Subschet.ru: Новости | Статьи | Книги on-line | Журналы on-line | Книги в продаже | Вопрос-ответ | Официальные документы
SUBSCHET.RU
  Везде    Новости    Статьи    Книги on-line    Книги в продаже    Вопрос-ответ    Официальные документы  
Образец для поиска:

Все словоформы  Нечеткий поиск | Советы по поиску | Топ запросы







РИСКИ ИННОВАЦИОННЫХ ИТ-ПРОЕКТОВ

Разделы: Аудит; Представление отчетности в электронном виде, Прочие вопросы, Право

Инновационный ИТ-проект – это разработка нового программного обеспечения и внедрение информационных систем, обеспечивающее качественный рост эффективности процессов.

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

ИТ проекты имеют свои особенности, а именно: 1) ИТ-проекты быстро устаревает; 2) клиенты не всегда понимают ИТ-проект (необходима реклама и продвижение); 3) человек – главная составляющая ИТ-проекта; 4)определить риски инновационных ИТ-проектов является большой трудностью, они мало предсказуемы; 5) риски инновационного ИТ-проектов часто являются уникальными.

Можно выделить основные проблемы, которые связаны с особенностями инновационного проекта.
1. При проведении оценки эффективности инновационного проекта необходимо принимать в расчет временной горизонт, учитывающий сроки действия права на объект интеллектуальной собственности.
2. При реализации инновационного проекта возникает гораздо больше рисков, чем при реализации инвестиционного проекта. Много предприятий, которые не уделили внимания оценке рисков, решают отказаться от реализации инновационных проектов в связи с неопределенностью, а как результатом этих решений является отставание таких предприятий в развитии.
3. При реализации инновационного проекта важным условием выступает учет конъюнктуры рынка инноваций.
4. На данный момент, инвесторы, которые вкладывают свои средства в российские предприятия, не уверены в способности инновационных проектов окупить себя и принести прибыль. Но, несмотря на опасения, размеры вложений в ИТ-проекты достигают невероятно больших сумм.

Чтобы инвесторы заинтересовались проектом и вложились в него, важно провести оценку эффективности данного проекта. Основное место в данном процессе занимает оценка рисков, а для их эффективного управления важно учитывать некоторые особенности.
1. Для эффективного управления рисками возможна нехватка данных. Согласно классической теории управления рисками непредсказуемость может быть связана как с полным или частичным отсутствием информации (в частности, по уникальному объекту), так и с принципиальной невозможностью количественного или качественного прогноза. Для предсказуемых (прогнозируемых) рисков дальнейший анализ тесно связан с получением необходимой информации. Большое количество рисков инновационных проектов уникальны, так как происходят от самого продукта. Данных о таких рисках очень мало или вовсе нет.
2. Следующий фактор, необходимый при оценке рисков инновационного проекта, является тем, что как правило, на этапе планирования оцениваются некоторые риски как незначительные, то в дальнейшем они не отслеживаются вовсе. Однако важно помнить, что риски инновационных проектов связаны с большой неопределенностью, и риски, оцененные как незначительные на первых этапах, могут оказаться весьма критическими для проекта при его осуществлении. В литературе приведена одна мысль, согласно ей, анализ рисков необходимо проводить регулярно, по расписанию, составленному на этапе планирования.

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

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

Предложенные действия необходимо производить регулярно.
Риски, которыми невозможно управлять, нет смысла вносить в перечень рисков и затрачивать на них временные ресурсы. К данным рискам относятся риски со следующими характеристиками:
а) вероятность возникновения риска очень мала;
б) при возникновении риска в результатах реализуемого проекта теряется необходимость;
в) в случае реализации риска последствия будут незначительны и не повлияют на реализацию проекта.

Важнее ограничивать уровень потерь в процессе разработки программного обеспечения, чем «идти на всё ради победы». К примеру, не следует требовать от подчиненных жертвовать своим личным временем ради достижения цели, разумнее нанять дополнительных сотрудников для разработки ИТ проекта

Все неопределенности относительно проекта необходимо заключать в четкие рамки: каждой неопределенности необходимо присваивать ту или иную степень вероятности. Данное правило необходимо применять особенно к срокам проекта.

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

