Технологическая архитектура бизнеса: пути обновления. Часть2.

Автор статьи: Юрген Лаартц

>

Работа в сотрудничестве

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

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

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

Создание сборной

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

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

Определение доменов и сервисов

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

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

Затем команда наладила обмен инструкциями и информацией между доменами, то есть создала сервисы: ИТ-специалисты называют их так потому, что они контролируют, как одно бизнес-подразделение обслуживает другое. Скажем, субдоменам банковского филиала, колл-центра и интернета нужен был стандартный сервис, который с помощью нового субдомена, содержащего информацию о клиентах, открыл бы им доступ к любым сведениями. Такая возможность у них появилась: теперь им достаточно лишь воспользоваться сервисом «обновить данные о клиенте». Другие сервисы банка могут «проследить использование каналов клиентами» и «оценить доходность продукта» (см. схему 2).

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

Компании из самых разных отраслей получили немало выгод от обновления ИТ-архитектуры. Розничному банку удалось на 30% сократить время вывода на рынок новых продуктов и на 10-20%- затраты на развитие и поддержание ИТ-систем. Европейская компания- оператор фиксированной связи перестроила ИТ-архитектуру, введя систему выставления счетов и обработки данных о клиентах, которую можно было использовать и для продвижения новых продуктов. В результате компания выводит на рынок новые продукты всего за несколько недель вместо прежних нескольких месяцев. У одного интернет-провайдера 70% бюджета, выделенного на развитие приложений, расходовалось на изменение их свойств и только 30% — на развитие самих услуг. Но после того, как компания начала практиковать эволюционный подход, это соотношение постепенно изменилось. Компания, ведущая разведку нефтяных месторождений, перестроила свою ИТ-архитектуру и обнаружила, что легко сможет объединить свои ИТ-системы с системами компании, с которой собиралась совершить слияние. Более того, совокупные затраты на информационные технологии сократились на треть.

Переход управления

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

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

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

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

***

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

Статья вышла в 8-м номере журнала.
Полностью номер можно прочитать
на сайте http://www.vestnikmckinsey.ru/

Юрген Лаартц, Эрик Моннойе, Александр Шердин
Статья была опубликована в The McKinsey Quarterly, 2003, № 3