Как успешно “продать” ИТ-проект бизнесу

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

Обычная практика

По сведениям Марка Шиллера, 95% CIO вынуждены настойчиво уговаривать своих бизнес-коллег принять участие в презентации ИТ-проекта руководству компании. Как правило, на словах бизнес-коллеги поддерживают проведение инноваций, но когда доходит до дела, они предпочитают держаться в стороне, оставляя CIO в одиночестве.

Опрошенные нами ИТ-руководители не вполне разделяют данную точку зрения. “Создается впечатление, что CIO работают в неком враждебном коллективе”, — сказал заместитель генерального директора по ИТ-агентства “Руссколлектор” Александр Богаченко. По его словам, ИТ-директору, конечно, часто приходится одному доказывать необходимость запуска того или иного проекта. Многие проекты лежат исключительно в плоскости ИТ, и привлечение смежных подразделений к их защите может вызвать законное недоумение. Однако если речь идет о другого рода проектах, то все заинтересованные подразделения прямо или косвенно должны и реально участвуют в процессе их обоснования и защиты. Но вот если инициатива внедрения, допустим, CRM-системы идет только со стороны ИТ-подразделения, то такой проект обречен на провал из-за естественного сопротивления или просто бездействия смежных подразделений, уверен г-н Богаченко.

Сходную позицию занимает директор Центра дополнительного профессионального образования (ЦДПО) МФТИ Евгений Колесников, который считает, что, как правило, бизнес-коллеги понимают свою часть хорошо, поэтому нет необходимости их в чем-то убеждать: “Самое правильное, что следует делать CIO, — это организовывать референс-визиты и показывать уже выполненные работоспособные проекты, на примере которых можно убедить руководство в успехе дела”.

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

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

Второй подход более простой, динамичный. Сначала кто-либо из представителей бизнеса выражает свое пожелание (например, установить новое ПО или увеличить тот или иной ресурс) ИТ-руководителю, который изучает техническую сторону запроса и необходимость его реализации “здесь и сейчас”. Помимо этого вступают в силу субъективные симпатии или, наоборот, антипатии ИТ-руководителя к “бизнес-просителю”. Далее составляется служебная записка, в которой обосновывается обязательность совершения тех или иных затрат для реализации проекта для бизнеса. И здесь чаще всего в ответ возникает волна “негатива”, причем последующие объяснения, что это нужно не ИТ-подразделению, а бизнесу, чаще всего не приносят успеха. Так что и этот путь, по мнению Олега Белова, не лишен недостатков: “Если повезет, всё происходит легко и быстро, но при этом любые затраты субъективно относятся на счет ИТ-подразделения”.

В отличие от этой оценки директор отдела ИТ DHL Express в странах СНГ и Юго-Восточной Европы Геннадий Столяров, основываясь на своем опыте работы в компании, утверждает, что презентация ИТ-проектов руководству не представляет проблем и не отнимает значительных ресурсов. По его словам, это объясняется тем, что ИТ в DHL Express — полноценная бизнес-функция, без которой не может эффективно работать ни одно подразделение. От информационных систем, например, напрямую зависят наиболее критичные показатели операционной деятельности и контакт-центра, поэтому для всего топ-менеджмента необходимость в постоянном совершенствовании ИТ-инфраструктуры очевидна, и доказывать ее не приходится. Все новые проекты (относящиеся не только к ИТ) обсуждаются всем советом директоров, когда они уже в достаточной степени проработаны: выбраны платформа, поставщик, просчитан бюджет.

Следующий момент, по мнению Марка Шиллера, заключается в том, что большинство CIO ошибочно считают, что “продавать” ИТ-проекты руководству — это необходимая часть их работы. При этом он убежден, что истоки такого подхода кроются в том, что ИТ-служба рассматривается бизнесом преимущественно как обслуживающее подразделение. Следовательно, для того чтобы реализовать крупный, сложный, бизнес-ориентированный проект (например, внедрение ERP-, CRM- или BI-системы), CIO нужно заручиться активной поддержкой бизнес-коллег, что получается далеко не всегда.

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

