Подобно многим сервисным финансовым организациям фирма Chubb Insurance, занимающая 11-е место среди крупнейших страхователей недвижимости и несчастных случаев в США, быстро осваивала технологии, популярные в начале 21-го века. Но как и во многих компаниях, происходило это скорее спонтанно, чем на основе целостного видения.
“Когда я начал работать в Chubb, каждая бизнес-единица имела свою архитектуру и архитекторов, — говорит Джун Друри, занимавший пост CIO с 2005 по 2008 г. — основной период становления архитектуры в компании. — Каждый думал, что он прав, и каждый отдел имел уникальную архитектуру. Ни у кого не было полной картины. Мы должны были понять, что важно делать на уровне предприятия, а что лучше оставить бизнес-подразделениям”.
В 2006-м высшее ИТ-руководство этой компании, имеющей оборот в 50 млрд. долл., решило, что для продвижения ИТ на следующий уровень необходимо создавать архитектуру предприятия. После нескольких встреч и обсуждений было решено, что возглавить эту работу должен старший архитектор коммерческого подразделения Патрик Салливан.
Но была одна проблема: Салливан не хотел уходить из своего отдела. Он считал, что назначение главным архитектором компании может затруднить его взаимоотношения с архитекторами других направлений бизнеса, поскольку те будут воспринимать его как начальника. Работа же в коммерческом подразделении позволяет ему зарабатывать свой хлеб и зависеть только от своих решений наравне с другими архитекторами. После небольшой дискуссии Друри согласился с тем, что Салливан будет работать на двух постах одновременно.
“В это время Салливан использовал логику и здравый смысл, а не властные полномочия для объяснения значимости общей архитектуры”, — вспоминает Друри. Так продолжалось до 2008 г., когда исполнительным вице-президентом и CIO компании стал Джим Найт, а Салливан наконец занял пост главного архитектора компании.
К тому времени он чувствовал, что архитектура предприятия и компания готовы к предстоящим изменениям. Chubb Insurance перешла на федеративную архитектуру, которая используется до сих пор.
Хотя модель основана на инфраструктуре TOGAF (The Open Group Architecture Framework), Салливан подчеркивает: “TOGAF просто дает нам компоненты. Это не поваренная книга и не готовый рецепт, они должны применяться уместно и интерпретироваться должным образом”.
Достижение компромисса
Применяемая в Chubb архитектура создана разработана таким образом, чтобы поддерживать баланс между разработкой инфраструктуры и поддержкой текущей проектной работы.
Основным фактором в этой работе является то, что архитектура предприятия описывается на языке, понятном непрофессионалам. “План города” — генеральный план для портфолио приложений. Эти приложения связаны с “кварталами города”, которые представляют бизнес-возможности Chubb (например, маркетинг и продажи, возбуждение исков о возмещении ущерба). Все новые проекты должны получить “разрешение на строительство”, чтобы гарантировать, что они следуют стандартам предприятия и затрачиваемые на них усилия не дублируются в других местах. Если архитекторы нуждаются в нестандартной технологии, они должны затребовать “изменение”.
Наблюдательные советы по архитектуре обеспечивают управление стандартами и их соблюдение в каждом бизнес-подразделении. Они отслеживают ключевые характеристики, включая эффективность, стоимость, баланс, прибыль и инвестиции.
Одна из главных причин успеха ИТ-архитектура Chubb — фокус на прибыли. “Я не встречаю сопротивления со стороны бизнеса по поводу архитектуры”, — говорит Найт. Важно и то, что бизнес-партнеры были вовлечены в процесс на ранней стадии проекта и занимаются им до сих пор. Архитектура представлена в таком виде, что бизнес нуждается в ней.
Хотя архитектура предприятия Chubb все еще в разработке, на сегодняшний день достигнуты впечатляющие результаты. Она предоставляет возможности для коллективного использования инструментов и процессов по всем бизнес-направлениям, тем самым снижая затраты. Например, в 2010-м было сэкономлено 600 000 долл. на перераспределении неиспользуемых лицензий на ПО.
Еще одно преимущество — план инвестиций. Поскольку архитектура предприятия описывает взаимодействие данных, технологий, приложений и бизнес-возможностей, ИТ-директора по каждому направлению бизнеса могут планировать инвестиции совместно с не-ИТ-коллегами. В результате ИТ-отдел пользуется большим доверием, поскольку руководство уверено, что здесь выбираются правильные технологии на основе правильного понимания нужд бизнеса.
Коллективно доступные инструменты готовы к работе еще до того, как они понадобятся. Центры компетенции предоставляют доступ к знаниям такой глубины, которая требуется. Благодаря этому решения по выводу на рынок новых услуг принимаются быстрее, а повторное использование наработанных ИТ обеспечивает дополнительную окупаемость. Это создает прочный фундамент на будущее.
Десятилетнее движение компании Chubb к использованию архитектуры предприятия основывалось на здравом смысле и взаимной ответственности бизнеса и ИТ-подразделения на каждом шаге.
“Если что-то не дает добавочную стоимость, мы этим не занимаемся, — говорит Салливан. — Мы стремимся минимизировать бюрократию и всегда приводим ясные доводы относительно ожидаемых результатов”.
Компания прошла большой путь с того времени, когда для каждого направления бизнеса использовалась своя архитектура. Сегодняшняя сплоченность помогает ей двигаться вперед, в то время как другие пытаются поспеть за настоящим. Пример Chubb показывает, что единая архитектура предприятия действительно помогает в управлении всей компанией.