Для отрасли ИТ проектов диапазон реального завершения проекта составляет примерно 100 – 150% от даты первого возможного завершения проекта до даты реального завершения проекта. Данный вывод был получен из анализа упомянутых проектов, который показал, что только 1 проект был реализован без опоздания от изначально предполагаемого срока; опоздание в диапазоне от 100 до 200% от изначально установленного срока выявлено у 30 анализируемых проектов; от 50 до 100% – у 6.

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

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

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

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

Следует учитывать и такие риски, наступление которых может полностью вынудить отказаться от проекта. Для инновационных проектов в сфере ИТ, например, такой риск может быть связан с тем, что конкуренты быстрее, чем компания, выпускают на рынок инновационный продукт, скажем, скопировав технологии (утечка информации). Другой пример: инновационный продукт строится на базе преобладающей на данном рынке операционной системы (ОС). Если система будет обновлена, продукт окажется несовместимым с новой версией. В этом случае при оценке проекта данный риск необходимо упоминать при перечислении рисков проекта. Однако проводить какие-либо мероприятия по управлению таким риском не имеет смысла – это неуправляемый риск.

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

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

По результатам анализа тридцати восьми инновационных проектов в сфере информационных технологий были выделены основные риски, чаще всего встречающиеся в инновационных проектах в этой сфере:
1) ошибки в календарном планировании;
2) изменение требований в процессе реализации проекта;
3) текучесть кадров;
4) нарушение спецификаций;
5) низкая производительность.

Задача управления рисками заключается в том, чтобы меры были приняты по каждому из перечисленных рисков.

1. Ошибки в календарном планировании.

Смысл этих ошибок заключается в некорректной оценке продукта, созданного как результат реализации инновационного проекта. Чаще всего это происходит из-за того, что в работы над проектом могут добавиться дополнительные работы, не планируемые в самом начале.
2. Изменение требований в процессе реализации проекта.

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

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

Однако это не самый лучший выход из ситуации для репутации компании. Для удовлетворения потребностей заказчика передовым компаниям при планировании инновационного проекта необходимо учитывать, что потребуются дополнительные ресурсы для создания продукта, который заказчику будет необходим в будущем. Например, заранее сообщить заказчику о том, что его предпочтения по объективным обстоятельствам могут модифицироваться, и в разработку нового продукта закладывать изменения, которые могут потребоваться в дальнейшем. Данные действия со стороны подрядчика, возможно, могут основываться на предыдущем опыте разработки и реализации ИТ проектов.

Данный риск был включен в перечень основных рисков инновационных проектов в сфере ИТ, поскольку у 23 проектов из анализируемых, что составляет 60%, в процессе реализации в проектную документацию были внесены изменения, у 8 проектов (21%) указанные изменения касались доработок продукта в связи с переменами, которые произошли на рынке, а также в связи с дополнительными функциональными возможностями продукта, которые не были согласованы при реализации проекта (14 проектов, 37%).
3. Текучесть кадров.

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

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

Из проведенного анализа был сделан вывод, что время, затрачиваемое новым сотрудником на достижение необходимого уровня производительности, может составлять от 2 месяцев на самых простых позициях в области ИТ до 24 месяцев для разработки очень сложных приложений. Длина этого периода зависит от сложности области, ее типичности, от опыта и навыков типичного новичка.

Анализ показал, что в результате реализации 19 проектов (50%) возникла проблема задержки реализации в связи с отсутствием необходимого сотрудника, увольнением или повышенной загруженностью занятых в проекте в результате увольнения сотрудников, выполняющих аналогичные функции, в том числе уход основного разработчика существенно повлиял на сроки реализации 9 проектов (24%). В результате проекты были сданы с опозданием к изначально определенному сроку, диапазон опоздания составил от 100 до 200% .
4. Нарушение спецификаций.

Относится к обрушению процесса переговоров по установлению требований к продукту, которые проводятся в начале любого проекта.

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

Таким образом, продукт получается описанным неверно, проблема откладывается, а в итоге создать продукт не получается. Рано или поздно приходится сталкиваться с нерешенными проблемами, и конфликтная ситуация повторяется снова. В худшем случае это происходит на очень поздней стадии проекта, когда на него потрачены почти все отведенные ресурсы и обнаружение нерешенной проблемы может погубить проект. По статистике около 10–15 % проектов прекращены без поставки какой-либо продукции именно по указанной причине.

