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

Software

Автор:
Источник: Публикуется с согласия редакции "Вестника McKinsey". Статья вышла в 3 номере журнала за 2003г. Полностью номер можно прочитать на сайте www.vestnikmckinsey.ru
Опубликовано: 1 марта 2006

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

Компании из развитых стран, в конце 1990–х транжирившие деньги на все новые и новые ИТ–системы, извлекли для себя ценный урок: если представители бизнеса не принимают участия в управлении ИТ–проектами, вложенные в ИТ средства используются неэффективно. Чтобы не повторять свои ошибки, руководители бизнес–подразделений и ИТ–менеджеры начали объединять технологические системы в так называемые домены — группы приложений и баз данных, которые управляются с учетом интересов прежде всего бизнеса, а не исходя из конфигурации компьютеров и операционных систем, на которых работают приложения. И такой вариант гораздо удобнее для бизнеса[1]. К примеру, объединение систем, содержащих информацию о клиентах, и пересмотр существующих между ними связей позволит компании «распутать клубок» переплетающихся систем, устранить дублирование, избавиться от ненужных приложений. В результате резко сократятся расходы на обслуживание и развитие информационных технологий, ИТ–специалистам будет проще переделывать или отлаживать эти системы, эффективнее и дешевле обслуживать бизнес–подразделения и вовремя оказывать технологическую поддержку проводимым в компании преобразованиям. Более того, в этом случае сгладятся трения, вызванные различием двух культур— бизнеса и ИТ.

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

Отчасти этот подход напоминает систему скидок «1 + 1 = 1». Вы перестраиваете свою информационную систему, чтобы сделать ее более гибкой и сократить издержки, и если вы действовали правильно, то получите дополнительный приз: бизнес–подразделения начнут реально участвовать в управлении ИТ. В крупных компаниях на эти преобразования может уйти больше двух лет и свыше 10 млн долл. Тем не менее если существующая ИТ–архитектура связывает компанию по рукам и ногам, а добавление новых приложений оборачивается непомерно высокими издержками, то ее обязательно нужно переделать. В среднесрочной перспективе такой шаг позволит на 60—70% снизить затраты на интеграцию новых приложений. Компаниям стоит как минимум задуматься о перестройке ИТ–архитектуры, если перед ними стоят неотложные проблемы, решение которых затрагивает вопросы информационных технологий: изменение стратегии, интеграция бизнес–подразделений, находящихся в разных странах, слияние, поглощение, продажа активов. Но даже тем компаниям, у которых нет никаких сложностей с ИТ, стоит оценить потенциальные преимущества, которые они получат, если заранее подготовятся к будущим испытаниям.

Несоответствие предложение спросу

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

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

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

Некоторые компании пробовали решить проблемы ИТ–архитектуры, заменяя сразу все ее ключевые элементы. В качестве примера можно привести внедрение ERP–систем[2] — монолитных, интегрированных приложений, которые, как правило, заменяют разрозненные программы для управления персоналом, операционной деятельностью, бухгалтерией и цепочкой поставок. Такие масштабные преобразования иногда необходимы — например, если компании нужно создать систему отчетности по всей глобальной деятельности на основе ERP,— но по возможности их лучше избегать. Перспектива избавиться разом от всех старых систем заманчива, но это очень затратная и рискованная стратегия, которая приводит к неоднозначным результатам и, как правило, не способствует налаживанию отношений между бизнес– и ИТ–подразделениями. Нам известны случаи, когда бизнес–менеджеры брали на себя руководство сложными проектами, но, как только понимали, что требуются непомерные материальные и временные затраты, перепоручали контроль ИТ–специалистам или закрывали проекты.

Многим компаниям самое время обновить свою ИТ–архитектуру, но не менее важно устранить вызванный культурными различиями глубинный раскол между бизнес– и ИТ–подразделениями. И хорошо, что кому–то удается решить обе эти задачи одновременно (см. схему 1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[1]См.: Jurgen Laartz, Ernst Sonderegger, Johan Vinckie. The Paris Guide to IT Architecture // The McKinsey Quarterly, 2000, No 3, pp. 118—127 (www.mckinseyquarterly.com/links/4037).
[2]ERP (enterprise resource planning) — электронные системы планирования ресурсов предприятия.

Автор: