CC BY
56
Посилання на статтю_
Барская И.С. Особенности принятия решения на этапе инициации проектов создания корпоративных информационных систем / И.С. Барская, П.А. Тесленко, В.Ю. Денисенко // Управлшня проектами та розвиток виробництва: Зб.наук.пр. -Луганськ: вид-во СНУ iм. В.Даля, 2014 - №1(49). - С. 32-39. - Режим доступу -http://pmdp.org.ua_
УДК 005.8:681.3
И.С. Барская, П.А. Тесленко, В.Ю. Денисенко
ОСОБЕННОСТИ ПРИНЯТИЯ РЕШЕНИЯ НА ЭТАПЕ ИНИЦИАЦИИ ПРОЕКТОВ СОЗДАНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
Этап инициации ИТ-проектов характеризуется проблемой выбора: использовать готовое или разрабатывать собственное программное обеспечение. Для каждого из альтернативных вариантов проведен анализ рисков. Разработана сравнительная таблица оценок затрат ресурсов (денежных, человеческих и временных). Предложена процедура поддержки принятия решений в проектах создания корпоративных информационных систем на стадии инициации. Показана ее адекватность. Табл. 2, ист. 16.
Ключевые слова: информационная система, ИТ-проект, успешное внедрение, альтернативные варианты, формирование видения.
1.С. Барська, П.О Тесленко, В.Ю. Денисенко
ОСОБЛИВОСТ1 ПРИЙНЯТТЯ Р1ШЕНЬ НА ЕТАП1 1НЩ1АЦП ПРОЕКТ1В СТВОРЕННЯ КОРПОРАТИВНИХ
1НФОРМАЦ1ЙНИХ СИСТЕМ
Етап Мцацп 1Т-проею1в характеризуемся проблемою вибору: користуватись готовим або розроблювати власне програмне забезпечення. Для кожного з альтернативних варiантiв проведений аналiз ризиив. Розроблена порiвняльна таблиця оцшок витрат ресурав (грошових, людських, часових). Запропонована процедура пщтримки прийняття ршень в проектах створення корпоративних Ыформацшних систем на етап ^цацм. Показана ii адекватнють. Табл. 2, дж. 16.
I.S. Barskaia, P.A. Teslenko, V.Yu. Denisenki
FEATURES OF MAKING DECISIONS ON THE INITIATION STAGE IN PROJECTS OF CREATION CORPORATE INFORMATION SYSTEMS
Stage of initiation in IT-projects is characterized by the problem of choice: to use ready or to develop their own software. Risks are analyzed for each of the alternatives. A comparative table of the cost estimates (of financial, human and time resources) is developed. A procedure of supporting decision making in projects of creation of corporate information systems at the initiation stage is proposed. Its adequacy is shown.
JEL O22
ВВЕДЕНИЕ
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
1
Постановка проблемы в общем виде и ее связь с важными научными или практическими задачами. Успешное ведение бизнеса любого масштаба на сегодняшний день практически невозможно без использования информационных систем (ИС). Умело спроектированная и внедренная ИС существенно улучшает управляемость предприятия и повышает эффективность его работы. Однако исследования свидетельствуют о том, что лишь около 40% проектов внедрения ИС являются успешными [1, 2]. Остальные же попытки автоматизации либо длятся годами, не принося ожидаемого эффекта, либо полностью сворачиваются. Это обусловлено в первую очередь тем, что современные проекты настолько сложны, что в 80% случаев в процессе создания и внедрения ИС требования к функциональности многократно меняются и уточняются, а также дополняются совершенно новыми блоками, о которых ничего не было известно на начальном этапе [3]. В большинстве случаев не выясненный до конца функционал продукта проекта приводит к многократному увеличению реальных трудозатрат, что, в свою очередь, вызывает непонимание и конфликт между сторонами [4].
Дополнительная сложность заключается в установке заказчиком жестких сроков реализации проекта, хотя зачастую далеко не все подразделения предприятия-заказчика готовы к внедрению ИС. Компенсацию низкой квалификации персонала также приходится закладывать в функционал проекта, реализовывая в дальнейшем рабочие места, не требующие высокой квалификации пользователей [5,6].
Недостаток начальных условий на стадии инициации проекта усугубляет одну из самых распространенных проблем управления ИТ-проектами -расплывчатое целеполагание со стороны заказчика. Чаще всего на этапе реализации, оно приводит к срыву сроков и выходу за рамки установленного бюджета.
Анализ последних исследований и публикаций. Широкий спектр задач, требующих использования ИС, обусловил появление большого разнообразия программных продуктов, решающих те или иные прикладные задачи [7]. Вследствие этого, как заказчик, так и проектировщик ИС сталкиваются с неясностью и многозначностью. Понимание этого, а так же множество неудач при внедрении ИС, послужило катализатором появления новых методологий и стандартов проектирования, разработке программных средств автоматизированного проектирования [8-10].
Один из идеологов науки управления Том Питерс обращает внимание на то, что в современной компании необходимо управлять именно проектами, а не процессами или функциями. На сегодняшний день происходит смена традиционной системы управления, подходящей для крупных, однородных и независимых друг от друга проектов, на концентрическую систему контуров управления проектами. В значительной мере этот процесс обусловлен возросшей в конкурентной борьбе ценой ошибки и необходимостью более тесного взаимодействия людей, команд и подразделений внутри компании.
Эту же идею развивают Хироши Танака и С.Д. Бушуев, предлагая следующие контуры: сценарный подход, процессный подход, проектный подход, системный подход. Ими разработаны модели формирования видения проекта «Облако», когда виден силуэт продукта и результата, но не видны элементы системы, «Туман» - видны силуэты отдельных элементов и не видны контуры системы [11].
Анализ типичных ошибок, приводящих к провалу проекта разработки ИС, позволил выделить 3 группы рисков [12-15]. Это риски связанные с:
- функционалом и конфигурацией ИС;
2
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
- компетентностью команды по внедрению;
- предприятием, на котором происходит внедрение.
Исследования показывают, что на многих предприятиях процесс принятия решений протекает в условиях неопределенности, а его успешность зависит от адекватности и своевременности анализа поступающей информации [16].
Выделение не решенных ранее частей общей проблемы. Широко применяемые методы разработки, зародившиеся еще в 80-х годах, предполагают, что объект проектирования адекватно описан, а так же построены полные и непротиворечивые функциональные модели ИС.
Современные, не только производственные, но и торговые фирмы генерируют большое количество сложных бизнес-процессов, которые должны многоступенчато взаимодействовать между собой. Поэтому построение адекватной модели объекта проектирования является сложной задачей.
Остается открытым вопрос, как на этапе инициации помочь заказчику принять решение о методе разработки и внедрения ИС, который бы максимально соответствовал ресурсам, которыми располагает заказчик.
Целью статьи является анализ окружения ИТ-проектов создания корпоративных ИС на стадии инициации проекта для поддержки принятия решений.
ОСНОВНЫЕ РЕЗУЛЬТАТЫ
Методы и методики исследования. В исследовании использовались сравнительный и дисперсионный анализ, метод балльного ранжирования и составления рейтинга, методы экспертных оценок: мозговой штурм; метод Дельфи; метод балльной оценки риска.
Для доказательства адекватности применялась методика оценки согласованности мнений экспертов.
Изложение основного материала исследования. Участникам, вовлеченным в сферы проектного управления, крайне важно учитывать особенности предметной области ИТ-проектов, выявленные при исследовании опыта их реализации на постсоветском пространстве:
- высокий уровень рисков;
- политизированность;
- необходимость корректировки бизнес-процессов и реорганизации предприятия до начала внедрения ИС;
- изменение содержания работ на любом из этапов реализации проекта;
- вовлечение исполнителей в реализацию нескольких проектов;
- отсутствие единого видения целей автоматизации среди различных ветвей руководства;
- ориентация на внедрение готовых ИС;
- ожидание мгновенного экономического эффекта от внедрения ИС.
Крупными фирмами-разработчиками программного обеспечения было
создано множество базовых программных продуктов, обеспечивающих хранение данных и доступ к ним, а также содержащих набор регламентированных функций, приведенных в соответствие с текущей законодательной базой выбранного региона. На первый взгляд, сталкиваясь с отсутствием ясности видения концепции ИС у заказчика, наиболее целесообразным было бы воспользоваться одним из готовых бизнес-решений. Однако при проведении более глубокого анализа всплывает ряд особенностей готовых решений для корпоративных ИС:
- отсутствие типовых решений для большинства специализированных областей;
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
3
- высокая стоимость настройки программного продукта под нужды конкретного предприятия даже при относительно низкой стоимости базовой оболочки;
- высокие требования к техническим характеристикам не только серверной, но и клиентской части аппаратного обеспечения;
- необходимость привлечения высококвалифицированных специалистов как для настройки и адаптации приобретенного ПО, так и, возможно, для дальнейшего администрирования и эксплуатации, что существенно повышает затратную часть при реализации и сопровождении ИС;
- недостаточная гибкость настройки системы при проявлении специфики предметной области;
- отсутствие или недостаток возможностей для интеграции с другим, специализированным ПО.
В итоге, стремление разработчиков отраслевого ПО максимально обобщить функциональность ИС, сделав ее подходящей для любой компании, приводит к тому, что нужды ни одной из компаний не удовлетворяются на 100%. Для компаний из сферы малого бизнеса типовое решение перегружено излишним функционалом, а представители среднего бизнеса сталкиваются с невозможностью полностью подстроить систему под некоторые специфические аспекты деятельности.
Таким образом, непродуманное внедрение готовых ИС может дать совершенно обратный эффект: рост затрат, ухудшение производительности труда, текучесть кадров.
Влияние внешнего окружения проекта, было проанализировано относительно основных этапов - центров затрат (V). Результат представлен в табл. 1 по пятибалльной шкале для 5 параметров проекта адаптации готовой ИС: инвестиции ^),затраты человеческих ресурсов время реализации(1) и уровень риска
Таблица 1
Оценка затрат и рисков при использовании готового ПО
Этап проекта S H T R
V Описание V Описание V Описание V Описание
Выбор и 2 Есть 1 Для подбора ПО 1 Анализ 5 Неправильно
покупка относительно достаточно одного предлагаемых выбранное ПО не
базовой программной оболочки недорогие российские АСУ специалиста продуктов не больше недели будет обладать необходимым функционалом
Первичная 4 Большинство 2- Затраты времени 2- Затраты времени 3 Возможно, в
настройка фирм держат штат специалистов по настройке 3 снизятся при привлечении стороннего специалиста и увеличатся при использовании внутреннего специалиста 3 зависят от того, привлекается ли сторонний специалист процессе работы потребуется изменение первичных настроек
Интеграция с 3 Возможна как 3 Требуется 3 Затраты зависят 3 Возможно,
другим ПО покупка дополнительных драйверов, так и обновление ПО привлечение большого круга ИТ-специалистов: программистов, системных и сетевых администраторов от специфики ПО возникнут сложности с интеграцией, вплоть до покупки нового ПО
Модернизация 5 Возможна 4 Требуется 4 Возможно 3 Риск торможения
или замена покупка крайне привлечение потребуется работы и потери
4 "УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
текущего ПО и АО дорогостоящего АО: сервера, линейки памяти, хранилища большого круга ИТ-специалистов: программистов, системных и сетевых администраторов, инженеров сектора поддержки длительное время для организации закупки и последующей настройки оперативности при использовании устаревшего ПО и АО
Обучение персонала 1 Фирмы- производители обычно предоставляют видео-курсы или преподавателя с курсом лекций 2 Потребуется внутренний менеджер по организации обучения и сторонний специалист-лектор 2 Разработать график учебного процесса, провести обучение 4 Качественно проведенное обучение существенно снизит количество дальнейших вопросов
Регламентное обновление 2 Потребуется периодическая покупка или продление подписки на обновления 1 Достаточно одного специалиста 23 Обновления как правило не успевают за изменением законодательной базы и выходят с опозданием 3 Риск потери функционала, который разработчики посчитали несущественным
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
5
Дальнейшая 4- Зависит от 3 Возможно 3- Код типовых 4 Низкая
настройка и 5 объемов привлечение 1-2 4 программных масштабируемость
разработка разработки штатных оболочек обычно системы затрудняет
сотрудников или плохо процесс разработки
сторонних масштабируем
разработчиков
Проведенный анализ показал, что при внедрении готовой ИС потребуются значительные денежные затраты на фоне достаточно быстрого запуска в режиме тестирования.
Альтернативой является разработка системы «с нуля», которая обеспечит заказчику необходимый уровень функциональности и качества. Однако традиционные модели управления проектами в этом случае неприменимы, поскольку отсутствует полное техническое задание и расплывчато сформулированы даже начальные требования, что приводит к невозможности создания WBS-структуры проекта. Анализ информации о проектах подобного рода позволил идентифицировать следующие причины неудач:
- разница в видении продукта проекта между заказчиком и разработчиками, которая впоследствии приводит к конфликтам при сдаче проекта;
- неясная расстановка приоритетов или их хаотическая смена;
- появление новых требований или замена первоначальной концепции модулей;
- сложность или невозможность составления расписания процесса разработки;
- конфликты и саботаж пользователей при внедрении;
- текучесть кадров среди разработчиков.
Выбор альтернативного варианта проекта выполним аналогично, воспользовавшись предложенным алгоритмом относительно основных этапов -центров затрат в разрезе S, ^ T и R. Результат представлен в табл. 2.
Таблица 2
Оценка затрат и рисков при использовании разрабатываемого ПО
Этап проекта S H T R
V Описание V Описание V Описание V Описание
Выбор среды разработки 2 Затраты на покупку лицензионных копий 1 Решение обычно принимает менеджер проекта 2 Выбор среды зависит от стороннего ПО, с которым придется интегрироватьс я 2 Разработчики как правило знакомы с особенностями выбранного инструментария
Первичное изучение предметной области 1 Затраты включены в оплату рабочего времени 3 Вовлекаются программисты 2-3 Зависит от специфики предметной области 2 Слишком поверхностное изучение помешает правильно спроектировать систему
Согласовани е основных требований к функционалу 2 Возможно потребуются услуги сторонних фирм для разработки технического задания 2 Участвует менеджер проекта и представители заказчика 3 Зависит от четкости представления заказчиком целей автоматизации 3 Добавление нового функционала приведет к росту затрат и увеличению продолжительности разработки
6 "УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
Составление 2 Оплачивается 4 В идеале 3 Практика 4 Неправильная
графика рабочего рабочее время разработчиков участвует вся проектная показывает, график расстановка приоритетов
процесса и команда с необходимо приведет к
расстановка менеджером и все время затягиванию
приоритетов представители заказчика корректировать процесса
Процесс разработки и 5 Услуги профессионал 5 Участвует проектная 5 Процесс разработки при 5 Возможен рост затрат и
внедрения ьных разработчиков высоко ценятся команда с менеджером отсутствии четкого технического задания растягивается по времени растягивание сроков при существенных изменениях технического задания
Обучение 2 Обычно 1 Достаточно 2 Разработка 4 Некачественное
персонала выделяется один из разработчиков одного-двух человек графика, проведение обучения, написание документации обучение увеличит количество ошибок при использовании ПО и затормозит работу системы
Дальнейшая 3 Услуги по 3 Для 4 Выявление и 3 Ошибки этапа
разработка и сопровожде сопровождени ю менее сопровождения требуется исправление ошибок может разработки могут затруднить
ние затратные меньшее количество персонала занять длительное время дальнейшее сопровождение
Анализ показал, что для варианта разработки собственной ИС больше всего необходим временной ресурс, при относительно невысоких денежных затратах.
Предложенный подход позволяет выполнить количественное сравнение показателей альтернативных вариантов проекта на основе средних значений S, К T и R. Результат сравнения приведен в табл. 3.
Таблица 3
Сравнительная таблица показателей для альтернативных подходов
Вид ИС в Н Т
Готовая 3.14 2.43 2.86 3.57
Разрабатываемая 2.43 2.71 3.14 3.29
Полученные результаты используются на этапе инициации проектов создания корпоративных ИС. В результате менеджер проекта совместно с заказчиком должны принять решение о выборе альтернативного варианта в соответствии с конкретными условиями внешнего окружения и ресурсами, которыми располагает заказчик.
ОБСУЖДЕНИЕ
Обоснование полученных результатов. Предложенный подход поддержки принятия решений в проектах создания корпоративных ИС на стадии инициации базируется на: экспертном методе качественной оценки рисков; дисперсионном и сравнительном анализе; модели «Облако» при которой видны только контуры проекта, а внутренняя часть не видна или не известна.
Для получения результатов на основе методов коллективных и индивидуальных экспертных оценок использовалась унифицированная пятибалльная шкала, которая дает возможность в дальнейшем оперировать средним арифметическим.
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
7
Коэффициент конкордации Кендалла оценки согласованности мнений 5 экспертов составил 0,72, что свидетельствует о высокой согласованности мнений. Поэтому полученные результаты достоверны и адекватны и могут в дальнейшем использоваться на практике.
Сравнительная информация из таблицы 3 свидетельствует о том, что оба альтернативных варианта подвержены достаточно высокому уровню рисков, которые придется минимизировать в процессе управления проектом.
Потребность в человеческих ресурсах находится на среднем уровне, причем при внедрении готовой ИС в основном привлекаются внешние специалисты.
Выводы. Предложена процедура поддержки принятия решений в проектах создания корпоративных ИС на стадии инициации.Показана ее адекватность.
Проведенный сравнительный анализ позволил определить значимость каждого из видов ресурсов, необходимых для запуска проекта автоматизации предприятия, что позволит заказчику сформировать более четкое видение о характере будущих затрат, на основании чего он сможет принять решение о выборе подхода к автоматизации.
Проанализирован уровень рисков на каждом из этапов разработки и внедрения для альтернативных вариантов автоматизации.
Перспективы дальнейших исследований. Перспективой дальнейших исследований является разработка подхода формирования видения проекта создания корпоративной ИС в условиях слабо формализованного окружения.
ЛИТЕРАТУРА
1. Гагарский, В.А. Проблемы внедрения корпоративных информационных систем [Текст] / В.А. Гагарский// Журн. «Дело», 2009. - №12. - С. 58-63.
2. Миславская, Е.С. Особенности управления ИТ-проектами в России [Текст] / Е.С. Миславская // Управленческий учет и финансы, 2010. - №4. - С. 7-12.
3. Москалюк, А.Ю. Особенности управления инициацией проектов в рамках системы управления охраной труда [Текст] / Москалюк А.Ю., Тесленко П.А., Федунец П.Д. // Восточно-европейский журнал передовых технологий. - Харьков: "Технологический центр", 2012. - № 1/13 (55). - С. 36-38.
4. Боковой, Ю. В. Особенности методологии проектирования информационных систем для малого и среднего бизнеса [Текст] / Ю.В. Боковой // Прикладная информатика, 2006. - №5. - С.3-11.
5. Тесленко, П.А. Информационная конструк^я оболочки базы данных / П.А. Тесленко // Науковi записки Мiжнародного гумаштарного ушверситету: Збiрник / Пщ ред. д.т.н., проф. Рибака А.1. - Одеса: Мiжнародн. гумашт. ун-т, 2008. - Вип.13: Серiя "УправлЫня проектами та програмами". - С. 100-104.
6. Тесленко, П.А. Концепция информационного конструирования систем [Текст]/ П.А. Тесленко, В.Д. Гогунский // Тези доповщей мiжнародноí конференций Управлшня проектами в умовах глобалiзацií знань. - К.: КНУБА, 2008. - С. 100-102.
7. Ананьин, В.И. К конкурентному преимуществу - через проекты [Текст] / В.И. Ананьин // Управление проектами и программами, 2010. - №3. - С. 12-24.
8. Математические основы управления проектами [Текст]: учеб.пособие / Баркалов С.А., Воропаев В.И., Секлетова Г.И. и др.; под общ. ред. В.Н. Буркова. - М.: Высш. шк., 2005. - 423 с.
9. Балдук, Г.П. Автоматизация процессов коммуникаций в оперативном управлении участниками проекта [Текст] / Балдук Г.П., Тесленко П.А., Балдук П.Г. // Восточноевропейский журнал передовых технологий. - Харьков: "Технологический центр", 2012. - № 1/13 (55). - С. 21-23.
10. Кент, Б. Экстремальное программирование [Текст] / Б. Кент. - СПб: Питер, 2002. -224 с.
11. Бушуев, С.Д. Креативные технологии в управлении проектами и программами [Текст] / Бушуев С.Д., Бушуева Н.С., Бабаев И.А. и др. - К:. Саммит книга, 2010. - 768 с.
8
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
12. Макаров, Д.А. О факторах риска в процессе разработки программного обеспечения [Текст] / Макаров Д.А., Розенберг М.Я., Шильников А.Б. // Вестник ЮУрГУ, 2009. -№ 37(170). - С. 85-92.
13. Тесленко, П.О. Прийняття ршень в умовах вартюних обмежень проекту [Текст]/ П.О. Тесленко // УправлЫня розвитком складних систем: Зб.наук.пр. - К.: вид-во КНУБА, 2012. - Вып. 9. - С. 40-43.
14. Орлов, А.И. Теория принятия решений: учеб. пособ. [Текст] // А.И. Орлов. - М.: Издательство "Март", 2004. - 656 с.
15. Ramsin, R. Process-Centered Review of Object-Oriented Software Development Metodologies[Текст] / R. Ramsin, R. Paige // ACM Computer Surveys, 2008. - V.40, №1. -P. 35-42.
16. Москалюк, А.Ю. Подготовка информации о состоянии предприятия для инициации проектов по охране труда [Текст]/ А.Ю. Москалюк, П.А. Тесленко // Управлшня проектами: Стан та перспективи: Матерiали 8-Т Мiжнародноí науково-практичноТ конференцп. - МиколаТв: НУК, 2012. - С. 129-131.
Рецензент статт Стаття надмшла до редакцп
Д.е.н., проф. Сахацький М.П. 10.02.2014 р.
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
9
