Предпринимательская ценность ИТ для бизнеса

(Опубликовано в журнале “Экономика и жизнь” №41 октябрь 2011)
Ананьин В.И.
Преподаватель кафедры
"Системы управления бизнес-процессами".
Школа IT-менеджмента
РАНХиГС при Президенте РФ
V.Ananiin@gmail.com

Бизнес вкладывает в ИТ большие средства. А какова отдача от таких инвестиций и как ее оценить? Однозначного ответа пока нет. Существует широко распространенная точка зрения, что ценность ИТ для бизнеса определяется выгодами от ИТ проекта в стоимостном выражении (увеличение дохода или снижение затрат, или ROI). Но это упрощенный подход. В чем же ценность ИТ для бизнеса? Чего ждет бизнес от ИТ и как достичь желаемого? Когда ИТ проект оказывается эффективным? Попробуем разобраться.

Существует различные подходы к определению ценности ИТ. Ценность – всегда субъективная оценка того, кто принимает решение об ИТ проектах применительно к своим задачам. Например, для топ-менеджеров корпоративные ИТ помогают реализовать стратегические цели и планы бизнеса, снизить риски, получить выгоды. Инвесторы ожидают рентабельность проекта для своевременного получения отдачи от вложенных денег. Менеджерам среднего уровня важно обеспечить качественный уровень поддержки бизнеса в рамках определенного бюджета. Для продавцов/консультантов – продвижение и продажа своих продуктов и услуг.
Для предпринимателя ценность ИТ для бизнеса состоит в ответе на вопрос зачем ему нужны ИТ. Ему нужны ИТ проекты не сами по себе, они – лишь инструмент, который бизнес использует для создания и увеличления стоимости. Ему нужна коммерциализация изменений в бизнесе, которые производят эти проекты. Предпринимательскую ценность для него представляют только те изменения, которые поддерживают его существующие конкурентные преимущества и развивают новые. Поэтому бизнес ждет от ИТ прежде всего не столько расчета точных цифр, склько плана коммерциализации ИТ-инициатив. Главным инструментом такой коммерциализации является коммерческая бизнес модель (КБМ). Рассмотрим ее.

Коммерческая Бизнес Модель

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

1. Кто заказчик моего продукта?
2. Какую ценность я для него создаю? Как он собирается использовать мой продукт? За что он мне будет платить?
3. Как эта ценность должна создаваться, или какова цепочка создания этой ценности?
4. Как я смогу извлечь прибыль из этого (п. 1 - 3)?
5. Как я смогу защитить созданную мною ценность и свою прибыль от конкурентов? То есть в чем мои конкурентные преимущества?
6. Как все это (п. 1 - 5) работает на мою стратегию развития?

