Константин Старовойтов, технический директор ЗАО "Транссервис Связь", начальник отдела ИТ ООО "ОФ ПТК"
Культура применения информационных технологий в России за последние годы выросла, однако разрозненные информационные системы на практике продолжают существовать. Проблемы, связанные с устойчивостью подобной ситуации можно выделить и попытаться их решить. Но не факт, что оптимальным выходом окажется создание новой единой ИС и использование наиболее популярных на сегодня программных продуктов.
Как и многие другие российские холдинги, возникшие на перестроечной волне, "Петербургская топливная компания" прошла тернистый путь автоматизации - от первой "сводки", сформированной в MS Excel, до успешно функционирующих систем b2b. Ретроспективный взгляд показывает, что год от года ситуация с автоматизацией компании становилась все сложнее и запутаннее, и происходило это по нескольким причинам.
Одна из них - недостаточные базовые и профессиональные знания ИТ-персонала, ведь необходимого опыта в принципе не могло быть у людей, конечно, за исключением приехавших из-за рубежа. Другой - отсутствие понимания целей, к которым надо стремиться. То есть того, что теперь все называют ИТ-стратегией. Вносила и вносит свой вклад в растущую сложность систем постоянно меняющаяся внешняя среда, изменения правила игры. В свое время владельцы компаний не знали потенциальных возможностей ИТ-технологий и соответственно не ставили ИТ-специалистам четких задач. Еще один, очень распространенный фактор: каждое подразделение, входившее в только что образованные холдинговые структуры, проводило собственные проекты автоматизации, выбирая свои технологии и подходы к внедрению.
Время шло, персонал компаний рос профессионально, рынок ИТ в России достиг определенной зрелости, но при этом зоопарк информационных систем только усложнялся и разрастался. Новые знания и новые возможности позволяли давать собственникам сначала только новую информацию для анализа, а потом и новые конкурентные преимущества для их компаний. Начала выкристаллизовываться новая инфраструктура ИТ-служб с единым управлением, поделенная на ставшие уже стандартными блоки технической поддержки, проектный офис, отдел программных разработок и т. д. Но все эти положительные прогрессивные факторы не только не упростили структуру зоопарка, но наоборот, сделали его еще сложнее.
Если проанализировать с точки зрения ИТ объекты автоматизации нашей компании, связанные с ними ИС и связи между этими системами, получится следующая картина. Имеется 120 АЗС и АЗК (автозаправочные станции и комплексы), две нефтебазы (предприятия, обеспечивающие хранение значительных запасов нефтепродуктов), пять эксплуатационных и торговых компаний (офисов продаж), подразделение перевозки топлива, девять прочих компаний группы (связь, реклама, экология, транспорт) и две управляющие компании с разными зонами ответственности.
АЗС оснащены комплексными системами управления оборудованием (топливораздаточные колонки, датчики уровня топлива, модули приема и обработки смарт-карт, POS-терминалы, фискальные регистраторы). Все это оборудование порождает потоки данных, которые несколько раз в день передаются по проводным и беспроводным каналам связи в процессинговый центр по протоколам TCP/IP и X25. Данные упакованы в файлы, которые и пересылаются в обе стороны. При этом автозаправочные станции - единственный объект, который не является отдельным юридическим лицом, и работают они как подразделения одной из эксплуатационных компаний.
Нефтебазы пользуются специализированным ПО. Оно поставлялось в комплекте с автоматической системой налива топлива и функционирует как "черный ящик" для нынешнего ИТ-персонала. Данные этой системы (о том, сколько, когда и какого топлива было отгружено в какой бензовоз, доставляющий горючее на АЗС) представляют основной интерес для анализа и оперативной работы по учету топлива с точки зрения управляющей компании. Проблема в том, что ПО на нефтебазе специфическое и очень слабо интегрируется с чем-либо еще: программы работают под DOS, внешних интерфейсов не имеют.
Эксплуатационные и торговые компании интегрируют у себя как данные, получаемые ими от АЗС напрямую, так и данные, получаемые от управляющей компании. Данные, получаемые ими от АЗС, представляют оперативный интерес для управляющей компании и ежедневно передаются "наверх". Логистическая компания, эксплуатирующая парк бензовозов и непосредственно занятая доставкой горючего, обладает критическими данными о необходимости доставки топлива на АЗС и о фактически доставленном топливе.
Естественно, центр притяжения всех данных и раздачи этих данных клиентам холдинга находится в управляющей компании. Информация, генерируемая всеми объектами автоматизации, стекается и обрабатывается в одном месте. Но эти данные очень разнородны по своей структуре. Различны даже технологии, которые их порождают. На практике проблема несовместимости лежит одновременно в нескольких областях. Первый пласт проблем: несовместимость принципов формирования данных (файловый обмен против прямого подключения к таблицам в БД). Второй пласт: несогласованность справочников. Это самый распространенный случай. Например, в программе нефтебазы коды продуктов соответствуют советским ГОСТам, да еще могут содержать не только цифры, но и буквы алфавита. В специализированном ПО, поставляемом "под ключ" для обработки операций по пластиковым картам, код продукта будет выбран одним из программистов фирмы-разработчика по принципу "как бог на душу положит". Третий и самый проблемный пласт: данные изменяются "задними" числами, и применять простой инкремент для таблиц с данными нельзя. Четвертый пласт проблем "зарыт" не на уровне структуры таблиц, а внутри самих данных, в их содержании, в их природе. Например, существует такая специфическая для топливной отрасли тонкость: топливо на нефтебазе учитывается в килограммах, а на АЗС в литрах. Коэффициент пересчета зависит от текущей температуры воздуха, соответственно создавать точные общие балансы очень проблематично.
Спасением от многих из описанных "бед" может стать сочетание технологий OLAP и BI, но проблему целиком они не решают, хотя, по моему мнению, это лучший на сегодня подход к получению отчетных и аналитических данных из разнородных баз данных. Ведь ключевое слово для этих технологий - "отчетные". То есть рассматриваются данные, которые рождаются "после" действия. У нас же проблемы взаимодействия информационных систем лежат в области "до действия" или "во время действия", а тут новомодный BI помочь никак не может. Да и с проблемой изменения данных "задним числом" эти технологии справляются не очень успешно.
Не упрощают ситуацию и особенности передачи данных из систем B2B, используемые компанией для взаимодействия с нашими клиентами. С корпоративного сайта клиенты могут получить доступ к информации обо всех операциях, совершенных с принадлежащим им топливными картами различных видов (система "ГСМ-Онлайн"). Клиенты могут управлять распределением топлива между своими картами, а также некоторыми другими параметрами системы взаимодействия "Клиент-ПТК-АЗС" (система "ПоТоК"). Естественно, для такого оперативного взаимодействия клиента и компании необходимо обеспечить полную синхронизацию данных, с которыми оперирует клиент в Интернете, с теми данными, которые существуют в базах данных бэк-офиса. Дело всеобщей интеграции и унификации осложняется тем, что половина Web-ресурсов компании функционирует под операционными системами семейства UNIX, другая половина использует сервер MS IIS, а в целях безопасности Web-приложения не могут интегрироваться в локальную сеть напрямую, но должны производить обмен с локальными ресурсами через дискретные средства передачи данных. Для этого у нас стандартно используется обмен по электронной почте, работающий автоматически по расписанию.
Понятно, что такое многообразие информационных систем дает большое количество вариантов взаимодействия между ними, а с многообразием вариантов множатся ошибки и сбои при обмене данными. В какой-то момент мы поняли, что все большая часть ресурсов ИТ-департамента уходит не на развитие, а на поддержание систем в работоспособном состоянии, причем количество жалоб от внутренних и внешних клиентов все возрастало. Компания встала перед выбором: либо попытаться создать новую единую распределенную систему "управления всем на свете", либо создать подразделение, которое будет заниматься исключительно поддержкой существующих систем. Причем это подразделение не будет иметь никакого отношения к подразделению технической поддержки (help desk), так как в основном занимается не обслуживанием пользователей, а обеспечением бесперебойного функционирования взаимодействия информационных систем.
Мы пошли по второму пути. Официальное название нового подразделения - центр обработки данных, но неформально в компании к нему приклеился ярлык "узел связи", что, на мой взгляд, гораздо точнее отражает суть решаемых задач. Надо отметить, что традиционные функции узла связи как предприятия, предоставляющего услуги связистов, также остаются одной из обязанностей нового подразделения, ведь круглосуточное обслуживание сети телефонных станций холдинга входит в ежедневный регламент нашего "узла".
В цифрах структура выглядит так: два сотрудника с обычным восьмичасовым рабочим днем (сетевой администратор и инженер по телекоммуникациям); четыре сотрудника, работающих "сутки через трое" (наличие одного из этих людей круглосуточно на рабочем месте и позволяет решать почти все проблемы); три внешних оптических Интернет-канала; десяток серверов; наиболее критичные приложения размещены на кластере с внешним дисковым массивом.
Функции узла связи таковы:
Почему же мы выбрали экстенсивный вариант развития и предпочли вкладывать деньги в поддержку того, что есть, хотя могли бы остановиться на "более перспективном" и "академическом" варианте с созданием новой глобальной системы, которая унифицирует все процессы, сделает взаимодействие более прозрачным и управляемым? Ответ скрыт в тех нюансах, которые упоминались в начале статьи: имеются в виду особенности каждого узелка в паутине связей наших информационных систем. Рассмотрим все по порядку.
АЗС - система управления написана сторонней компанией, поставлена под ключ, "завязана" на оборудование, заменена быть практически не может (гигантские неоправданные инвестиции). Принята за базу для всего остального тоже быть не может, так как является закрытой технологией, принадлежащей одному вендору.
Нефтебаза - такая же ситуация: система "завязана" на оборудование, за базу принята быть не может не только по причине закрытости, но и по причине полного морального устаревания (система работает под MS DOS).
Эксплуатационные компании не интересует аналитика, их задача - бесперебойное функционирование АЗС. Такая же ситуация с офисами продаж: их задача ограничивается сбытом. Соответствующим образом "заточены" и их информационные системы. Положительный момент для целей интеграции - то, что в отличие от первых двух объектов автоматизации (АЗС и нефтебаз) в офисах системы не привязаны к оборудованию, что отражается на более широких возможностях по подключению их баз данных к базам данных управляющей компании.
Перевозка топлива - пожалуй, единственный на сегодня узелок паутины ИС, автоматизации которого не уделялось должного внимания, хотя эта компания может дать достаточно много важной оперативной информации о движении топлива в холдинге. И как раз в этой области (одной из немногих у нас) возможно интегрирование нескольких программных продуктов в один продукт с единым центром хранения данных. Мы выбрали для решения этой задачи Web-технологию и сейчас разрабатываем продукт, который объединит информацию с нефтебаз, от эксплуатационных компаний и компании-перевозчика в один массив данных, но с разными уровнями доступа для каждого участника процесса.
В такой ситуации управляющая компания может выбрать для себя любой подход к интеграции информационных систем, но практически это свобода выбирать из нуля вариантов. Несмотря на бурную жизнь "зоопарка", на самом деле интегрироваться-то оказывается не с кем, по причинам, приведенным выше для каждой отдельной компании. Именно поэтому мы выбрали путь улучшения надежности обмена между всеми существующими системами "как они есть" путем создания нашего "узла связи", вместо того чтобы создать что-то новое, которое породит новые собственные проблемы, не решая полностью старых.
Источник: Intelligent Enterprise, #21 (130)
Рейтинг ИТ-директоров 2013 по мнению Комерсантъ.ru
Поздравление c Днем Рождения Кирилла Соловейчика, учредителя Санкт-Петербургского клуба ИТ-директоров "SPb CIO Club"
Приглашение в крупный промышленный, научный и университетский центр французских Альп — Гренобль
Энергетик для вашего бизнеса
«Гиперавтоматизация-2024»: экосистема повышения операционной эффективности
Road-Show BPMSoft