Ррпнгг. Учебное пособие СанктПетербург 2014 2 Оглавление
 Скачать 0.86 Mb.
|
|
2.5.2. Метод прикладной информационной экономики – AIE (Applied Information Economics) Метод прикладной информационной экономики являет собой вариант комплексного подхода к оценке эффективности проектов, систем и процес- сов бизнеса. Он был разработан Дугласом Хаббардом, руководителем кон- салтинговой компании Hubbard Ross, и позволяет повысить точность показа- теля «действительная экономическая стоимость вложений в технологии безопасности за счет определения доходности инвестиций» (ROI) до и после инвестирования. Применение AIE дает возможность сократить неопределен- ность затрат, рисков и выгод, в том числе и неочевидных. Эта методология объединяет достижения теории опционов, современной теории управления портфелем активов, традиционных бухгалтерских подходов (к которым от- носятся, прежде всего, NPV, ROI и IRR) и некоторых статистических мето- дов, с помощью которых можно выразить неопределенность в количествен- ных оценках, построить кривую распределения ожидаемых результатов, оце- нить риск и возврат на инвестиции. Для этой методологии характерен очень большой объем расчетов, но при оценке эффективности дорогостоящих про- ектов AIE является удобным и статистически верным способом анализа рис- ков. Кроме того, использование AIE (как и ряда других) осложняется тем, что она является ноу-хау консультационной компании, следовательно, ком- пания, пожелавшая использовать AIE для оценки своих ИТ-проектов, должна обратиться к разработчику или компаниям, имеющим лицензию на право ис- пользования AIE. 75 2.5.3. Перерасчет финансовых показателей с учетом риска Управление рисками охватывает весь цикл проекта – от подготовки до завершения, но наиболее важным (особенно в контрактах с фиксированными сроками и стоимостью) будет правильная и «честная» оценка будущих рис- ков на стадии подготовки проекта. Практика показывает, что игнорирование или несерьезное отношение к оценке рисков до начала работ может приво- дить к серьезным последствиям в ходе выполнения проекта. Заметим, что до- вольно часто работа по идентификации рисков, их определению в договоре возлагается на руководителя проекта со стороны компании – консультанта по внедрению системы, в то время как Заказчик не уделяет этим аспектам доста- точного внимания, полагая, что его ответственность ограничена финансовы- ми обязательствами по контракту. На самом деле, эта работа должна прово- диться совместно и итеративно. В этом плане полезно, если проекту внедре- ния ERP-системы предшествует этап бизнес – диагностики или разработки ИТ-стратегии, так как уже заранее часть наиболее важных рисков может быть определена и учтена. После первичной идентификации рисков необходимо оценить параметры этих рисков. Оценка таких параметров риска, как вероятность его возникновения (от пренебрежимо малой до значительной) и последствия для проекта (от незначительных – т.е. не приводящих к значимым изменениям в сроках, результатах и бюджете проекта до катастрофических, когда реализация проекта вынужденно прекращается). Каждый из этих параметров оценивается на основании экспертного мнения, например по 5- балльной шкале, а значимость риска прямо пропорциональна величине вероятности и последствиям. q q R P I , (23) где R – индекс риска (баллы); P q – вероятность возникновения рисков в соответствии с классификацией (баллы); 76 I q – величина потерь в соответствии с классификацией риска (баллы). После определения данного индекса риска производится корректировка фининсовых показателей, таких как ROI или IRR и NPV. С поправкой на уровень риска может быть пересчитана ставка дисконтирования, используемая для определения доходности проекта. К ней, как правило, прибавляется так называемая премия инвестору за риск, то есть более рисковые проекты должны иметь более высокую доходность. Это же можно отнести и к показателю ROI. В таблице 1 приведены рекомендуемы поправки данного финансового показателя в зависимости от индекса риска. Таблица 1. Рекомендуемые поправки значений ROI с учетом интегральных рисков ИТ-проекта Суммарная балльная оценка рисков (0-100) Поправка на риск, % 0-10 0 11-20 10 21-30 20 31-40 30 41-60 40 >60 50 Говоря о рисках с сфере ИТ, необходимо отметить особый характерный для этой сферы риск. В инновационной сфере вообще и в особенности в высокотехнологич- ных отраслях промышленности (таких как разработка и внедрение информа- ционных систем) существует специфический инновационный риск – риск невнедрения, реальная опасность отрицательных экономических и социаль- ных последствий, когда инновация не используется или же инновационный 77 процесс затягивается на неопределенное время, «цена» которого может в ре- зультате оказаться выше, чем потери от внедренческих рисков. Рассматривается также концепция, которая предлагает рассчитать до- ход от внедрения информационной системы как величину обратную потерям, связанным с отказом от внедрения, за вычетом затрат. Хотя в явном виде данный риск нигде не рассматривается, в том или ином виде он должен быть учтен всегда, в том числе и как критерий разум- ности производимых компанией затрат. Полезно также сравнить риски, связанные с отказом от внедрения раз- личных вариантов ИС для выбора того, который наилучшим образом удовле- творит потребности предприятия. 3. Современные тенденции в оценке эффективности ИС В этой главе дана характеристика некоторых новых методик оценки эффективности ИС, а также рассмотрены проблемы выбора метода оценки эффективности для конкретных ИТ-проектов и влияние архитектурного под- хода к созданию ИС, обеспечивающего высокий уровень эффективности ИТ- проектов. 3.1. Современные методики оценки эффективности ИС 3.1.1. Расчет совокупной ценности возможностей TVO (Total Value of Opportunities) Метод расчета совокупной ценности возможностей разработан в 2003 году компанией Gartner Group в развитие метода ТСО для большей полноты отражения экономических результатов внедрения информационных систем. Достоинство этой методики – в высокой гибкости, позволяющей приспосо- бить ее к различным уровням управления в организации и к различной отно- сительной значимости финансовых и нефинансовых факторов. В модели TVO оценка ИТ-деятельности ведется по пяти направлениям: соответствию 78 стратегии бизнеса, воздействию на бизнес-процессы, непосредственной оку- паемости, архитектуре и степени риска. Соответствие стратегии (Strategic Alignment) – степень, в которой рассматриваемый ИТ-проект способствует достижению стратегических це- лей организации. Базовая схема анализа соответствия стратегии включает в себя оценку текущих значений показателей, описывающих стратегию, оцен- ку их целевых значений с точки зрения стратегии и оценку их целевых зна- чений в рассматриваемом проекте. Предполагается, что соответствующие показатели известны и надлежащим образом утверждены. Так, в компании «Прагматик экспресс» стратегия состоит в повышении уровня сервиса – процента товарных позиций (компания торгует канцеляр- скими товарами по каталогу), которые могут быть отгружены заказчику в те- чение одного дня. Инструментом повышения уровня сервиса стала в том числе заказная система, позволяющая отследить исполнение заказа с момента его приема до получения товара от службы доставки. Это позволило сокра- тить число ошибок комплектации в два раза. Такого рода ошибки прямо влияют на уровень сервиса, поскольку их исправление часто занимает более одного дня. Воздействие на бизнес-процессы (Business Processes Impact) – влияние ИТ-проекта на результативность и эффективность бизнес-процесса или про- цессов. Под результативностью понимают предельные возможности данного процесса — время выполнения, процент качественной продукции, необходи- мый уровень запасов и т. д. Под эффективностью — соотношение результата и затрат: затраты на единицу продукции, выход продукции на единицу сырья, выработку на одного занятого и т. д. Эти две группы показателей связаны между собой, но не идентичны. Архитектура – внедряемое ИТ-решение должно соответствовать су- ществующей в организации среде ИТ. Значительное отклонение отдельно взятого решения от стандартных для организации аппаратных и программ- 79 ных платформ ведет к повышению TCO решения и технических рисков про- екта. Проблемы архитектуры следует понимать с надлежащей степенью общности, т.е. выходя за рамки аппаратной и программной совместимости. Соответствие решения по архитектуре подразумевает в числе прочего наличие в ИТ-службе или в организации, осуществляющей аутсорсинг, спе- циалистов, способных сопровождать данное решение ИТ. Более мягкий ва- риант этого требования – наличие таких специалистов на рынке. О соответствии ИТ-решения существующей архитектуре предприятия можно судить по следующим показателям: поддержка имеющихся бизнес-процессов организации; поддержка текущих и/или перспективных стандартов; соответствие текущим и/или перспективным требованиям к инфор- мационной безопасности; наличие в распоряжении организации специалистов по сопровожде- нию данного решения, при отсутствии — возможность найма такого специалиста; наличие интерфейсов для обмена информацией со стандартными информационными системами организации; возможности миграции данных из существующих информационных систем; соответствие процессам информационной службы и др. Риск – пятый и последний столп экономической оценки ИТ-проекта. Под риском здесь понимается вероятность наступления событий, неблаго- приятных для достижения цели ИТ-проекта и/или соблюдения установлен- ных сроков и бюджета. В случае ИТ-проектов эта вероятность весьма велика. Модель обладает рядом достоинств, нехарактерных для большинства конкурирующих моделей. Во-первых, это адаптивность, возможность при- способления к текущему состоянию управленческого учета в организации. 80 Во-вторых, возможности настройки на приоритеты бизнеса организации. В- третьих, модель выступает как интегрирующая платформа, позволяющая объединить результаты, полученные с помощью различных моделей: моде- лей денежного потока, вероятностных и качественных. Следует отметить следующие существенные недостатки методики: Информационная насыщенность модели TVO. Разносторонняя оценка проекта требует сбора и обработки большого объема информации. Работы в этой области ложатся дополнительным бременем на заказчиков и руководителей проекта, что вызывает понятное сопротивление тех и других. Интеграция сбора данных с существующими процессами управления. Как показывает практика, работник может собирать и передавать с приемлемой точностью только те данные, с которыми он работает постоянно. Если же сотрудникам организации вменить в обязанность собирать данные, стоящие вне существующих процессов управления, точность этих данных будет неприемлемо низка даже при отсутствии сопротивления. Получение дополнительной информации в ходе ИТ-проекта. В начале проекта информация о его воздействии на бизнес-процессы, о соответствии архитектуре, а также о большинстве его рисков недоступна. 3.1.2. Методика расчета совокупного экономического эффекта TEI (Total Economic Impact) Метод расчета совокупного экономического эффекта предназначен для поддержки принятия решений, снижения рисков и обеспечения «гибкости», то есть ожидаемых или потенциальных преимуществ, остающихся за рамками анализа преимуществ и затрат (cost-benefit analysis). TEI включает четыре фундаментальных элемента: стоимость, преимущества, гибкость и риск ИТ-проектов – охватывая как финансовые, так и нефинансовые аспекты разработки, развертывания и поддержки корпоративных ИС. 81 «Стоимость» вычисляется по методике «Совокупная стоимость владе- ния» (TCO) и является единственной количественной оценкой данной мето- дики. «Преимущества» и «Гибкость» есть оценки качественные. «Преимущества» позволяют судить о соответствии возможностей вне- дряемого продукта или компонента информационной системы требованиям проекта внедрения. Дополнительные возможности, которые появятся в рабо- те сотрудников предприятия по итогам внедрения такого компонента или продукта должны быть оценены, как с точки зрения повышения эффективно- сти работы, так и по их влиянию на выявленные операционные и технологи- ческие риски. «Гибкость» рассматривается как показатель, характеризующий слож- ность процесса внедрения. Т.е. оцениваются затраты, которые нужно понести на «включение» нового компонента в информационную систему предприятия – потребуется ли переделка всей системы предприятия ввиду внедрения но- вого компонента, достаточны ли возможности по настройке компонента для подключения его к существующей системе, потребуется ли адаптация такого компонента и так далее. Завершающий шаг методики TEI – анализ рисков, возникающих в про- цессе приобретения, внедрения и эксплуатации анализируемого компонента информационной системы. Очевидно, что методика TEI имеет достаточно узкий спектр примене- ния. Ее можно использовать для анализа вариантов внедрения какого-то оп- ределенного компонента ИТ-инфраструктуры предприятия. Например, при выборе банком скоринговой системы от разных производителей. Методология TEI особенно удобна при анализе двух различных сцена- риев (например, приобретение готового ПО или его разработка своими сила- ми), если они сопряжены с построением инфраструктуры или реализацией других корпоративных проектов, преимущества и недостатки которых оце- нить сложно. 82 Завершающий шаг методики TEI – анализ рисков, возникающих в про- цессе приобретения, внедрения и эксплуатации анализируемого компонента информационной системы. Очевидно, что методика TEI имеет достаточно узкий спектр примене- ния. Ее можно использовать для анализа вариантов внедрения какого-то оп- ределенного компонента ИТ-инфраструктуры предприятия. Например, при выборе банком скоринговой системы от разных производителей. 3.1.3. Метод быстрого экономического обоснования REJ (Rapid Economic Justification) Метод быстрого экономического обоснования предложен корпорацией Microsoft и, подобно TEI, предусматривает конкретизацию модели TCO за счет установления соответствия между расходами на ИТ и приоритетами бизнеса. Пятиступенчатый процесс требует разработки бизнес-плана, отра- жающего мнение всех заинтересованных сторон и учитывающего основные факторы успеха и ключевые параметры эффективности; совместной прора- ботки влияния технологии на факторы успеха; анализа критериев стоимо- сти/эффективности; определения потенциальных рисков с указанием вероят- ности возникновения и воздействия каждого из них; вычисления стандарт- ных финансовых показателей. Методология REJ наилучшим образом подхо- дит для управления отдельными проектами, а не их портфелем. Аналитики и пользователи отмечают такие возможности REJ, как оценка состояния бизне- са, анализ рисков и совместимость с TCO. Однако, несмотря на «быстроту», присутствующую в названии, процедура REJ может оказаться достаточно продолжительной. Методика REJ включает пять последовательных этапов: привязка целей и ключевых показателей ИТ-проекта к бизнес-целям орга- низации (этот этап имеет много общего с методикой BSC); 83 выбор решения по перечню «требуемых возможностей», во многом сов- падающих с критерием «Преимущества» методики «Совокупный эконо- мический эффект» (TEI); оценка прибыли и затрат с использованием методики «Совокупная стои- мость владения» (TCO); оценка рисков проекта по критериям соответствия выбранного решения исходному проекту, внедрения выбранного решения, его эксплуатации и финансовому риску; расчет финансовых показателей проекта внедрения с привлечением мето- дик вычисления «Чистого приведенного дохода» (NPV), «Внутренней нормы доходности» (IRR), «Экономической добавленной стоимости» (EVA), «Отдачи от инвестиций» (ROI) и других. Методика REJ не только помогает найти общий язык ИТ-специалистам и бизнес-менеджменту, она представляет собой наглядный инструмент, по- зволяющий оценить вклад ИТ в бизнес-результат компании. Методика REJ является наиболее сложным и комплексным инструмен- том оценки проекта внедрения ИТ-решения. Она не может эффективно оце- нивать проекты преобразования ИТ-инфраструктуры в целом. 3.2. Выбор методики оценки эффективности ИС На основании анализа всех перечисленных методик и подходов можно сделать достаточно простой вывод. Абсолютно все методы определения эко- номической эффективности имеют определенные достоинства и недостатки, поэтому использования одного из методов может, как не дать результата во- все, так и, дав какой-либо результат, привести к ошибочным управленческим решениям. Таким образом, очевидна необходимость использования комплек- са методов. Комплекс этих методов зависит от точки зрения на разрабатываемую систему, параметров самой системы, выбора типового решения и проектиро- 84 вания уникальной системы, размера бизнеса компании, целей и этапа вне- дрения и так далее. Прежде всего, предприятие должно разработать некую качественную шкалу показателей, определяющую основные потребности пользователей, решать конкретные задачи. И, следовательно, система должна в первую оче- редь строго соответствовать целям разработки и срокам разработки, так с те- чением времени потребности бизнеса имеют свойство изменяться. Для этого подойдет некая система качественных показателей, которая сможет отразить достигнутые цели. Основная проблема определения эффекта – выявления связи между собственно эффектом и деятельностью ИС, то есть руководство должно четко отдавать себе отчет в том, за счет чего получен эффект. Не меньшую сложность представляет и определения стоимостной оценки эффекта, поэтому, чем прозрачнее и понятнее будет методика такого определения, тем больше у предприятия шансов на успешное внедрение и функционирование системы. В качестве инструмента такого качественного анализа возможно использование методик сбалансированных показателей или функционально-стоимостного анализа (ABC). Метод ФСА логичен и на- гляден, предоставляет конкретные результаты в доступной форме. Возмож- ности BSC шире по охвату неэкономических эффектов, трудно поддающихся стоимостному анализа, однако эта система требует большей интерграции с управленческим учетом предприятия и вероятность принятия неверного ре- шения на ее основе велика. Так или иначе оцененный эффект нужно соотнести с затратами, так как для любого проекта затраты не должны превышать тот результат, ради кото- рого они производятся. Затратную часть проекта можно оценить по-разному. Самым распро- страненным методом оценки затрат является методика оценки совокупно стоимости владения, так как данная методика позволяет оценить не только 85 разовые капитальные затраты при создании ИС, но и возникающие затраты на всем пути жизненного цикла системы. Если результат, полученный от реализации проекта, и затраты на него удалось оценить в стоимостном выражении и в сопоставимом виде, то проект по внедрению ИС можно рассматривать как полноценный инвестиционный проект и оценку сопоставления результатов и затрат лучше делать по одному из классических инвестиционных методов, таких как ROI. Такая оценка позволит привлечь потенциального инвестора, повысит уровень доверия к проекту со стороны руководства и поможет наладить взаимопонимание между финансовыми менеджерами и ИТ-специалистами. На принципиальное решение о внедрении ИС, а также на выбор одного из вариантов системы должен оказывать влияние и анализ рисков. Среди рисков невыполнения сроков, превышения бюджета и несоответствия систе- мы требованиям организации целесообразно рассматривать также и риск от невнедрения системы, то есть риск потери конкурентоспособности, престижа компании и риск упущенной выгоды от более рационального управления и повышения производительности труда. Несомненно, предприятие должно установить приемлемый уровень риска, так как затраты на внедрение ИС велики. Возможно, предприятие на данном этапе своего развития не может позволить себе такие затраты при та- ком уровне риска, и от внедрения полноценной корпоративной информаци- онной системы стоит отказаться, ограничившись так называемым «коробоч- ным» решением, одним модулем, постепенно дополняя его остальными. Контроль разработки, бюджета и сроков внедрения должен быть доста- точно жестким, поэтому после принятия решения о запуске проекта необхо- димы методики жесткого контроля всех условий, на этом этапе возможно ис- пользования методик проектного управления. В заключение хочется отметить, что вероятность возникновения эф- фекта от применения информационных систем резко повышается, если у ме- 86 неджмента предприятия уже есть заинтересованность в использовании ин- формационных технологий и неважно, для решения каких-либо конкретных задач, например, оптимизации работы склада, или общих задач повышения эффективности бизнеса, главное, что это понимание существует. Идеальный вариант, когда проекты по созданию и развитию ИТ встроены в комплекс стратегических мероприятий компании, направлены, наряду с другого рода мероприятиями (например, мероприятиями по замене технологического обо- рудования, внедрения системы менеджмента качества, повышения маркетин- говой активности и т.д.), на достижение стратегических целей компании. Необходимо помнить, что информационная система не дает эффекта сама по себе, все зависит от правильности ее использования. В связи с этим в послед- нее время меняется роль и ИТ-службы предприятия от чисто обслуживающе- го подразделения и реальному и эффективному инструменту управления бизнесом. Переход к сервис-ориентированным принципам организации ин- формационного обслуживания предприятий в рамках модели ITSM позволяет более точно оценивать не только затраты на создание и эксплуатацию ИС, но и экономические результаты использования ресурсов таких систем. |