ИТ-проекты, не забывайте для чего они нужны!

Дерябин А.Б.

Deryabin-AB@energodata.ru

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

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

Приквел: эффективность ИТ-проекта для заказчика и исполнителя.

Очень часто звучат слова про эффективность проекта, про эффективность управления бюджетом проекта, про контроль показателей эффективности. Как же создается и из чего складывается «эффективность»?

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

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

Важнейшими объективными факторами, определяющими правила взаимодействия являются:

1. Существующая процедура формирования инициативы и инициация соответствующего проекта, или другими словами процедура согласования и утверждения инициативы.

2. Показатели и алгоритмы их оценки, их применимость, их гибкость, их объективность.

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

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

Основная сюжетная линия: темп выполнения и снижение затрат как приоритетные параметры.

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

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

Другой важнейший параметр – темп инициации ИТ-проекта и создания целевого решения. Огромные ресурсы тратятся не на генерацию идей, не на подготовку внутренних документов, и даже не на создание дополнительных серверных мощностей, а на процедуру согласования по заинтересованным сторонам и… «обязанными быть заинтересованными» сторонами. Действительно заинтересованные стороны, как правило, подходят с активной или даже проактивной позицией и быстро согласуют «нужные» и эффективные инициативы или наоборот отсеивают невостребованные или «сомнительные прожекты». В этом случае можно использовать принцип «20 на 80»^[2]. На любом крупном предприятии всегда будет борьба при проведении процедуры согласования, ведь даже при наличии обоснованной заинтересованности и поддержки у функционального заказчика какого-либо проекта всегда будут противники или даже просто конкуренты на бюджет. Таким образом, опять же самым эффективным и быстрым способом является создание и выполнение относительно небольших проектов, цена ошибки по которым будет сполна компенсироваться за счет экономии средств путем упрощения процедур согласования, как при инициации проекта, так и при его выполнении и приемке.

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

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

Сиквел: оценка эффективности ИТ-решения.

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

1. Прямое влияние на финансово-хозяйственную деятельность предприятия.

2. Снижение рисков автоматизируемого бизнес-процесса.

3. Изменение трудозатрат.

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

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

Для оценки снижения рисков можно использовать один из экономико-статистических методов, например, в случае финансового риска можно использовать простейшую формулу:

где DR — уровень соответствующего финансового риска, PR — вероятность возникновения данного финансового риска, SL — размер возможных финансовых потерь при реализации данного риска.

Для измерения трудозатрат в автоматизированном режиме можно рассмотреть использование продуктов класса BPM^[3]. В данном случае наглядно видна трудоемкость каждой операции бизнес-процесса и легко можно сравнить трудозатраты до и после внедрения ИТ-решения.

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

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

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

Мидквел и спин-офф: другой подход или «чужой против хищника».

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

Экономим ресурсы ... Вместо долгого анализа других известных всем подходов будет приведен только план/логика данного раздела:

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

2. Сделать вывод, что нужно делать большие проекты, так как они дают сразу существенный прорыв и эффект.

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

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

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

Просто заключение

Как бы вы не делали ИТ-проекты не забывайте для чего это все делается!

[1] Рассматриваем ИТ-проекты в крупных организациях, которые, как правило, привлекают подрядчиков на выполнение ИТ-проектов.

[2] В наиболее общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата».

[3] BPM (Business Process Management, управление бизнес-процессами) — концепция процессного управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям. Примерами программных продуктов класса BPM: SAP NetWeaver Process Orchestration, IBM Business Process Manager, Pegasystems BPM.