CC BY
134
УДК 004 + ЗЗ9
JEL D 810, O 220, O З00
Ю. В. Прушинская
Институт экономики и организации промышленного производства СО РАН пр. Акад. Лаврентьева, 17, Новосибирск, 630090, Россия
E-mail: [email protected]
ОСОБЕННОСТИ АНАЛИЗА И ОЦЕНКИ РИСКОВ ИННОВАЦИОННЫХ ПРОЕКТОВ В СФЕРЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Рассматриваются основные проблемы, возникающие при оценке инновационных проектов в сфере информационных технологий (ИТ). В результате анализа проектов выявлены основные риски, присущие ИТ инновационным проектам, описан процесс обнаружения рисков в ИТ проектах; предложены рекомендации, для уменьшения влияния рисков на инновационные проекты, предложена схема управления рисками инновационных проектов в сфере ИТ, выработаны рекомендации для уменьшения влияния рисков на инновационный проект.
Ключевые слова: сфера инновационных технологий, инновационный проект, риски инновационных проектов.
В качестве основы для исследования использовалась база данных инновационных проектов крупной инновационной компании. Нами были проанализированы 38 инновационных проектов, в области информационных технологий (ИТ). Данные проекты связаны с разработкой программного обеспечения для крупнейших банков России, реализацией новых финансовых сервисов для населения и организаций, а также с повышением доступности для населения существующих финансовых сервисов, вводом на рынок новых финансовых продуктов, улучшением существующих сервисов в области денежных переводов и программ лояльности.
В результате анализа были выявлены основные проблемы, возникающие при оценке инновационных проектов и в процессе реализации инновационного продукта. Собрана информация по основным рискам, с которыми столкнулись анализируемые нами проекты. Выявлены основные неопределенности, связанные с созданием нового продукта. Рассчитан процент завершенности проектов к изначально запланированному сроку.
На первом этапе работы в результате анализа литературы были выделены особенности инновационных проектов в сфере ИТ, которые включают:
1) быстрое устаревание результатов новшеств ИТ сферы [1];
2) продукты ИТ сферы не всегда понятны потребителям (необходимо закладывать дополнительные затраты на рекламу и маркетинг) [2];
3) главной составляющей инновационных проектов в сфере ИТ являются человеческие ресурсы;
4) риски ИТ инновационных проектов связаны с большой неопределенностью и непредсказуемы, поэтому их необходимо оценивать на протяжении всего срока действия проекта [3];
5) риски инновационного продукта ИТ зачастую уникальны [3].
На следующем этапе работы выделены основные проблемы, связанные с особенностями инновационных проектов.
1. При проведении оценки эффективности инновационного проекта необходимо принимать в расчет временной горизонт, учитывающий сроки действия права на объект интеллектуальной собственности.
1818-7862. Вестник НГУ. Серия: Социально-экономические науки. 2013. Том 13, выпуск 4 © Ю. В. Прушинская, 2013
2. При реализации инновационного проекта возникает гораздо больше рисков, чем при реализации инвестиционного проекта. Многие предприятия, не уделяя должного внимания оценке рисков, отказываются от реализации инновационных проектов из-за высокой неопределенности, что в конечном счете приводит к отставанию в их развитии [4].
3. При реализации инновационного проекта необходимым условием является учет конъюнктуры рынка инноваций.
4. В настоящее время в России инвесторы, планирующие вложить денежные средства в инновационный проект, не уверены, что инновационный продукт будет способен окупить затраты на его реализацию и принести прибыль. Однако, несмотря на существующее недоверие к успешной реализации инноваций, размеры финансовых вложений в НИОКР в различных отраслях достигают огромных величин, особенно это проявляется в сфере ИТ [5].
Проблема заключается в следующем: чтобы инвесторы вложили денежные средства в инновационный проект, необходимо провести полную оценку эффективности инновационного проекта.
Практически основное место в оценке эффективности инновационного проекта, особенно инновационного проекта в сфере ИТ, занимает оценка риска. Для эффективного управления рисками в ИТ проектах необходимо учитывать следующие особенности.
1. Для эффективного управления рисками проекта может не хватать данных.
Согласно классической теории управления рисками непредсказуемость может быть связана как с полным или частичным отсутствием информации (в частности, по уникальному объекту), так и с принципиальной невозможностью количественного или качественного прогноза. Для предсказуемых (прогнозируемых) рисков дальнейший анализ тесно связан с получением необходимой информации [6]. Многие риски инновационных проектов являются уникальными, поскольку происходят от самого продукта. Данных относительно таких рисков немного или нет вовсе.
2. Следующим фактором, который необходимо учитывать при оценке рисков инновационного проекта, является то, что зачастую, оценив определенные риски на этапе планирования проектов как незначительные, на этапе реализации их уже не отслеживают. Однако необходимо помнить о том, что риски инновационных проектов связаны с большой неопределенностью, и риски, которые были оценены как незначительные на начальных этапах, могут оказаться критическими для проекта при его осуществлении. В литературе известна точка зрения, согласно которой пересмотр рисков должен проводиться регулярно, согласно расписанию, составленному на этапе планирования [7].
Для того чтобы избежать недооценки рисков, мы предлагаем использовать следующий метод.
В начале проекта необходимо перечислить все возможные катастрофические результаты, с которыми может столкнуться данный проект. Следует описать сценарии, ведущие к каждому из рисков, на основании сценариев необходимо описать риски, которые вызывает каждый из этих сценариев [8].
Предложенные действия необходимо производить регулярно, на каждом этапе и стадии реализации проекта, поскольку инновационные проекты в сфере ИТ непредсказуемы.
3. Риски, которыми невозможно управлять, нет смысла вносить в перечень рисков и затрачивать на них временные ресурсы. К данным рискам относятся риски со следующими характеристиками:
а) вероятность возникновения риска очень мала;
б) при возникновении риска в результатах реализуемого проекта теряется необходимость;
в) в случае реализации риска последствия будут незначительны и не повлияют на реализацию проекта [9].
4. Из проведенного анализа 38 инновационных проектов в сфере ИТ выявлено, что все анализируемые проекты за исключением одного сданы с опозданием относительно изначально определенной даты завершения проекта.
5. Важнее ограничивать уровень потерь в процессе разработки программного обеспечения, чем «идти на всё ради победы». К примеру, не следует требовать от подчиненных жертвовать своим личным временем ради достижения цели, разумнее нанять дополнительных сотрудников для разработки ИТ проекта.
6. Все неопределенности относительно проекта необходимо заключать в четкие рамки: каждой неопределенности необходимо присваивать ту или иную степень вероятности. Данное правило необходимо применять особенно к срокам проекта.
Не следует говорить о том, что проект будет точно завершен к конкретному сроку. Каждому сроку необходимо устанавливать границы неопределенности или вероятности. Такие границы можно очертить с помощью диаграмм неопределенности.
Для отрасли ИТ проектов диапазон реального завершения проекта составляет примерно 100-150 % от даты первого возможного завершения проекта до даты реального завершения проекта. Данный вывод был получен из анализа упомянутых проектов, который показал, что только 1 проект был реализован без опоздания от изначально предполагаемого срока; опоздание в диапазоне от 100 до 200 % от изначально установленного срока выявлено у 30 анализируемых проектов; от 50 до 100 % - у 6.
7. В процессе исследования установлено, что перечень главных проблем организации, с которыми пришлось столкнуться в проектах последних лет, является первоначальным перечнем рисков для следующего проекта. При анализе проектов установлено, что более половины их имели общие риски. Например, если выявить и учесть, что у недавно завершенного проекта возникли трудности, когда несколько ключевых работников ушли из компании, тогда потери персонала входят в перечень рисков по новому проекту.
Таким образом, чтобы выявить риски по реализуемому проекту, необходимо проанализировать неудачи предыдущих проектов и транспонировать их на новый проект.
8. Зачастую в компаниях возникает проблема, связанная с тем, что риск, который в итоге губит проект, изначально не упоминается при анализе выявленных рисков. Мы предлагаем следующие действия, которые помогут учесть данную особенность при анализе рисков.
В большинстве случаев данная проблема лежит на критическом пути. Следовательно, необходимо проанализировать, что лежит на критическом пути для данного проекта и обозначить это как риск. (Под критическим путем мы понимаем непрерывную последовательность работ и событий от начального до конечного события.)
9. Следует учитывать и такие риски, наступление которых может полностью вынудить отказаться от проекта.
Для инновационных проектов в сфере ИТ, например, такой риск может быть связан с тем, что конкуренты быстрее, чем компания, выпускают на рынок инновационный продукт, скажем, скопировав технологии (утечка информации). Другой пример: инновационный продукт строится на базе преобладающей на данном рынке операционной системы. Если система будет обновлена, продукт окажется несовместимым с новой версией. В этом случае при оценке проекта данный риск необходимо упоминать при перечислении рисков проекта. Однако проводить какие-либо мероприятия по управлению таким риском не имеет смысла - это неуправляемый риск.
10. Основные вопросы неопределенности, связанные с ИТ проектами, заключаются в следующем: когда закончится разработка проекта, примет ли пользователь продукт и будет ли его использовать? На них нельзя ответить однозначно, но при планировании проекта необходимо выяснять и собирать информацию, которая поможет найти ответы.
Необходимо анализировать информацию, полученную от реализации аналогичных проектов, а также опыт компании. Данная информация имеет большую ценность. Если схема ослабления риска слишком дорого стоит, то указанные данные могут пригодиться при принятии решения о том, ослаблять риск или нет.
Как и для любой другой области, в области разработки программного обеспечения существуют общие проблемы, с которыми сталкиваются все проекты. Данные проблемы вызывают расхождение проекта с его реальным исполнением, а следовательно, являются рисками проектов.
Как было сказано выше, мы проанализировали риски тридцати восьми инновационных проектов в сфере ИТ, что позволило нам выделить основные риски, чаще всего встречающиеся в инновационных проектах в этой сфере:
1) ошибки в календарном планировании;
2) изменение требований в процессе реализации проекта;
3) текучесть кадров;
4) нарушение спецификаций;
5) низкая производительность.
Смысл управления рисками состоит именно в том, чтобы принять меры по каждому из перечисленных рисков. Остановимся немного подробнее на перечисленных рисках.
Ошибки в календарном планировании. Смысл данных ошибок состоит в неправильной оценке продукта, который будет создан в результате реализации инновационного проекта. Часто это происходит потому, что в проект могут добавиться работы, которые при планировании проекта казались ненужными. Например, если изначально запланированный семимесячный проект в реальности превращается в двенадцатимесячный, то вся вина падает не на того, кто неправильно спланировал проект, однако, как правило, в подобных случаях во всем винят исполнителей, которые не успевают выполнить проект в срок. Проведенный нами анализ показал, что в 32 проектах (84 %) неверно спланированные работы по проекту не позволили завершить проекты к установленному сроку.
Изменение требований в процессе реализации проекта. Существует большая вероятность возникновения риска, состоящая в том, что заказчик ИТ продукта, который в начале разработки хотел получить один продукт, в конце разработки может хотеть совершенно другой продукт. Это связано с тем, что за время разработки продукта в данной области бизнеса произошли изменения. Следовательно, потребуются дополнительные работы. Однако, чтобы прогнозировать такой риск, необходимо понимать, сколько именно дополнений разумно ожидать.
При планировании проекта, чтобы учесть данный риск, мы предлагаем следующее: прописать в договоре между заказчиком и подрядчиком, что подрядчик обязуется разработать для заказчика определенный продукт по истечении определенного времени. Если окажется, что заказчику необходимо что-то другое, это будет являться проблемой заказчика.
Однако это не самый лучший выход из ситуации для репутации компании. Для удовлетворения потребностей заказчика передовым компаниям при планировании инновационного проекта необходимо учитывать, что потребуются дополнительные ресурсы для создания продукта, который заказчику будет необходим в будущем. Например, заранее сообщить заказчику о том, что его предпочтения по объективным обстоятельствам могут модифицироваться, и в разработку нового продукта закладывать изменения, которые могут потребоваться в дальнейшем. Данные действия со стороны подрядчика, возможно, могут основываться на предыдущем опыте разработки и реализации ИТ проектов.
Данный риск был включен нами в перечень основных рисков инновационных проектов в сфере ИТ, поскольку у 23 проектов из анализируемых, что составляет 60 %, в процессе реализации в проектную документацию были внесены изменения, у 8 проектов (21 %) указанные изменения касались доработок продукта в связи с переменами, которые произошли на рынке, а также в связи с дополнительными функциональными возможностями продукта, которые не были согласованы при реализации проекта (14 проектов, 37 %).
Текучесть кадров. Возможность увольнения персонала, как правило, не рассматривается в момент оценки проекта. Чтобы принять во внимание данный фактор, необходимо заложить дополнительные расходы для сдерживания риска на начальном этапе.
В данном случае неблагоприятные последствия заключаются в общих потерях времени при найме подходящей замены уволившимся работникам. Кроме того, новому работнику должно потребоваться время, чтобы достигнуть уровня производительности уволившегося сотрудника.
Из проведенного анализа был сделан вывод, что это время составляет от 2 месяцев на самых простых позициях в области ИТ до 24 месяцев для разработки очень сложных приложений. Длина этого периода зависит от сложности области, ее типичности, от опыта и навыков типичного новичка.
Анализ показал, что в результате реализации 19 проектов (50 %) возникла проблема задержки реализации в связи с отсутствием необходимого сотрудника, увольнением или повышенной загруженностью занятых в проекте в результате увольнения сотрудников, выполняющих аналогичные функции, в том числе уход основного разработчика существенно повлиял на сроки реализации 9 проектов (24 %). В результате проекты были сданы с опозданием к изначально определенному сроку, диапазон опоздания составил от 100 до 200 %.
Нарушение спецификаций относится к обрушению процесса переговоров по установлению требований к продукту, которые проводятся в начале любого проекта.
В данном случае речь идет о том, что если стороны не могут прийти к соглашению, принятие решения затягивается, то результат могут скрывать. Проект реализуют с неверными двусмысленными целями, решение проблемы постоянно откладывается на будущее.
Таким образом, продукт получается описанным неверно, проблема откладывается, а в итоге создать продукт не получается. Рано или поздно приходится сталкиваться с нерешенными проблемами, и конфликтная ситуация повторяется снова. В худшем случае это происходит на очень поздней стадии проекта, когда на него потрачены почти все отведенные ресурсы и обнаружение нерешенной проблемы может погубить проект. По статистике около 10-15 % проектов прекращены без поставки какой-либо продукции именно по указанной причине.
Такой риск можно снимать с проекта, когда стороны однозначно достигли договоренности по поводу спецификаций (описания продукта).
В анализируемых нами проектах 10 % от общего количества (4 проекта) имели сложности при реализации, связанные с наступлением указанного риска, который проявился в неоднозначной согласованности продукта и проектных целей, что привело к дополнительному вложению значительных финансовых ресурсов, связанных с затратами на дополнительные разработки, и к затягиванию срока реализации проекта.
Низкая производительность. Только данный риск из всех перечисленных связан с трудозатратами. Тогда как существует мнение, распространенное среди руководителей, что риски ИТ проектов связаны с тем, что исполнители не успевают выполнить проект в срок.
Существенные различия производительности можно наблюдать между разработчиками. Между командами проектов они более сглажены и не так заметны, как индивидуальные различия.
На производительность могут оказывать влияние и перечисленные риски.
Для выявления указанного риска в анализируемых проектах исследовалась производительность разработчиков схожих по трудозатратам проектов, данные анализа показали, что производительность собственных разработчиков компании (занятых в 32 из 38 анализируемых проектов) была выше, чем производительность разработчиков, привлекаемых из сторонних организаций (заняты в 6 из 38 анализируемых проектов). Производительность разработчиков сторонних организаций оказалась ниже на 42 %, т. е. на разработку аналогичных по трудозатратам проектов разработчикам привлеченных организаций потребовалось больше рабочего времени. Кроме того, на уровень производительности внутренних разработчиков компании и иных проектных исполнителей оказывает значительное влияние опыт работы (продолжительность работы в копании). Максимальная производительность была выявлена у разработчиков, проработавших в компании более 2-х лет.
Таким образом, чтобы осуществить управление рисками ИТ проектов, необходимо описать и проанализировать для разрабатываемого инновационного проекта перечисленные риски. Данные риски являются общими практически для всех инновационных проектов в сфере ИТ.
Проведенная работа позволяет распространить результаты на иные инновационные проекты в сфере ИТ, поскольку анализ 38 проектов показал, что только один проект был реализован в изначально установленные сроки, 37 проектов из анализируемых (97 %) реализованы с опозданием или сроки корректировались в процессе реализации проекта. Неверно спланированные работы не позволили завершить к изначально установленному сроку 32 проекта (84 %). При этом к затягиванию сроков реализации 10 % анализируемых проектов (4 проекта) привело нарушение спецификации; в 23 проектах (60 %) были изменены требования в процессе реализации проекта, что в 15 проектах (39 %) привело к нарушению сроков реализации. В 19 проектах (50 %) уход сотрудников из проекта не позволил реализовать проект в изначально установленное время.
Однако кроме рисков, которые присущи всем ИТ проектам, необходимо принимать во внимание и рассматривать возможность возникновения рисков, которые будут свойственны конкретному ИТ проекту. Например, в проекте может быть ключевой исполнитель, чей уход будет роковым для проекта, важный пользователь, который может решить продолжать раз-
виваться без предлагаемого ему продукта, или поставщик, чья необязательность может иметь необратимые последствия.
Как только указанные риски обнаружены и количественно оценены, ими можно управлять. Но выявить данные риски нелегко.
В некоторых организациях существует мнение, что говорить о риске перед началом проекта - значит навлечь риск на проект. Однако молчание - это не способ избавиться от риска.
Ниже мы приводим процесс обнаружения рисков в ИТ проектах.
1. Описать все возможные риски (опасения за реализацию проекта). Данный этап разумно проводить при помощи мозгового штурма. Возможно, в данном случае следует идти методом от противного: описать все надежды относительно проекта и рассмотреть прямо противоположную ситуацию.
2. Построить сценарий развития каждого риска.
3. Выявить то, что могло бы привести к возникновению проблемы.
Необходимо заметить, что большинство проектов рушится примерно посредине. Следовательно, именно в этот период управление рисками необходимо проводить особенно тщательно. Причины проблем почти всегда возникают раньше, но их осознание приходит на середине проекта [10].
Приведем перечень мер по управлению рисками, которые необходимо осуществлять в период с середины и до окончания проекта.
1. Непрерывно производить мониторинг показателей наступления рисков в поисках такого риска, который может осуществиться в ближайшее время.
2. Продолжать выявлять новые риски, которые, возможно, не были выявлены в начале проекта.
3. Ежедневно отслеживать показатели завершенности [10].
Показатели завершенности демонстрируют состояние исполнения проекта, позволяют сравнивать результаты хода работ на данный момент с общим объемом работ.
Следующим этапом нашей работы является описание показателей наступления риска и мониторинг рисков.
Для каждого риска необходимо выбрать один или несколько показателей, предупреждающих о наступлении риска, и в процессе реализации проекта отслеживать данный показатель, чтобы при первом его наступлении привести в действие план на случай наступления рисков.
Методы управления рисками или возможные действия с рисками:
1) избегание;
2) сдерживание;
3) ослабление;
4) уклонение [11].
Избежать риска можно путем неосуществления проекта или части проекта, который вызывает данный риск. Следствием избегания риска является упущенная выгода, которую мог принести проект при его реализации. Например, не реализовав проект по продаже инновационной продукции, компания упустит выгоду от роста продаж и развития бренда.
Компания сдерживает риск, когда закладывает в бюджет достаточно времени и денег, чтобы заплатить за риск, если он наступит. Стратегия сдерживания предполагает закладывание средств в бюджет в начале проекта, чтобы противостоять рискам, наступление которых наиболее вероятно.
Стратегия ослабления риска предполагает принятие мер по снижению возможных затрат на сдерживание. Затраты на ослабление невозможно вернуть. Ослабление рисков представляет собой полный набор предварительных мер, которые можно предпринять для обеспечения возможности последующих действий по эффективному противодействию рискам в случае их материализации.
Всякое ослабление включает затраты на текущий момент, ради того чтобы справиться с возможными рисками при их наступлении в будущем. Это делает наилучший сценарий менее прекрасным, поскольку если риск не наступит, то затраты на ослабление рисков могут показаться пропавшими зря.
Как правило, в ИТ проектах осознающий риски руководитель захочет заставить включить в ранние версии те функции продукта, с которыми связан наиболее серьезный технический риск. Это разумно, но многие руководители боятся погубить проект уже в самом его начале.
Действительно, в управлении рисками ИТ проектов разумнее пораньше понести неизбежные потери, иначе можно потерять контроль над ситуацией. Части системы, которые зависят от создания «технических чудес», следует включить в более ранние версии. Таким образом, если «чудес» не случилось, остаются шансы перехода на «аварийный режим». Если это случилось достаточно рано, то можно будет справиться своими силами, в то время как данное поражение на более поздних этапах коснется всех.
В проектах, где критичен срок сдачи, эффективным методом ослаблением риска является раннее начало процесса осуществления проекта. Однако для некоторых ранее начало проекта означает трату денег на что-то не вполне надежное, поскольку, не понятно, будет новый продукт принят рынком или нет. Многие проекты оказываются под угрозой срыва сроков поставки из-за того, что руководители ушли от другого риска, связанного с ранним стартом.
Компании удается уклониться от риска, когда никакие меры не предпринимаются, но проект проходит без рисков. В данном случае можно говорить об удаче.
Первые три способа стоят денег: избегание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. И только удача, которая реализуется, если от риска удается уклониться, ничего не стоит компании.
Разумеется, планировать проект, рассчитывая на то, что удастся увернуться от рисков, не является грамотной стратегией для реализации проекта. Однако необходимо помнить, что вероятность того, что проект сможет уклониться от всех рисков сразу, очень мала, даже если перечень этих рисков небольшой.
Необходимо перед началом осуществления проекта просчитывать термин «подверженность риску», который означает ожидание затрат на сдерживание риска [12]:
подверженность риску = затраты х вероятность.
Например, если наступление риска обойдется компании в миллион рублей, а вероятность наступления риска составляет 20 %, то подверженность риску составит 200 000 рублей. Если посчитать подверженность для всех рисков и создать резерв на управление рисками, равный этой сумме, то его должно хватить, чтобы покрыть затраты на наступившие риски. Такой резерв разумно создавать на компанию в целом, на долгосрочные проекты.
Вероятность наступления того или иного риска может основываться на данных по отрасли, предшествующем опыте или догадке. В конечном счете важно не определиться точно с количественным выражением вероятности, а понять, что данный риск угрожает осуществлению проекта.
Подверженность риску можно выразить в месяцах ожидаемой задержки. Если вероятность наступления риска составляет 20 % и наступление риска вызовет задержку в пять месяцев, то подверженность риску составляет 1 месяц.
Мы предлагаем схему управления рисками.
1. Идентифицировать риски, которые угрожают проекту; убедиться, что все основные риски проектирования программного обеспечения угрожают проекту.
2. Провести оценку по каждому из рисков и осуществить действия по управлению рисками:
• выявить и описать показатели наступления события риска (наиболее ранних признаков);
• оценить влияние риска на стоимость и расписание проекта;
• определить для каждого из рисков, какие действия по управлению рисками необходимо провести;
• оценить вероятность наступления риска;
• рассчитать подверженность риску по отношению к графику и бюджету;
• определить, какие меры необходимо будет предпринять, когда событие риска наступит;
• включить в проект действия по управлению рисками.
3. Сделать предположение относительно даты завершения проекта исходя из допущения, что ни один из рисков не наступит, т. е. определить самую раннюю дату возможного завершения проекта; использовать собственные и отраслевые факторы неопределенности для установления наиболее вероятной даты завершения проекта с учетом рисков (диаграммы неопределенности). Диаграмма неопределенности представляет собой диапазон возможных дат завершения проекта, каждая из которых отмечена некоторым уровнем неопределенности.
4. Описать все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом.
5. Описать структуру работ, показывающую все задачи, которые нужно решить для выполнения работ. Оценить все усилия, необходимые для каждой задачи.
6. Оценить все выгоды и затраты.
7. Отслеживать на протяжении оставшейся части проекта риски на предмет наступления или исчезновения и осуществлять запланированные действия в случае наступления риска.
8. На всем протяжении проекта непрерывно осуществлять процесс идентификации рисков, оперативно реагировать на поздно проявляющиеся риски.
Мы предлагаем рекомендации, для уменьшения влияния рисков на инновационный проект:
1) детально оценить, какие дополнительные работы могут понадобиться в процессе осуществления проекта;
2) заложить дополнительные затраты времени и денежных средств на случай, если проект не будет выполнен к изначально запланированному сроку;
3) правильно описать и согласовать продукт, который будет создан по результатам стадии разработки;
4) все характеристики создаваемого продукта необходимо прописать в соглашении между разработчиком и заказчиком;
5) выявить «узкие» места проекта и предпринять необходимые действия для их устранения;
6) установить заработную плату для ключевых специалистов проекта на уровне выше среднерыночного;
7) подписать с работниками соглашения о конфиденциальности, о неразглашении информации, полученной в результате профессиональной деятельности;
8) прописать все свойства будущего продукта в соглашении между заказчиком и разработчиком;
9) нанять для осуществления разработки проекта проверенных в компании разработчиков, производительность и скорость работы которых известна по предыдущим проектам;
10) описать альтернативные варианты поставок оборудования и материалов, необходимых для реализации проекта, у различных поставщиков;
11) продумать альтернативные варианты реализации проекта на случай, если не будет достигнут прогнозируемый спрос у предполагаемой целевой аудитории.
Список литературы
1. Кравченко Н. А. Развитие инновационного бизнеса: истории успеха // Инновации. 2009. № 4. С. 95-102.
2. Инновационное предпринимательство: барьеры развития и факторы успеха: Сб. материалов науч.-практ. конф. / Под ред. Н. А. Кравченко, С. А. Кузнецовой, А. Т. Юсуповой; ИЭОПП СО РАН, Сиб. центр прикладных экон. исслед. Новосибирск, 2009. 211 с.
3. Агафонова И. П. Риск как объект управления при реализации инновационного проекта // Экономические преобразования в России: проблемы и перспективы: Межвуз. сб. науч. тр. СПб., 2002. № 3.
4. Torok R. M., Cordon P. J. Operational Profitably. Conducting Audits. N. Y.: John Wiley & Sons Inc, 2009. P. 28-55.
5. Кравченко Н. А., Кузнецова С. А., Маркова В. Д., Соломенникова Е. А., Титов В. В., Че-ремисина Т. П., Юсупова А. Т., Балдина Н. П., Халимова С. Р. Инновации и конкурентоспособность предприятий / Под ред. В. В. Титова; ИЭОПП СО РАН. Новосибирск, 2010. 323 с.
6. Прокопов Б. И. Инновационные проекты: экспертиза и оценка // Проблемы современной экономики. М., 2009. № 2 (30).
7. Дасковский В. Б., Киселёв В. Б. Совершенствование оценки эффективности инвестиций // Экономист. 2009. № 1. С. 42-56.
8. Харламенко Е. В. Количественный анализ рисков инвестиционного проекта // Российское предпринимательство. 2009. Т. 5, вып. 1 (134). С. 58-63.
9. Тумина Т. А. Методология оценки эффективности инновационной деятельности // Транспортное дело России. 2009. № 1. ИКЬ: http://morvesti.ru/archiveTDR/ section.php? 8БСТЮ]Ч_ГО=1390 (дата обращения 20.01.2013).
10. Дасковский В. Б., Киселёв В. Б. Фактор времени при оценке эффективности инвестиционных проектов // Экономист. 2008. № 1. С. 55-67.
11. Нойбауэр Х. Инновационная деятельность на малых и средних предприятиях // Менеджмент на малых и средних предприятиях / Под ред. Й. Х. Пихлера, Х. Й. Плайтнера, К.-Х. Шмидта. URL: http://www.cfin.ru/management/strategy/smallbiz_inno.shtml (дата обращения 02.03.2007).
12. Нарышкин С. Е. Инновационная составляющая инвестиционных процессов // Вопр. экономики. 2009. № 7. С. 52-64.
Материал поступил в редколлегию 09.04.2013
Yu. V. Prushinskaya
Institute of Economics and Industrial Engineering of the Siberian Branch of the RAS 17, Acad. Lavrentiev ave., Novosibirsk, 630090, Russian Federation
E-mail: [email protected] ESPECIALLY EVALUATION OF INNOVATIVE PROJECTS IN THE FIELD OF IT
The article deals with the core problem of the evaluation of innovative projects in the IT sector, identifies the main features that should be considered for effective risk management in IT projects. An analysis of innovative projects in the field of IT, identified the main risks inherent in IT innovation projects and shows the detection of risks in IT projects, the scheme of evaluation of innovative projects in the field of IT.
Keywords: innovative technology, innovative project, the risks of innovation projects.