Такой риск можно снимать с проекта, когда стороны однозначно достигли договоренности по поводу спецификаций (описания продукта).

В анализируемых проектах 10% от общего количества (4 проекта) имели сложности при реализации, связанные с наступлением указанного риска, который проявился в неоднозначной согласованности продукта и проектных целей, что привело к дополнительному вложению значительных финансовых ресурсов, связанных с затратами на дополнительные разработки, и к затягиванию срока реализации проекта.

5. Низкая производительность.

Только данный риск из всех перечисленных связан с трудозатратами. Тогда как существует мнение, распространенное среди руководителей, что риски ИТ проектов связаны с тем, что исполнители не успевают выполнить проект в срок.

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

Для выявления указанного риска в анализируемых проектах исследовалась производительность разработчиков схожих по трудозатратам проектов, данные анализа показали, что производительность собственных разработчиков компании (занятых в 32 из 38 анализируемых проектов) была выше, чем производительность разработчиков, привлекаемых из сторонних организаций (заняты в 6 из 38 анализируемых проектов).

Производительность разработчиков сторонних организаций оказалась ниже на 42%, т. е. на разработку аналогичных по трудозатратам проектов разработчикам привлеченных организаций потребовалось больше рабочего времени. Кроме того, на уровень производительности внутренних разработчиков компании и иных проектных исполнителей оказывает значительное влияние опыт работы (продолжительность работы в копании). Максимальная производительность была выявлена у разработчиков, проработавших в компании более 2-х лет.

Проведенная работа позволяет распространить результаты на иные инновационные проекты в сфере ИТ, поскольку анализ 38 проектов показал, что только один проект был реализован в изначально установленные сроки, 37 проектов из анализируемых (97%) реализованы с опозданием или сроки корректировались в процессе реализации проекта. Неверно спланированные работы не позволили завершить к изначально установленному сроку 32 проекта (84%). При этом к затягиванию сроков реализации 10% анализируемых проектов (4 проекта) привело нарушение спецификации; в 23 проектах (60%) были изменены требования в процессе реализации проекта, что в 15 проектах (39%) привело к нарушению сроков реализации. В 19 проектах (50%) уход сотрудников из проекта не позволил реализовать проект в изначально установленное время.

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

Как только указанные риски обнаружены и количественно оценены, ими можно управлять. Но выявить данные риски нелегко. В некоторых организациях существует мнение, что говорить о риске перед началом проекта – значит навлечь риск на проект. Однако молчание – это не способ избавиться от риска.

Однако можно отметить, что существует процесс обнаружения рисков в ИТ проектах, который состоит их нескольких этапов.
1. Описать все возможные риски (опасения за реализацию проекта). Данный этап разумно проводить при помощи мозгового штурма. В данном случае следует идти методом от противного: описать все надежды относительно проекта и рассмотреть прямо противоположную ситуацию.
2. Построить сценарий развития каждого риска.
3. Выявить то, что могло бы привести к возникновению проблемы.

Необходимо заметить, что большинство проектов рушится примерно посредине. Следовательно, именно в этот период управление рисками необходимо проводить особенно тщательно. Причины проблем почти всегда возникают раньше, но их осознание приходит на середине проекта.

С целью предотвращения прекращения развития и функционирования проекта эффективно было бы применять перечень мер по управлению рисками, которые необходимо осуществлять в период с середины и до окончания проекта.

1. Непрерывно производить мониторинг показателей наступления рисков в поисках такого риска, который может осуществиться в ближайшее время.
2. Продолжать выявлять новые риски, которые, возможно, не были выявлены в начале проекта.
3. Ежедневно отслеживать показатели завершенности.

Показатели завершенности демонстрируют состояние исполнения проекта, позволяют сравнивать результаты хода работ на данный момент с общим объемом работ.