Ответы на первые пять вопросов “крупными мазками” определяют за счет чего живет бизнес. А на шестой вопрос ответ бизнес отвечает лишь иногда, потому что не всегда имеет внятную стратегию своего бизнеса.
КБМ это не какое-то новое изобретение, это широко распространенная давняя практика в среде бизнес предпринимателей [1]. Приведенные вопросы являются основными в любом бизнес – плане. Именно они, прежде всего, интересуют инвесторов. Именно они превращают идеи в инновации.
Проект – это форма реализации перехода от старой КБМ к новой. Новая КБМ и проект соотносятся как ожидаемый результат и способ его достижения. В ИТ проектах КБМ описывает механизм формирования и поддержки конкурентных преимуществ бизнеса с помощью ИТ. Именно в этот механизм должны быть встроены методики оценки бизнес-эффекта от инвестиций в ИТ, именно там они начинают приобретать индивидуальную для каждой компании конкретику. Предпринимателю, когда он начинает новый проект, важна не точная оценка того, СКОЛЬКО он на этом заработает, а точное понимание механизма КАК он это заработает. В условиях высокой неопределенности возможны лишь общие, грубые оценки, основанные на здравом смысле, а не на изощренных методиках. КБМ – это не методика оценки идей, а правило их коммерциализации. Детально прописанная КБМ (механизм коммерциализации инициативы) позволяет детализировать эту оценку, ее моделирования и, главное, возможность итерационного контроля того, движемся ли мы в нужном направлении при реализации этой инициативы.
Для бизнеса использование КБМ – привычная практика. Распространение ее на ИТ позволяет построить диалог CIO с бизнесом на привычном для бизнеса языке. Чем выше уровень бизнес-руководителя, чем больше он погружен в предпринимательство, тем лучше он понимает язык КБМ. А чем ниже уровень, тем большее значение для него приобретает язык бизнес-процессов регламентов и показателей. Это не просто разные языки, это разные картины мира.
Чем более сильные конкурентные преимущества бизнес хочет получить от ИТ, тем более радикальными и масштабными должны быть изменения в самом бизнесе. Но они всегда будут связаны с большими затратами, сроками и, главное, рисками для бизнеса. Бизнес и ИТ-службы должны быть готовы к тому, что при реализации, например, системных изменений не удастся обойтись небольшим набором управленческих практик. Может потребоваться целый арсенал. Одного классического управления проектами будет недостаточно, придется осваивать программное а, возможно, и портфельное управление проектами. При этом ИТ проект может выступить в роли своеобразного стимулятора других бизнес проектов, которые и дадут основные эффекты.
Для проведения изменений на практике часто привлекают внешних подрядчиков. Тем не менее, уже в случае системных изменений бизнес и ИТ-службы должны быть готовы к тому, чтобы брать в свои руки управление ИТ-проектами, сопряженные с высокими рисками. Чем радикальнее изменения, тем в большей степени ИТ-проекты превращаются в бизнес проекты, и тем большее значение приобретает конструктивный диалог между руководителями ИТ служб (CIO) и топ-менеджментом. И в этом диалогекрайне важно найти компрмисс между ЗАЧЕМ и КАК внедрять и использовать ИТ.

Радикальность изменений

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

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

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

Улучшения

Рассмотрим проект внедрения отдельного модуля Управления Финансами системы класса Управление ресурсами предприятия (ERP) в финансовой службе завода серийного производства электродвигателей. Проект внедрения ведет внешний подрядчик системный интегратор.
У заказчика изменения затрагивают изменения КБМ только в пункте модели формирования прибыли (пункт 4 табл. 2). В серийном материальном производстве сокращение сроков подготовки финансовой отчетности лишь косвенно влияет на общие показатели бизнеса.
Таблица 2. Изменений КБМ заказчика при локальных изменениях

Достижение результата ИТ проекта зависит от обеих сторон: привлекаемого подрядчика и заказчика. Поэтому для эффективной организации управления проектом необходимо рассматривать и КБМ подрядчика. Рассматриваемый проект близок к типовому [2], вся его неопределенность связана с обеспечением необходимыми ресурсами (пункт 4, табл. 3). Управление таким проектом хорошо ложится, например, на стандарт Project Management Body of Knowledge (PMBoK) [3]. Если ситуация на рынках заказчика в перод ИТ проекта стабильна, риски данного проекта будут минимальными.
Таблица 3. КБМ локального проекта для подрядчика

Изменения могут быть еще более локальными. В этом случае проект не открывают, а управление осуществляется своми силами в рамках моделей управления изменениями, например, как в управлении ИТ сервисами [4].

Системные изменения

Рассмотрим более сложный проект - комплексное внедрение ERP системы на том же предприятии. Внедрение ориентировано на постановку сквозного планирования всей цепочки: снабжение – запасы – производство – сбыт на базе модели планирования MRP [5]. Проект ведет тот же системный интегратор.
Изменения для заказчика носят системный характер и затрагивают практически все аспекты его КБМ (пункты 2-6 табл. 4).
Таблица 4. Изменение КБМ заказчика при системных изменениях

