ПЗ (1218909), страница 8

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 8)

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

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

В результате получаются скорректированные сроки и стоимость проекта с учетом возможных рисков.

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

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

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

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

Журнал требований на изменение проекта заполняется в том случае, когда назрела необходимость корректировки проекта, будь то сроки, логические рамки, финансирование или смена проектной команды. Доводить дело до этого, конечно, крайне нежелательно, но если все-таки такая потребность возникла (а она определяется руководителем проекта по согласованию с заказчиком), то в журнале фиксируются необходимые действия для выполнения изменений, а также дается оценка влияния этих действий на план и стоимость работ.

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

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

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

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

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

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

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

Очень хорошо зарекомендовал себя метод планирования резервов. Базовые параметры проекта лучше планировать «с запасом». Величина запаса экспертно оценивается в 20% от первоначальной величины. Для эффективного выполнения проекта необходимо создавать резервные фонды управления рисками, которые могут составлять до 10% от общего бюджета управления проектом.

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

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

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

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

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

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

Ввиду убытков, которые ООО «Грек» понесло в 2014 году, возможность увеличения штатов, как альтернатива автоматизации, руководством даже не рассматривается. Поэтому единственным вопросом, на который необходимо ответить для принятия руководством ООО «Грек» положительного решения о внедрении – каково соотношение предполагаемых затрат на разработку и внедрение первой итерации, и ожидаемого экономического эффекта.

8.2 Расчет затрат на проектирование, разработку, внедрение и обслуживание системы

Затраты на проектирование системы состоят из рабочего времени специалиста-проектировщика. В данном случае он же является разработчиком системы. Это были встречи с руководством предприятия для постановки задач, беседы с потенциальными пользователями. 3 встречи, в сумме 7 человеко-часов.

Затраты на разработку – оплата работы программиста. В данном случае – это оплата фиксированной суммы по договору подряда. Сумма была рассчитана исходя из предполагаемых трудозатрат на разработку в 30 человеко-часов.

Затраты на внедрение – это затраты на написание руководства пользователя и обучение сотрудника. Написание руководства пользователя было оценено в 2 человеко-часа, обучение сотрудников – в 8. В эти восемь человеко-часов входят так же и удаленные консультации пользователей на начальном этапе внедрения.

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

Стоимость человеко-часа программиста, нанятого для разработки и внедрения системы – 600 руб. человеко-час.

Соответственно, в денежном выражении затраты на первой итерации проекта = 600 47 = 28 200 руб.

8.3 Расчет экономической эффективности внедрения функционала первой итерации проекта

При расчете экономического эффекта использовались данные по простоям, поломкам оборудования, потерянным заявкам, не вовремя заказанным запчастям в ООО «Грек» за 2014 год, а так же экспертные оценки ответственных специалистов этой компании.

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

Таблица 23 ̶ Простои и потери в 2014 году

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

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

Для экономического анализа эффективности инвестиционного проекта традиционно используют следующие показатели:

̶ чистая текущая стоимость (Net Present Value, NPV);

̶ срок окупаемости (Payback Period, PP);

̶ индекс прибыльности инвестиций (Profitability Index, PI).

Исходные данные для расчета этих показателей приведенны в таблице 24.

Таблица 24 ̶ Исходные данные для расчета показателей

NPV – это сумма дисконтированных значений потока платежей, приведённых к сегодняшнему дню.

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

Характеристики

Список файлов ВКР