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

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

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

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

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

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

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

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

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

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

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

Может ли таким процессом стать процесс управления изменениями модели ITIL/ITSM? Нет, не может. Прежде всего потому, что он относится к изменениям в инфраструктуре ИТ, тогда как здесь изменения могут касаться и сферы бизнеса. Далее, искомый процесс должен обеспечить как можно большие выгоды бизнеса, тогда как цель процесса управления изменениями — повышение устойчивости среды ИТ при внесении изменений. Соответственно, владелец процесса в первом случае представляет бизнес, во втором — информационную службу. Наконец, контроль проекта тесно связан с управлением проектом, тогда как управление изменениями связано с ним лишь в отдельных контрольных точках. Таким образом, контроль проектов — это отдельный процесс со своими целями и владельцами.

Процесс как таковой

Итак, вопрос о целесообразности дальнейшей деятельности возникает несколько раз на протяжении жизненного цикла проекта. Соответственно, процесс контроля проектов разбивается на несколько стадий (рис. 2).

На стадии запуска оценивается инициатива проекта — документ, обобщающий ключевую информацию, необходимую для начала проекта на надежной основе, и доводящий ее до всех лиц, имеющих отношение к возможному проекту (термин «проектная инициатива», или Project Initiation Document, PID, применяется в методологии управления и контроля проектов PRINCE2; в других методологиях фигурируют документы «устав проекта» и «определение проекта». — Прим. ред.). Результаты оценки суммируются в документе, который мы будем называть паспортом проекта. В случае, если:

  • у PID есть бизнес-заказчик;
  • PID предполагает реализацию четко определенной потребности бизнес-заказчика;
  • определен перечень выгод, которые получает заказчик от удовлетворения потребности;
  • бизнес-заказчик или его руководитель готовы финансировать реализацию PID и имеют для этого бюджет;
  • потребность не может быть удовлетворена посредством существующих ИТ-услуг;
  • риски со стороны заказчика понятны и приемлемы;
  • принимается решение о реализации этой проектной инициативы. Последняя в этом случае становится проектом. Если принятие окончательного решения требует дополнительной информации, проектная инициатива приостанавливается и назначается дата рассмотрения вопроса с полным объемом необходимой информации (стрелка «Уточнить» на рис. 2). Наконец, если потребность нечетко сформулирована, бизнес-заказчик отсутствует или не располагает необходимым бюджетом, проектная инициатива закрывается (стрелка «Закрыть» на рис. 2).

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

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

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

На стадии проектирования создается модель бизнес-процессов «как должно быть» и прототип ее реализации средствами информационной системы. Ключевые ИТ-услуги встраиваются в бизнес-процесс, одновременно с этим определяются вспомогательные ИТ-услуги, несущественные с точки зрения выгод бизнеса, но необходимые для работы процесса. Ряд рисков со стороны заказчика и подрядчика могут реализоваться, что может привести к остановке или закрытию проекта. Поскольку на этой стадии затраты в несколько раз больше, чем на предыдущей, такой ход событий нежелателен. Чтобы его избежать, необходимо более тщательно учитывать выгоды и риски на стадиях запуска и выбора.

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

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

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

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

Наконец, стадия использования начинается с момента передачи проекта в эксплуатацию. Здесь решаются две задачи. Первая — полная реализация выгод проекта. В ходе работы над проектом (стадии выбора, проектирования, выполнения) многие требования заказчиков просто не могут быть удовлетворены. Модель бизнес-процесса «как должно быть» обычно включает лишь необходимый минимум форм и отчетов, без которых процесс неработоспособен. Постепенное выполнение пожеланий заказчика возможно после передачи проекта в эксплуатацию при сравнительно небольших затратах. Контроль проектов должен обеспечить ресурсы, необходимые для такой реализации выгод.

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

Процесс контроля проектов и модель TVO

Эффективность процесса контроля проектов значительно возрастает при использовании модели оценки совокупной ценности возможностей (Total Value of Opportunities, TVO) [1, 2] или подобных ей моделей.

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

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

На рис. 3. представлено наполнение модели TVO по стадиям процесса контроля проектов в разрезе отдельных «столпов» (pillar). Степень заполнения прямоугольника означает долю необходимой информации, собираемой на данной стадии процесса (нарастающим итогом).

Для иллюстрации заполнения данных модели TVO в процессе контроля проектов рассмотрим пример из практики. В крупной компании внешние консультанты разработали модель расчета стратегических сценариев развития. Совершенная и сложная модель с большим количеством параметров была реализована в виде системы электронных таблиц. Расчет сценария при этом занимал длительное время и заканчивался успешно примерно в 50% случаев. Общее время расчета составляло две-три недели, что ограничивало число рассматриваемых сценариев и, как следствие, пригодность самой модели для поставленных перед ней задач.

В этой ситуации возникла проектная инициатива переноса модели с Microsoft Excel на иную, более развитую специализированную платформу. На стадии оценки было выявлено следующее:

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

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

В силу специфики проекта наиболее ответственной стала фаза выбора, на которой были определены платформа и поставщик решения. Для этого были уточнены функциональные требования к системе, разработан тестовый пример и подготовлен запрос предложений (Request for Proposal, RFP) в рамках стандартной процедуры выбора контрагента. Запрос был разослан заранее определенному списку поставщиков. Ответы были получены по платформам Cognos Enterprise Planning, Hyperion Analyzer и Oracle Financial Analyzer. По каждому решению были рассмотрены один или несколько поставщиков. По критерию соответствия функциональным требованиям (включая требования тестового примера), наличия опыта внедрения в России и совокупной цены решения была выбрана платформа Cognos Enterprise Planning.

В ходе анализа была получена следующая информация по модели TVO:

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

Оценка окупаемости не проводилась, так как выгоды проекта с самого начала рассматривались как нефинансовые.

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

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

Синергический эффект

Совместное использование модели TVO и процесса контроля проектов обеспечивает синергический эффект: целое превосходит по эффективности сумму своих частей. К источникам дополнительного эффекта можно отнести:

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

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

Литература
  1. Скрипкин К. Основы модели TVO // Директор информационной службы, 2005, № 6.
  2. Эпфел О. TVO на подступах // Директор информационной службы, 2005, № 6.

Кирилл Скрипкин — директор департамента ИТ-планирования и взаимодействия с бизнесом компании СУАЛ, доцент кафедры экономической информатики экономического факультета МГУ, k.skripkin@sual.com