Александр Богаченко уверен, что большинство подразделений совершенно объективно рассматривают ИТ-службу как сервисную структуру, однако руководство и проектный институт должны понимать, что помимо этого она выполняет роль новатора и генератора идей, а также служит мощным инструментом оптимизации бизнес-процессов. “И если руководство этого не осознает, то последствиями станут стагнация в ИТ и медленные темпы развития бизнеса (если тот сильно зависит от ИТ), — убежден он. — Я считаю, что если бизнес-коллеги не заинтересованы в ИТ-проектах, выгодных в первую очередь им самим, то за такие проекты не стоит и браться”.

С этим мнением согласен и Олег Белов, по словам которого ИТ-подразделение, хотя и является обслуживающим, но при этом оно не лишено голоса и способно к саморазвитию: “Если ваши проекты не нужны никому, то, значит, они не нужны и вам. А вот по какой причине отвергнут тот или иной проект развития, решать вам — может быть, вы не нашли нужного аргумента или недооценили затратную часть”.

Позиция Игоря Клопотова по данному вопросу заключается в том, что если функциональные стратегии могут формироваться относительно независимо друг от друга, то ИТ-стратегия служит своеобразным связующим звеном и формируется параллельно соответствующим функциональным стратегиям. Соответственно не должно существовать каких-либо инфраструктурных проектов в отрыве от бизнес-целей. “Даже если мы реализуем такие явно затратные проекты, как строительство дублирующего ЦОДа или резервирование магистрального канала, это прежде всего решение задачи поддержки непрерывности ведения бизнеса, а не строительство ради строительства”, — подчеркнул он.

Что нужно делать

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

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

Для проведения изменений Марк Шиллер предлагает построить следующую иерархию ИТ-проектов (ИТ-инициатив) в зависимости от их критичности для компании и соответственно с учетом уровня поддержки со стороны бизнес-менеджеров:

Обратимся к оценкам опрошенных нами ИТ-руководителей. По мнению Игоря Клопотова, в “нормальных”, динамично развивающихся и прибыльных компаниях данный подход реализуется уже много лет. Согласно нему каждая заявка на ИТ-проект (еще на этапе подготовки) проходит экспертную оценку и по ней уже выставляются числовые показатели для каждого из целевых ориентиров.

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

Данную точку зрения разделяет и Александр Богаченко, по словам которого введение дополнительной метрики к свойствам проекта является, безусловно, хорошей идей, однако, как следует из его опыта, такая метрика так или иначе уже имеется во многих компаниях: “Конечно, именно с такой градацией проектов я еще не встречался, но в любой нормальной компании существует некое деление проектов на необходимые, доказуемо выгодные, выгодные “по ощущениям” и инновационные (экспериментальные). Если же нет, нужно вводить предложенную или аналогичную по смыслу систему градации”.

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

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

Например, руководитель бизнес-подразделения подает запрос на ИТ-новшество, после чего ИТ-руководитель должен детально проработать данный запрос на трудозатраты, финансовые вложения, возможные скрытые издержки, а также кратко прописать ожидаемый эффект. Отдельной статьей обязательно следует указать издержки обслуживающего ИТ-подразделения и его реальные ресурсы, способные реализовать проект. Затем вся эта информация отправляется обратно бизнесу, а уже оттуда — главному руководству. Именно при таком сценарии развития, как убежден Олег Белов, ИТ-подразделение не является “паровозом” затрат, четко обозначает свои позиции и в итоге всегда в плюсе.

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

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

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

Что это дает

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

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

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

Однако Евгений Колесников убежден, что бюджет — не самое главное мерило успешности ИТ: “Важнее всего отношение бизнеса, который хочет развиваться и активно использовать ИТ в своем развитии”. Причем в сложные времена отношение к инициативам лучше и их охотнее слушают, если в них есть разумное зерно.