Ловушки согласования бизнеса и ИТ

Читая один из материалов MIT Sloan Management Review (ссылку на конкретную статью я дам ниже), невольно вспомнил как 14 лет назад, прийдя на работу в РОСНО и начиная заниматься в тандеме с Федором Кожевниковым* автоматизацией бурно развивавшегося добровольного медицинского страхованием (ДМС), столкнулся с достаточно сложной ситуацией:

Задача, поставленная отделом оформления страховой документации звучала как крайне , почти катастрофически срочная - сотрудники этого отдела уже практически не успевали справляться с подготовкой полисов страхования и необходимо было в кратчайшие сроки создать программу печати полисов. Я начал заниматься этой задачей. Благо, руководитель группы оформления страховой документации был человек очень разумный (и как менеджер, и как человек) и начальник ИТ-отдела, ставший в дальнейшем известным российским CIO и входившим в совет директоров РОСНО не только умел делегировать полномочия, но и доверял сотрудникам. Так вот - конечно, можно было "просто" взять и написать программу, которая при вводе соответствующих данных выводила бы на бланки полисов и дополнительных документов всю информацию в необходимом формате. Дело, вроде бы несложное (ну да - DOS, прерывания там всяческие, да еще PCL 5 для лазерника ;)

Однако, анализировав вместе с руководителем группы оформления необходимую для печати информацию (а она сильно зависела от типа договора страхования и т.п. - вы чувствуете, да? ;), мы пришли к выводу - по сути для печати надо было вбивать большую часть информации по договорам. Ок. Но договора корректируются, бывают ошибки в наборе данных.... - в общем, врубившись в бизнес-процесс, я рискнул упереться. Как говориться - "по полной". Моя позиция, в которой я убедил и руководителя группы оформления и руководителя ИТ-отдела, - надо делать программу управления договорами и уже как ее составную часть - печать полисов и доп.документов к ним. Первоначально, ни о какой системе управления договорами никто не хотел слышать - зачем она - у нас и так шаблоны Лексикона (был такой популярный русский редактор) тут? "Не надо самим себя занимать работой над непонятно какой системой, когда нужна печать полисов." Я оценил объем работы, прослезился - получалось +2.5-3 месяца от требуемой даты задания на печать полисов. Но, пошел убеждать с цифрами в руках - система управления договорами нужна бизнесу, информация - та же, дублировать ввод в разные системы в дальнейшем - глупо. Динамика изменений в модели добровольного мед. страхования - очень высокая. Но при автоматическом формировании номера и серии полиса, всегда все зависит от договора, это обсуловлено природой бизнеса ДМС. и т.п. И таких примеров зависимостей очень много.

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

Первая версия подсистемы управления договорами (в дальнейшем - ключевая часть "Системы ДМС" РОСНО) была готова через 3.5 месяца, включая разработку и дизайн нового формата полисов и алгоритм автоматического формирования их номеров и серий. Второе поколение подсистемы договоров (с новым ядром, работавшим уже в защищенном режиме DOS) была введена в эксплуатацию где-то через 8 месяцев, а окончательно выведена из повседневной работы... в начале следующего века.

Выводы, ради которых я рассказал эту историю (читая материалы бизнеса-школ, так и хочется сказать - кейза ;-) :

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

А это и есть настоящее согласование ИТ с целями бизнеса - Business-IT Alignment. Заметьте - целями бизнеса, а не текущими бизнес-задачами. Пойди я тогда на поводу классического запроса "надо срочно", могу с уверенностью (вполне) сказать , компания понесла бы дополнительные затраты (поверьте - считали: намного большие, чем дополнительные три месяца ручной работы по оформлению полисов) уже через несколько месяцев после ввода в эксплуатацию автономной программы печати полисов. Конечно, любой кейз, и этот, в частности, - достаточно схематичны. Но, надеюсь, некоторые важные аспекты согласования бизнеса и ИТ мне удалось проиллюстрировать на этом примере не только на уровне явно озвученных выводов.

В какой-то степени, в продолжение своего же недавнего поста, одной фразой о согласовании бизнеса и ИТ это можно переформулировать так: It's about business. But about IT too. Но надо четко понимать, что "it's about business" <> "it's not about technology", хотя последнее - "это ведь не о технологиях!"- часто можно услышать на конференциях, где выступают представители многих маститых вендоров. Кстати, на эту тему вот неплохая статья Эндрю МакКаффи из Harvard Business School:

• The Impact of Information Technology (IT) on Businesses and their Leaders
  

А вот, наконец, и материал, который заставил меня вспомнить всю эту историю:

• MIT Sloan: "Avoiding the Alignment Trap in IT"

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


* "старое поколение" дельфистов знает Федора как ключевого автора RXLib, кстати, название которой расшифровывается как "Rosno vcl eXtension Library", а мы с Федором были одними из первых филд-тестеров продукта Borland под кодовым названием AppBuilder, известного теперь всем под именем Delphi ;)