Контакты
Подписка
МЕНЮ
Контакты
Подписка

Принципы и подходы к эффективной интеграции различных систем автоматизации

В рубрику "ИТ-интеграция" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Принципы и подходы к эффективной интеграции различных систем автоматизации

Под интеграцией в данном материале я подразумеваю создание механизмов (элементов или модулей в самих системах автоматизации или отдельно стоящих программ), предназначенных для полного или практически полного (не менее 95%) устранения всякого рода ручных "переделов" данных при их передаче между различными системами автоматизации компании в процессе промышленной эксплуатации
Антон Левиков
ИТ-директор ГК "НОВАРД"

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

Интеграция

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


Принцип количественной оценки эффективности интеграции

Я призываю для небольших объемов данных (имеется в виду объем данных, на ввод которых сотрудник затрачивает один рабочий день) подтверждать необходимость интеграции оценкой ее эффективности. При росте объемов данных оценку эффективности работ по их интеграции производить нужно в рамках подтверждения результативности. А решение о необходимости интеграции при больших объемах данных принимается, что называется, "по умолчанию".

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

Случай 1. Когда компания молода и невелика

Например, новый интернет-магазин. В это время, как правило, доходов у компании мало, а расходов – много. Руководство и сотрудники не успевают заниматься отладкой бизнес-процессов (да и не настало еще для этого время). Бухгалтер в компанию приходит со "своим" 1С (или не приходит совсем, потому что бухгалтерский учет отдан целиком на аутсорсинг), специалисту по закупкам хватает Excel, а менеджер по продажам пользуется интернет-магазином как сервисом из Интернета. Своих ИТ-шников нет – максимум знакомый ИТ-специалист помогает удаленно или раз в неделю появляется в компании для решения неотложных проблем.

При таком раскладе вариантов немного: либо переносить данные через Excel, либо вводить вручную с документов. И так можно жить до тех пор, пока объем данных перестанет быть "небольшим".

Случай 2. Обособленная система автоматизации

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

Случай 3. Компания со сложным, но не очень интенсивным бизнес-процессом

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


Считаю эту задачу отлично подходящей для организации серьезного проекта интеграции. Но если 50 человек 2–3 раза в год тратят время на то, чтобы вспомнить последовательность действий, а затем в течение 15 минут выполнить это, то стоит ли такая игра свеч?

Случай 4. Сбор (консолидация) данных

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

Подобный бизнес-процесс не требует интеграции. Минимум, которым можно обойтись, – это сводная таблица в Excel, максимум – специальное ПО для консолидации данных (если нужно сохранять версионность и т.д.).

Случай 5. "Зоопарк"

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

Обычная ситуация для интенсивно развивающихся компаний "с историей". Своя система у финансистов, у логистиков, что-то своими силами написано для автоматизации продаж, какая-то устаревшая система BI любима руководством, а бухгалтерия – 1С 7.7. Усугубляется все это политическими моментами (пользователи могут лоббировать использование привычных им систем, руководство компании может явно ставить задачи интеграции в каких-то наиболее важных, на взгляд самого руководства, и т.д.)

Делать интеграцию всех систем со всеми – верная гибель. У интегратора при таком раскладе есть два пути.

Первый – сложный, затратный и правильный – разгонять зоопарк (сокращать количество систем, в идеале – до одной или двух, – и таким образом сокращать количество "переделов" данных). Проблемы этого пути известны и являются, по факту, проблемами внедрения ERP-системы (необходимость реинжиниринга бизнес-процессов, поиски активных заказчиков и т.д. – не тема данного материала).

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

Опубликовано: Журнал "Системы безопасности" #5, 2015
Посещений: 4400

  Автор

Антон Левиков

Антон Левиков

ИТ-директор ГК "НОВАРД"

Всего статей:  1

В рубрику "ИТ-интеграция" | К списку рубрик  |  К списку авторов  |  К списку публикаций