Системные изменения очень рискованны не только для заказчика, но и для подрядчика. Для таких изменений нужны очень сильные стимулы, например, борьба за выживание или лидерство. При реализации системных изменений в движение приходит все, и есть только две точки опоры. Одни зи них - понимание кто является заказчиком, вторая - заказчик и исполнитель должны стать стратегическими партнерами (пункты 1 и 6 табл. 5). Остальные пункты КБМ – зоны, в которых постоянно появляется неопределенность, и их приходится постоянно заново выстраивать в течение всего проекта.
Таблица 5. КБМ комплексного проекта для подрядчика (пример)

Системные изменения в бизнесе невозможно осуществить помощью одного проекта. В нашем примере внедрение ERP системы – всего лишь первый проект комплексной программы развития, предполагающей реализацию проектов по упорядочиванию и нормированию производства, а возможно и его модернизации, по построению новых партнерских схем работы с контрагентами, а также по развитию персонала и организации. Приведенные проекты тесно связаны между собой и остановка одного из них может привести к остановке всей программы. На управление такими формами организации ориентированы стандарты управления программами, например, стандарт PMI [6]. Не многие системные интеграторы решаются на такие рискованные проекты далеко выходящие за пределы ИТ компетенций.

Радикальные изменения

Радикальные изменения рассмотрим на примере создания и выведения на рынок новой поисковой системы Google. Период 1998 (стартап) – 2002 (получение прибыли) [7].
В середине 90-х годов многие, в том числе, очень крупные компании, занимались разработками поисковых систем для Интернета. Двумя молодыми аспирантами была изобретена новая технология поиска, которая позволяла с очень высокой скоростью и релевантностью овущетсвлять поиск по нечетким запросам пользователей в сверх больших объемах данных. Но успех этого проекта был не столько в новой технологии, сколько в изобретенной новой КБМ. Данная технология позволила Google создать технологию продвижения рекламы по инициативе самих пользователей. Для этого Google создал свою уникальную КБМ (табл. 6), которая стала коммерческой основой двух дополняющих друг друга сетей: рекламодателей и издателей рекламы (партнеров Google). Поскольку результат проекта - создание нового бизнеса по предоставлению нового сервиса продвижения рекламодателями своего контента в интернет, КБМ бизнеса и проекта его создания совпали (табл. 6).
Таблица 6. КБМ радикальных изменений

Радикальные изменения крайне рискованны и все шесть пунктов КБМ являются зоной высокой неопределенности и рисков. Проекты по реализации подобных изменений не укладываются в классические стандарты управления проектами. В стандартном управлении проектами ключевые параметры: заказчик проекта, цели и способы их достижения четко определены и не меняются, а в данном случае - они плохо определены и постоянно меняются.  Управление такими проектами реализуются в рамках экстремального управления проектами [8] и является областью венчурного (высоко рискованного) бизнеса [1].
Однако не каждый экстремальный проект приводит к  радикальным изменениям. Даже типовой проект неумелыми действиями его участников можно превратить в экстремальный. В этом случае КБМ не меняется, и типовой проект останется, как и был, простым улучшением, но в экстремальном исполнении.

Литература

• Котельников В. “Новые бизнес модели для новой эпохи быстрых перемен, движимых инновациями”, Москва, Эксмо, 2007
• Ананьин В.И. “В поисках “правильного” стиля ИТ проекта”, Журнал Управление проектами Март 2007 № 1 (6).
• “A guide to the Project Management Body of Knowledge”, 2004 Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
• “IT Infrastructure Library v. 3. Service Operation”, 2007, OGC, UK
• Гаврилов Д.А. "Управление производством на базе стандарта MRP II", СПб, Питер, 2005.
• “The Standard for Programm Management” 2006 Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
• "Бизнес-обзор. Корпоративная информация. Google" http://www.google.ru/intl/ru/corporate/business.html
• Дуг ДеКарло, “Экстремальное управление проектами”, ред. А. Баженов, А. Арефьев, p.m.Office, Москва, 2005