Огромное количество информационных служб собирают воедино колоссальные объемы данных, идя при этом на очень большие затраты. Не слишком ли большие? Может быть, и так, судя по комментариям некоторых руководителей ИС, чьи компании в недавнем прошлом реализовывали крупные интеграционные проекты.
Бизнес-планы. Передача данных. Руководство проектами и обучение пользователей. Каждая последующая проблема выскакивает как черт из табакерки, стоит только приступить к детальной проработке интеграционного проекта, и бьет прямо по бюджету информационной службы. Может быть, эти руководители ИС намеревались использовать не самые новые и не самые совершенные инструменты интеграции? Или обилие различных стратегий и инструментов интеграции данных ведет к превратному толкованию самих принципов управления подобным проектом. Собственно, это довольно часто происходит с любой инициативой, связанной с информационными технологиями.
 |
| Юзеф Экьюз: «Первейшая задача — в деталях разобраться с информационными потоками на предприятии» |
В любом случае интеграция воспринимается большинством пользователей, да и руководством многих компаний, как нечто не требующее особых усилий, само собой разумеющееся. Некоторые руководители ИС даже пытаются передать проект, связанный с интеграцией данных, в другие подразделения, а то и в независимые компании, и ни о чем не заботиться, пока работа не будет завершена.
Реальность, однако, такова, что интеграция, стоит ею заняться, способна поглотить вас целиком.
В самых общих чертах интеграция данных — это некоторый ряд процессов, происходящих тогда, когда два приложения, созданные разными разработчиками, обмениваются информацией. Эта цепочка, как правило, состоит из четырех этапов: извлечение, транспортировка, преобразование и загрузка.
Для выполнения каждой из этих функций можно завести отдельную программу или же последовать примеру большинства и потратить деньги на ПО, выполняющее функции брокера сообщений и способное управлять всеми аспектами обмена данными, от учета многочисленных требований бизнеса и до мелких технических деталей. Можно даже внедрить систему планирования ресурсов предприятия (enterprise resource planning, ERP) в надежде, что это избавит от всех трудностей, связанных с интеграцией, или решиться на некий промежуточный вариант: использовать определенную комбинацию двух-трех инструментов или частичное решение, опирающееся на брокер сообщений.
Каков бы ни был окончательный выбор, кое-какие шаги придется предпринять заранее, чтобы интеграционный проект не превратился в бездонную яму, где бесследно исчезают деньги.
Тем, кто только затевает интеграцию данных, нужно знать, что этот проект не сводится лишь к установке необходимого программного обеспечения. Так, использование брокера сообщений, выдвигаемое в качестве полного решения (так часто бывает в маркетинге программ), в действительности требует дополнительного программирования и постоянного администрирования, что выливается в непредвиденные расходы на программы, решающие такие задачи, как контроль версий и настройка адаптеров, выполняющих преобразование данных.
На первый взгляд кажется, что найти ответ на главный вопрос интеграции (то есть понять, какие требуются данные, как их преобразовывать и как их привести в порядок, чтобы можно было загрузить в новое приложение) довольно просто. Однако во многих случаях это трудная и дорогостоящая задача.
Так какова же цена интеграции? Очевидно, что в денежном выражении она сильно варьируется: от нескольких тысяч долларов за базовые механизмы извлечения данных до миллионов долларов за масштабное решение, включающее в себя, помимо брокера сообщений, необходимый дополнительный инструментарий. Кроме того, необходимо учитывать, что интеграция далеко не всегда изолированный проект; он влияет на всю систему в целом, часто провоцируя создание новых псевдоприложений.
«Существуют приложения, которые ?помещаются? между уже имеющимися, — отметил Росс Альтман, аналитик GartnerGroup. — Они несколько отличаются по стилю и архитектуре, но их, безусловно, можно отнести к приложениям».
А создание приложений требует среды разработки, обучения, определения процессов, архитектуры, короче, всего того, что ассоциируется с любым проектом разработки.
«Большинство людей этого не понимают, — отметил Альтман. — Они считают, что вопрос только в том, как объединить вместе две базы данных».
Что еще можно сделать, чтобы расходы на интеграционный проект остались на приемлемом уровне? Ниже приводится несколько «рецептов», которые предлагают директора информационной службы.
Совет №1. Прежде всего, проясните себе текущие и будущие бизнес-цели
По мнению Юзефа Экьюза, вице-президента компании The Timberland по информационным службам (производителя туристической обуви и снаряжения, первейшая задача — в деталях разобраться с информационными потоками на предприятии. Экьюз принял решение о приобретении брокера сообщений IBM MQSeries. Теперь он хочет настроить потоки информации с помощью этого программного обеспечения так, чтобы пользователи не подозревали, что работают с несколькими различными вычислительными и прикладными платформами. Его подход — использовать установку ПО как возможность реинжиниринга бизнес-процессов, чтобы сотрудники могли не просто передавать файлы, а выбирать пути эффективного выполнения конкретных действий.
«Можно придирчиво отбирать передаваемую информацию, используя возможности брокера сообщений, и адаптировать ее под адресата, которому она пересылается только какой в этом толк, если нет целостного представления о всей системе? — считает Экьюз. — Необходимо учитывать не только то, что происходит сейчас, но и то, какая ситуация сложится через два-три года».
Кроме того, нельзя замыкаться на интерфейсе — необходимо отслеживать всю цепочку поставок. «Нужно думать о том, — призывает Экьюз, — как подразделения предприятия могут воспользоваться информацией друг друга».
Совет №2. Некачественная формулировка проекта наверняка приведет к значительному превышению его бюджета
Требуется выяснить, в чем специфика источников данных и их адресатов, разобраться, какие данные необходимо передавать и как они будут использоваться. Если этого не сделать, то есть заниматься распределением данных позже, а не в первую очередь, это неизбежно обернется дополнительными затратами.
 |
| Эшвин Ранган: «Если реализовывать интеграционный проект, не определив основные этапы и не имея плана, в конечном итоге он превратится в проект, замкнутый исключительно на ИТ, а не на бизнес» |
Об этом предупреждает и Эшвин Ранган, директор информационной службы компании Conexant Systems, производящей полупроводниковые компоненты. Ранган знает это по собственному опыту: ему довелось заниматься организацией передачи данных из системы выставления счетов в систему управления продажами.
По словам Рангана, зачастую, когда ИТ-специалисты берутся за интеграционный проект, основное внимание они уделяют технологии, особенно в промежуточном звене, который отвечает за взаимодействие двух разнородных систем. На самом же деле, эта технология вторична. Самый важный вопрос: почему компания хочет связать эти две системы, по словам Рангана, зачастую даже не поднимается, ну а ответа на него и подавно не стоит ждать.
Передача сообщений и промежуточное ПО — это крайне сложный набор технологий, требующих немалых затрат времени, энергии и денег. Если реализовывать интеграционный проект, не определив основные этапы и не имея плана, в конечном итоге он превратится в проект, замкнутый исключительно на ИТ, а не на бизнес. «Такого рода ошибки не только наносят вред самому проекту, но и подрывают доверие к организации и людям, которые в нем участвуют», — предостерегает Ранган.
Совет №3. Данные в большинстве своем намного грязнее, чем это кажется
Очистка данных от избыточной и некорректной информации, которая позволяет более эффективно их передавать от исходной системы в систему-адресат, требует немало времени и к тому же обходится недешево. Как отметил Джон Керроу, директор по информационным технологиям компании Unisys и бывший директор ИС города Филадельфия, люди обычно оказываются неоправданно оптимистичны. «В конечном итоге почти всегда приходится вручную отсортировывать данные, — заявил Керроу. — Вера в то, что данные готовы к работе, практически всегда оказывается безосновательной и обходится крайне дорого».
Совет №4. Это никогда не закончится
По мнению Рангана, стоит сделать «моментальный снимок» данных, которые будут преобразованы, и пользоваться им в качестве «привязки». Интеграционные связи образуются при определенных условиях, и эти условия со временем меняются. Если не «замораживать» данные, впоследствии для организации передачи данных может возникнуть необходимость вернуться к самому началу.
В процессе развертывания нового инструментария для отдела продаж в компании Conexant было принято решение перенести данные из системы выставления счетов, созданной на ПО разработки SAP, в другую среду. Это как раз случай использования различных технологий, продуктов и платформ — одна из систем имела клиент-серверную архитектуру, а другая представляла собой набор тиражируемых баз данных Notes.
«Как раз перед тем как начать перенос данных, мы обнаружили, что необходимо кое-что доделать, поскольку некоторые форматы данных были изменены», — отметил он.
Группа Рангана вынуждена была вновь заняться проектированием, и по-другому взглянуть на источники информации, откуда следовало извлечь сведения для отдела продаж и заново пересортировать их. «Второй раз это обычно сделать проще, поскольку уже есть опыт подобных операций, — заметил он. — Хотя все равно это задерживает процесс интеграции».
Совет №5. Помните об управлении проектом
У семи нянек дитя без глазу. Так охарактеризовала свою ситуацию Лаура Энн Нэнс, директор по информационным технологиям компании Public Service, поставщика натурального газа. Отдел из 60 человек, которым руководит Нэнс, занималась интеграцией финансовых и кадровых приложений из пакета планирования ресурсов предприятия производства PeopleSoft, с пакетом управления документами, разработанным компанией American Software, и с унаследованной системой с информацией о потребителях, которую одновременно следовало проверить на совместимость с 2000 годом. Неизбежно возник вопрос о выборе методологии. Подобная ситуация далеко не всегда чревата значительными денежными затратами, но обязательно требует кропотливой работы, и редкий руководитель захочет рискнуть своим авторитетом, заставляя сотрудников выполнять ее.
 |
| Лаура Энн Нэнс: «В будущем мы будем очень осмотрительны в выборе консультантов и уж точно не станем преувеличивать значение их технических навыков» |
«К положительным моментам можно отнести тот факт, что мы осознали, как важно, чтобы руководители подобных проектов были не просто квалифицированными специалистами, но и носителями корпоративной культуры, — заметила она. — В будущем мы будем очень осмотрительны в выборе консультантов и уж точно не станем преувеличивать значение их технических навыков».
Совет №6. Для предотвращения катастрофических пробок, используйте автоматический мониторинг
Активизация деятельности по интеграции в конце месяца, например регулярное выставление счетов, может привести к тому, что система передачи сообщений исчерпает свой ресурс, передача информации замедлится, и бизнес-процессы застопорятся. В Timberland Экьюз сегментировал передачу крупных пакетов данных, разложив их на более мелкие. Программное обеспечение IBM MQSeries и приложение мониторинга передачи данных, которое разработала сама компания Timberland, уведомляет о проблемах с перегрузкой на самом раннем этапе, а затем автоматически пытается притормозить передачу. Экьюз намерен приобрести достаточно дорогое промежуточное объектно-ориентированное ПО для решения задачи интеграции. В «тандеме» с MQSeries оно будет отсортировывать и передавать информацию на различные узлы, вне зависимости от аппаратной платформы, приложения, часового пояса или языка.
По поводу мониторинга Экьюз заметил, что, даже вложив средства в мощное ПО передачи сообщений, возможно, придется потратить еще какую-то сумму на средства автоматического мониторинга передачи сообщений. В противном случае до того момента, пока не возникнет ощутимый затор, можно и не узнать, что возникла проблема с передачей данных или что нужно автоматически повторить попытку передачи, если она была прервана. Большинство производителей предлагают инструментальные средства контроля в качестве дополнительной и дорогостоящей возможности. Выбирая инструментарий мониторинга, необходимо убедиться, что он работает со всеми компьютерными платформами, используемыми на предприятии.
Совет №7. Не забудьте про обучение
Данные не просто размещаются в произвольном числе разнородных источников, но доступ к ним часто происходит с помощью различных интерфейсов. Поддерживать интегрированные архитектуры, прибегая к услугам многочисленных специалистов, крайне непрактично, правильнее попытаться обойтись лишь несколькими сотрудниками, обладающими всеми необходимыми навыками. Естественно, это означает, что придется заняться их обучением.
Если нет возможности организовать обучение пользователей внутри компании, придется обратиться за помощью к кому-то извне. Плюс к этому придется раскошелиться, к примеру, на подготовку обучающих материалов. Чарли Лейсфилд, бывший вице-президент и исполнительный директор по ИТ химической компании Dow Corning, который уволился сразу же после завершения внедрения многомиллионной системы планирования ресурсов предприятия, считает, что «запланировать эти расходы очень трудно, поскольку невозможно даже приблизительно определить их объем». Он добавил, что до этого момента не было необходимости в дополнительных затратах на инструментарий, используемый в процессе интеграции для завершения внедрения системы ERP, поскольку Dow Corning получила полный комплект модулей SAP.
Что касается привлечения «учителей», Лейсфилд отдал предпочтение техническим специалистам, обладающим навыками общения, отказавшись от профессиональных преподавателей, имеющих лишь общее представление о технологии. Естественно, поиск квалифицированных преподавателей сам по себе может превратиться в сложную работу. То же самое можно сказать и о составлении расписания занятий.
Брокер сообщений: планировать сегодня или платить завтра
Для большинства информационных служб, интеграция приложений путем пакетной обработки и передачи файлов — вовсе не проблема; они именно этим методом и пользовались столь долгое время. Но появление новых программных продуктов, выполняющих функции брокеров сообщений, называемые также инструментарием для интеграции корпоративных приложений (enterprise application integration, EAI), которые занимаются интеграцией в реальном времени, заставляет вернуться к тем же наболевшим вопросам.
По мнению Росса Альтмана из GartnerGroup, поддержка передачи сообщений начинается с обучения персонала, а также с мысли, что программа может оказаться не столь исчерпывающей, как показалось сначала.
«Во многих случаях вам придется приобрести инструментарий управления и мониторинга производительности у независимых разработчиков, чтобы получить реальный контроль над своей весьма масштабной информационной системой, — отметил Альтман. — Я думаю, многих неприятно удивят требования к управлению, возникающие при поддержке передачи сообщений».
Есть еще несколько моментов, которые могут существенно увеличить затраты компании, выбравшей для себя путь EAI.
- Инструментарий EAI. Они сокращают время и усилия, необходимые для создания приложения, но при этом не решают всех проблем. «По-прежнему требуется выяснить бизнес-семантику приложений, обменивающихся данными, — считает Альтман. — Как выглядят данные? Какие бизнес-правила применимы к этим данным?»
- Подготовка. EAI не избавляет от необходимости проводить анализ и проделывать определенную работу. «Кому то придется засесть в конференц-зале и изучить развешанные по стенам диаграммы, прежде чем компания будет готова использовать инструментарий EAI, который она приобрела, — подчеркнул Альтман. — Эти расходы часто не учитываются».
- Управление. Лучший инструментарий EAI включает встроенные компоненты для управления кодом, контроля версий, анализа и создания конфигураций. Но для управления ими по-прежнему нужно присутствие человека.
«Вне зависимости от выбранного подхода, для эффективной интеграции систем и приложений требуется создание специальной группы сотрудников, — считает Альтман. — В состав этой группы должны входить разработчики, руководители проектов, эксперты в области определенных бизнес-процессов, а также системные администраторы и представители руководства. Иными словами, сэкономить на этом не удастся».