Я очень часто повторяю, что бизнес хочет от ИТ-службы (да и от любой своей функции) всего трех вещей: чтобы она приносила пользу, чтоб не приносила вреда и чтоб делала это недорого. В очередной раз обсуждая эту простую формулу с участниками курса про COBIT, неожиданно связал ее в голове с вечной проблемой обоснования инвестиций в ИТ, и все в очередной раз стало ясно, стройно и понятно. И опять не без участия Дмитрия Исайченко.
Действительно, бизнес нередко требует от ИТ-менеджеров обоснования инвестиций в терминах ожидаемого роста прибыли или других подобных прелестей – даже когда обсуждаемые инвестиции направлены на сопровождение действующей инфраструктуры или, скажем, совершенствование ИТ-процессов. В то время как ИТ-менеджеры вместо того, чтобы покупать благосклонность бизнеса обещаниями улучшений, предпочитают пугать страшными потерями в случае невыделения запрашиваемых сумм.
А связано это с тем, как организовано взаимодействие бизнеса и ИТ в течение жизненного цикла услуг. Об этом замечательно и неоднократно рассказал Дмитрий – сначала в вебинаре, замаскированном под рассказ об управлении измененями, а потом в статье про каталог услуг.
И там, и там есть картинка, иллюстрирующая два типа отношений:
И в дополнение к комментариям Дмитрия я рискну написать следующее: в зависимости от того, как распределяется в этой системе ответственность и организуются коммуникации, меняется область нанесения бизнесу пользы и снижения вреда:
Вариант 1:
Вариант 2:
Соответственно, во втором случае любые инвестиции в операционный блок будут направлены либо на снижение рисков, либо на оптимизацию затрат, в то время как заметные бизнесу улучшения будут уделом проектной части (в схеме Дмитрия – разработчиков ПО).
В первом все немного сложнее: улучшения некоторых ИТ-процессов, например, могут сказаться и на способности ИТ-службы приносить пользу.
Все это кажется мне сейчас очевидным и довольно банальным, но я помню, как еще недавно оно таким не казалось. На случай, если и вам не кажется – делюсь.
Не совсем всё так, по моему мнению.
Если например не вкладываться в качественную разработку (организацию процессов разработки, тестирования, документирования), то никаие вложения в поддержку не смогут снизить риски от сложной в поддержке услуги переполненной ошибками.