Большое положительное значение имеют рекомендации, для уменьшения влияния рисков на инновационный ИТ-проект:
1) детально оценить, какие дополнительные работы могут понадобиться в процессе осуществления проекта;
2) заложить дополнительные затраты времени и денежных средств на случай, если проект не будет выполнен к изначально запланированному сроку;
3) правильно описать и согласовать продукт, который будет создан по результатам стадии разработки;
4) все характеристики создаваемого продукта необходимо прописать в соглашении между разработчиком и заказчиком;
5) выявить «узкие» места проекта и предпринять необходимые действия для их устранения;
6) установить заработную плату для ключевых специалистов проекта на уровне выше среднерыночного;
7) подписать с работниками соглашения о конфиденциальности, о неразглашении информации, полученной в результате профессиональной деятельности;
8) прописать все свойства будущего продукта в соглашении между заказчиком и разработчиком;
9) нанять для осуществления разработки проекта проверенных в компании разработчиков, производительность и скорость работы которых известна по предыдущим проектам;
10) описать альтернативные варианты поставок оборудования и материалов, необходимых для реализации проекта, у различных поставщиков;
11) продумать альтернативные варианты реализации проекта на случай, если не будет достигнут прогнозируемый спрос у предполагаемой целевой аудитории.

Таким образом, чтобы осуществить управление рисками ИТ-проектов, необходимо описать и проанализировать для разрабатываемого инновационного проекта перечисленные риски. Данные риски являются общими практически для всех инновационных проектов в сфере ИТ.







© Обращаем особое внимание коллег на необходимость ссылки на "Субсчет.ру: теория и практика бухгалтерского учета и налогообложения" при цитировании (для on-line проектов обязательна активная гиперссылка)



  Рубрикатор

Налоги:
НДС | Налог на прибыль | НДФЛ | ЕСН | Акцизы | НДПИ | Налог на имущество предприятий | Транспортный налог | Налог на игорный бизнес | Земельный налог | УСН | ЕНВД | ЕСХН

Бухучет:
Учет основных средств | Учет нематериальных активов | Учет вложений во внеоборотные активы | Учет материально-производственных запасов | Учет собственного капитала | Учетная политика организации | Учет расчетов | Бухгалтерская отчетность

Документы:
Судебная практика по налоговым спорам (ФАС)

Кодексы:
НК РФ ч.1 | НК РФ ч.2 | ГК РФ ч.1 | ГК РФ ч.2 | ГК РФ ч.3 | ГК РФ ч.4 | ТК РФ

Разное:
Экономика недвижимости: учебное пособие Виноградов Д.В| -

  Новости

Налог на прибыль: учет банком доходов в виде процентов по кредитному договору

Возврат НДС организациям, экспортирующим водные биоресурсы с низкой степенью переработки

НДФЛ с доходов граждан стран ЕАЭС от работы по найму в РФ

Депутаты предлагают восстановить для детей-инвалидов и инвалидов I и II групп возможность воспользоваться правом на внеконкурсное поступление в ВУЗы

Налогообложение НДФЛ доходов резидента Великобритании, полученных в виде дивидендов или вознаграждений от российского общества

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

Организации, осуществляющие инженерно-геодезические изыскания должны состоять в СРО

Все новости >>


  Статьи

7 лайфхаков по выбору и уходу за дисками Alutec

Экосистема криптовалют: криптобиржа децентрализованного типа

Описание процедуры стрейчевания грузов

Факторы, сдерживающие внедрение МСФО в России

Инвестиции на рынке недвижимости по отдельным зарубежным странам

Бухгалтерский и налоговый учет расходов на упаковку

Кредит на приобретение автомобиля: перспективы отказа от КАСКО

Установление суммированного учета рабочего времени

Учет расходов на страхование заложенного имущества

Все статьи >>


  Официальные документы

Об НДФЛ при компенсации (оплате) спортсменам, тренерам и иным специалистам стоимости проезда и проживания при участии в спортивных мероприятиях. Письмо Минфина России от 10.12.2019 N 03-04-06/96274

О применении с 01.01.2020 вычета акциза при реализации алкогольной и спиртосодержащей продукции, произведенной из винограда. Письмо Минфина России от 11.12.2019 N 03-13-05/96478

Об учете в целях УСН расходов на оплату услуг нотариуса за учредителей при купле-продаже ими доли в уставном капитале организации. Письмо Минфина России от 09.12.2019 N 03-11-11/95351.

О получении налгового вычета при приобретении лекарств за счет собственных средств. Письмо Минфина России от 16.12.2019 N 03-04-05/98226.

Все официальные документы>>





Рейтинг@Mail.ru

Subschet.ru: Новости | Статьи | Книги on-line | Журналы on-line | Книги в продаже | Вопрос-ответ | Официальные документы | Закладки | Copyright © 2005-2014