Обоснование инвестиций в ИТ: подкуп или шантаж?

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

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

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

И там, и там есть картинка, иллюстрирующая два типа отношений: 

И в дополнение к комментариям Дмитрия я рискну написать следующее: в зависимости от того, как распределяется в этой системе ответственность и организуются коммуникации, меняется область нанесения бизнесу пользы и снижения вреда:

Вариант 1:

Вариант 2:

Соответственно, во втором случае любые инвестиции в операционный блок будут направлены либо на снижение рисков, либо на оптимизацию затрат, в то время как заметные бизнесу улучшения будут уделом проектной части (в схеме Дмитрия — разработчиков ПО).

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

Все это кажется мне сейчас очевидным и довольно банальным, но я помню, как еще недавно оно таким не казалось. На случай, если и вам не кажется — делюсь. 

 

PRINCE2 Управление ИТ-проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс с интерактивным кейсом.
 

Узнайте больше!

Комментарии и мнения

  1. Pavel Solopov

    Не совсем всё так, по моему мнению.

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

    1. Роман Журавлёв Автор

      Снизить — могут, конечно. Устранить — нет.

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

      В то время как и бизнес, и ИТ, бывает, ждут именно такого обоснования. 

        1. Роман Журавлёв Автор

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

          1. Pavel Solopov

            Главное тут не форма организации цепочек, а умение ИТ  директора играть словами.

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

            1. Роман Журавлёв Автор

              Павел, вы ведь наверняка сходили посмотреть и вебинар, и статью Дмитрия, правда? форма организации не отменяет сервисов, но влияет на их определение. Вот, например, как они могут быть определены в ярко выраженной технологической цепочке, где за функциональность отвечают одни, а за эксплуатацию — совем другие: "Оказание услуг по эксплуатации и сопровождению автоматизированных банковских систем..." Это, конечно, услуги, но для бизнеса они интересны именно как средство снижения рисков, и ни в коем случае не как источник дополнительных преимуществ. 

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

              1. Pavel Solopov

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

                В тоже врем в другой схеме вполне может идти речь про создание, эксплуатацию и сопровождение.

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

                Не мечь должен подстраиваться под самурая, а самурай должен учиться владеть мечём.

    1. Роман Журавлёв Автор

      Ну,Альберт, упрощенность и оторванность свойственны любой модели... И все же: в чем проявляется оторванность от реальной жизни в данном случае? И в чем влияние окружающей среды в данном случае? Что именно она диктует? Расскажите поподробнее, пожалуйста.

        1. Роман Журавлёв Автор

          Мы говорим про обоснование расходов на ИТ, в частности — тех, что воспринимаются бизнесом как инвестиции. И принципиальные решения о том, какие именно расходы на ИТ будут требовать обоснования и управляться как инвестиции — действительно забота IT Governance. Но обосновывать их в конкретном случае приходится тем менеджерам, которые на картинке в ISO — и на моей картинке тоже — работают в части management, причем нередко только в правой ее половинке.


          И все же — о каком влиянии среды вы писали в предыдущем комментарии?

          1. Альберт

            Под влиянием среды подразумевается то что обозначено на схеме как Business Pressures и Business Needs. Здесь включаются такие вещи как конкуренция, изменения в регулировании рынка, интересы акционеров и т.д. То что иногда приходится заниматься этими вещами IT менеджерам, это понятно. Важно что-бы они в этот момент умели переключиться из своей роли менеджера, в роль бизнес партнера.

            Немного расширенную версию можно посмотреть на стр. 5

            http://www.sysaudit.gr.jp/public_comment/ISO-IECJTC1_N10998_Text_of_2nd_PDTR_38502__Governance_of_IT_.pdf

            Как пример можно посмотреть здесь:

            http://csbapp.uncw.edu/mis213/02/2-3.html

             

  2. Анатолий Павлюченко

    Не совсем всё так, по моему мнению. © by Pavel Solopov 🙂

    Скажу сразу, что я ЗА "шантаж"! По той простой причине, что в бюджете любой достаточно крупной организации затраты на ИТ настолько не сопоставимы с другими статьями, исключая чистые "откатные" схемы, что всякое обсуждение "копеек" выглядит само по себе неубедительно. Про потенциальные прибыли вообще молчу. Да, всё равно, хорошо бы рисовать ROI и TCO. Но намного проще привязать большие цифры потенциальных потерь от "не внедрения", чем создать реалистичную измеримую "финансовую отдачу" в случае "внедрения для ...". Возможно, это как-то пересекается с первым комментарием Альберта про "оторванность от реальной жизни"...

  3. Дмитрий Исайченко

    Мне кажется, в данной дискуссии не хватает контекста (как и в попытке провести ORBIT не для конкретной организации, а абстрактно – для того или иного процесса). Оттого выводы, делаемые сторонами, столь спорны. Смотрите сами:

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

    - Приоритеты ИТ-преобразований лучше всего определяются исходя из соответствия / не соответствия бизнес-стратегии.

    Дальше простые сценарии (исключительно для примера):

    1. Стратегия компании – захват нового рынка. Что нужно от ИТ – переварить быстрый рост, пусть даже чисто экстенсивный. Обоснование проектов – возможность заработка новых денег (или упущенная возможность – при отказе от трансформации), пусть даже в ущерб операционной эффективности.

    2. Стратегия компании – привлечение клиентов на существующих рынках за счет вывода новых, может быть инновационных продуктов. Что нужно от ИТ – иметь максимально быстрый конвейер реализации изменений (основной KPI – Time To Market, TTM). Путь даже где-то в ущерб стабильности и скорее всего операционная эффективность также не приоритет (инновации вообще не дружат с операционной эффективностью). Обоснование проектов – так же возможность заработка новых денег.

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

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

    Кому интересно, эта тема очень неплохо представлена в методике Gartner Total Value of Opportunity (TVO).

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26