В крупном международном концерне, где работает более ста тысяч человек, вопросы оптимизации ИТ-архитектуры имеют важное значение. О том, как в компании Philips связывают развитие и модернизацию бизнеса с архитектурными изменениями ИТ-систем, рассказывает Андрей Гурский, менеджер по информационным технологиям в России, Белоруссии и Средней Азии.

Intelligent Enterprise: Можно говорить об ИТ-архитектуре как о понятии глобальном и абстрактном, а можно — как о вещи простой и прикладной. Какой подход вам ближе?

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

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

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

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

Вы сказали о постоянных трансформациях. Разве бизнес Philips быстро меняется?

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

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

Каким образом вы управляете преобразованиями существующей ИТ-архитектуры? Какие цели при этом ставите?

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

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

У нас описана ИТ-архитектура «как должно быть», та, которую мы имеем в виду в качестве стратегии. К примеру, мы начали с сотни с лишним приложений в рамках подразделения «бытовая электроника» в европейском регионе. Это было четыре года назад. Важно было снизить число приложений и достичь прозрачности затрат на поддержку. Была инициирована целевая программа SYSLA — «System Landsсape», или «системный ландшафт», — направленная на то, чтобы снизить число приложений и привести их в соответствие с целевым ландшафтом. Каждый год из прошедших четырех мы снижали число приложений не менее чем на 30%.

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

Расскажите конкретнее, какие изменения вы провели в рамках приближения к целевой ИТ-архитектуре.

Например, было решено, что для заказов, продаж и логистики роль транзакционной системы должна исполнять SAP Business Suite. В начальный момент эта ERP-система охватывала лишь треть наших компаний, сейчас мы заканчиваем охват всех входящих в холдинг структур.

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

Похожая стратегия у нас действует и в области средств коллективной работы. Многие годы мы работали на средствах IBM, для некоторых задач применяли технологии Microsoft. Теперь Microsoft предлагает полный спектр решений как для личных коммуникаций, так и для организации коллективной работы. И мы приняли стратегию «Microsoft Unless». Речь идет о системах управления знаниями, средствах документооборота и групповых коммуникаций. Эти и другие задачи в данной сфере мы сначала пробуем решить средствами Microsoft. Если продукт этого вендора не находится, то принимаем решение отклониться от стратегии и ищем нужное у других производителей. Такой подход дает нам требуемую степень гибкости.

Кстати, уместно говорить не только об архитектуре систем, но и об архитектуре информации. Приведу пример. Когда мы развернули инфраструктуру коллективной работы на основе решений IBM, мы начали с электронной почты, потом внедрили документооборот и наконец управление знаниями. В 2001 году ИТ-сообщество компании активно пропагандировало решения для управления знаниями. В результате мы столкнулись с эффектом «снежного кома». Мы получили тысячи Documеnt Library и Teamroom (терминология решений IBM) для управления знаниями. Возникла необходимость индексации, сквозного поиска по ним, регулирования прав доступа. Сейчас мы создаем портал, где пользователь мог бы наконец увидеть всё, к чему он имеет доступ, где будет собрано всё необходимое для его эффективной работы. Теперь стоит задача перенесения всего этого богатства на технологии Microsoft. И было бы упущенной возможностью не использовать момент для переосмысления того, что у нас есть, как этим правильней управлять, как обеспечить удобство поиска. Иными словами, создать архитектуру информации.

Портал также рассматривается как элемент целевой ИТ-архитектуры?

Несомненно. Одна из серьезных проблем, с которой сталкивается крупная международная компания, касается коммуникаций, включая управление знаниями. Мне кажется, что глубина этой проблемы недооценивается. Я знаю довольно примеров за последние годы, когда инициативы, подобные созданию порталов, были хорошо осмыслены в ИТ-сообществе компании, но при этом недостаточно внимания уделялось тому, чтобы новый подход адаптировать к управлению информацией. Вот об этом мы и ведем сейчас дискуссию. Мы создаем решения на базе технологий Microsoft и SAP (именно на ПО SAP сделан портал) и хотим, чтобы у каждого пользователя была своя персональная страница, куда подтягивались бы те ресурсы, которые для него открыты или специально предназначены. Уже действует работоспособный прототип такого портала, технические задачи решены. Но нас волнуют не столько они, сколько организационные проблемы. Как сделать, чтобы этот портал действительно приносил людям пользу? Как его включить в культуру ведения бизнеса в компании? Открытие портала должно быть воспринято корпоративной культурой, а не оказаться никому не нужным ИТ-инструментом.

Вы рассматриваете портал как средство интеграции?

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

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

Вы упомянули об объединении двух бизнес-направлений внутри концерна. Насколько вы продвинулись в этом?

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

Philips активно покупает компании. Какие задачи это обуславливает с точки зрения ИТ-архитектуры?

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

Неужели этого будет достаточно, чтобы выдержать заданные весьма сжатые сроки?

Есть и другое обстоятельство, которое способствует упрощению присоединения покупаемых бизнесов, — это стандартизация. Очень сложно присоединять компании, если ты работаешь на закрытых стандартах, несовместимых со стандартами приобретаемых бизнесов или незнакомых им. Мы довольно долго отстраивали наши внутренние инфраструктуры как замкнутые экосистемы. Яркий пример — наша сеть Philips Global Network. Любой новый склад, завод, офис должен был быть подключен к этой сети. Был сформирован стандарт локальных сетей, на протяжении ряда лет мы активно инвестировали разработку этих стандартов. Точно так же и Lotus Notes, и все системы, на ней основанные, всегда были замкнутыми, полностью находящимися внутри компании.

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

Первый блок в этой области — электронная почта, с которой мы начали. Мы переходим к покупке услуги по размещению электронной почты у внешнего провайдера. Примерно 20% холдинга уже перешло на такую услугу, в том числе российское представительство. Полностью данный переход будет закончен в течение ближайших месяцев. Это сократило наши потребности в пропускной способности сети как минимум вдвое и заметно снизило затраты. Естественно, вопросы безопасности при этом должны решаться на другом уровне. Так что новым поглощенным компаниям мы просто даем доступ к нашим ресурсам через Интернет. Так же мы будем поступать и в других сегментах автоматизации. Например, мы много инвестировали создание десктоп-стандартов, теперь же ставится цель — «как можно больше по умолчанию». Раньше разные вендоры производили несовместимые между собой компоненты, нынче же поставщики систем сами решают проблемы, которые приходилось решать нам.

Идеи о переходе с закрытых стандартов к открытым рождаются в головах у очень сильных личностей, которые способны убедить всех остальных. Но переход сложен тем, что оказываются не продуманными очень многие детали. Правда, с течением времени понимаешь: магистральное направление было правильное, только вот путь к нему очень уж нелегок. Отчасти это связано со сменой парадигмы, перестройкой мышления самих айтишников. Раньше парадигма была следующей: «Лучше нас все равно никто не сделает, и никто посторонний не может знать, что лучше всего подходит для Philips». Теперь же складывается рыночное понимание того, как должны быть организованы эти услуги.

Провайдеры научились предоставлять требуемые сервисы и выдерживать нужные заказчикам параметры. Услуги по требованию уже есть на рынке, но только по инфраструктуре, и мы ориентируемся на этот факт, решая архитектурные задачи. Наверное, так и будет с приложениями, но только неизвестно, когда. Мы делаем робкие попытки внедрения «SAP по требованию», но пока они оказываются скорее неудачными. Однако спрос всегда развивает зрелость поставщиков…