Регламент интеграции информационной системы и Принципы и методы интеграции систем контроля доступа и учета с другими информационными системами компании

Ниже представлен пример проектного документа “Концепция интеграции информационных систем” который включает в себя предварительное описание регламента информационного взаимодействия.
Данный документ формируется IT-специалистом на этапе проектирования потоков данных интеграции и интерфейсов интеграции (обмена данными).

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

Описание текущих интеграционных процессов объекта автоматизации

В данном разделе документа приводится описание существующих потоков данных (процессов обмена данными между существующими информационными системами) в виде схемы потоков данных.

Например, приводится следующий текст:

На рисунке ниже представлена общая схема потоков данных взаимодействия между системами бухгалтерского учета, системами кадрового учета и другими информационными системами.

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

Интегрируемые информационные системы

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

В рамки проекта внедрения системы ERP предполагается организация взаимодействия со следующими существующими информационными системами:
– Система финансового планирования (Управляющая компания), верс. X.Y.
– Система финансового планирования (Филиал) OFA, верс. X.Y.
– Система ведения договоров (Управляющая компания)) , верс. X.Y.
– Файлы с данными по учету расчетов с акционерами, для филиала и управляющей компании.

Схема потоков данных

В данном разделе проектного документа приводится схема потоков данных, описывающая будущие потоки интеграции (обмена данными) между информационными системами.
Схема потоков данных может приводится как в свободной форме, при этом обязательно необходимо её описание, так и в виде, например, DFD диаграмм.

На рисунке ниже представлена схема потоков данных при организации синхронизации в рамках внедрения проекта ERP.

Периодичность обмена данными

Приводится периодичность осуществления обмена данными между информационными системами.

Описание интерфейсов интеграции информационных систем

В данном разделе приводится описание интерфейсов интеграции информационных системам.
При этом описываются интерфейсы каждого потока и типа данных в отдельности.

Данные по НСИ ведутся в исключительно в ERP и передаются в MS Axapta.
В MS Axapta переданные данные не корректируются.
Справочники передаются и загружаются каждый раз полностью, без захвата изменений.
Удаленные записи имеют соответствующую отметку в специальном поле.

Ниже приведено описание интерфейсов передачи данных (Типы данных: D – Data; C – Char/Text; N – Number).

Организационные мероприятия

В данном разделе приводится перечень организационных мероприятий, которые необходимо выполнить до начала разработки процессов интеграции (обмена данными).

Для обеспечения реализации интеграционных процессов необходимо провести следующие мероприятия:

Что учесть при разработке интеграций информационных систем

Невозможно представить современную информационную систему (далее – ИС), которая бы стояла особняком, и не была бы интегрирована с другими. Особенно, если мы говорим о корпоративных или государственных данных. Вопросу интеграций посвящены целые книги, такие как «Шаблоны интеграции корпоративных приложений» Грегора Хопа. Некоторые издания пытаются рассматривать не только технические, но и организационные вопросы интеграции (например, «Предметно-ориентированное проектирование (DDD)» Эрика Эванса). Между тем, современный уровень технологий и высокий уровень компетентности разработчиков очень сильно снижает технические риски, выставляя на первый план организационные. В этой статье мы рассмотрим интеграции информационных систем именно с точки зрения организационных рисков.

Взгляд на ИС сквозь призму команд

Как правило, при проектировании новой системы, или во время изучения ТЗ, на интеграции смотрят под следующими углами:

• Интеграция одной подсистемы с другой;
• Интеграция с другими ИС внутреннего ИТ-ландшафта заказчика (т.е. смежными ИС);
• Интеграция с внешними ИС по отношению к Заказчику, т.е. за пределами его ИТ-ландшафта.

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

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

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

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

Схема взаимодействия с поставщиком интеграции

В книге Эванса приводятся варианты схем взаимодействия команд при интеграции контекстов, часть из которых можно рассматривать и для интеграции систем.

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

На предварительных этапах многие приходят к выбору либо схемы Заказчик/Поставщик, либо Публичного API. Всем понятно, что схема Конформист не позволит взять исполнителю контракта хоть какую-то ответственность на себя. Но, не смотря на заявления заказчика, по итогу любая схема может превратиться в Конформиста.

Наша задача определить детали схемы взаимодействия как можно раньше чтобы выявить элементы скрытой схемы Конформиста. При предполагаемой схеме Поставщик/Заказчик на этапе предконтрактных работ должно насторожить следующее:

• Заказчик не знакомит команду Потребитель с командой Разработчик.
• Команда Разработчик не готова детально обсуждать схему взаимодействия и другие технические аспекты во время выполнения работ.
• Есть информация, что отношения между Заказчиком ИС и командой Разработчик натянутые (интеграция с вами может стать предметом чужих торгов).
• Вы не ощущаете у Заказчика сил продавливать необходимость реализации интеграции в команде Разработчик.

При предлагаемой схеме Публичного API могут насторожить такие факты:

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

Как защитить проект на этапе контрактации

При контрактации самая распространенная схема — это Поставщик/Заказчик.

В теории вы, как возможный исполнитель контракта, должен составить ТЗ для необходимых вам изменений, и передать его на согласование Заказчику. А он уже передаст его команде Разработчик, которая выполнит Ваше ТЗ «в кратчайшие сроки и с наилучшим качеством». Только в жизни все может получиться по-другому.

Заказчик, как правило, укажет на Исполнителя и скажет, что нужно договариваться с ним напрямую за счет бюджета проекта. А это уже совсем другая история. Появляется огромная проблема непредсказуемости по всем направлениям – начиная от готовности взяться за подряд и заканчивая его сроками и бюджетом. Подрядчик внешняя организация, и формально рычагов давления на неё нет.

Для минимизации рисков обязательно нужно четко прописывать зону ответственности Заказчика в контракте (используйте пункт «Вклад Заказчика» в ТЗ). При этом прописывайте вклад как можно конкретнее. Заказчик должен:

• Предоставить всю необходимую документацию для реализации интеграции.
• Предоставить тестовые данные (про тестовые данные у нас есть отдельная статья.
• Обеспечить сетевую связность.
• Заключить договор субподряда с командой Разработчиком интеграции (это сложный пункт).

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

Кстати, иногда это бывает не так просто. У нас был случай при разработке инфраструктурной ИС X. По замыслу, порядка 30 региональных информационных систем должны были подключиться к ИС X. При этом заказчик настаивал на ответственности разработчика X за подключение этих ИС, и очень настойчиво хотел вписать это требования в условия закрытия контракта.

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

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

Еще один важный момент. Если есть возможность, то всячески избегайте требований к сдаче проекта, связанных с конкретной реализацией интеграций, если это не типовые подключения к СМЭВ или хорошо известные вам системы из IT-ландшафта заказчика. Обязательно требуйте пункта, который говорит о том, что в случае недоступности внешней интеграции, система может быть сдана на эмуляторе интеграции внешней системы (проще говоря – на моках). Разумные заказчики включают это допущение.

Минимизация рисков на этапе разработки

Независимо от того, как хорошо мы подстраховались в зоне ответственности заказчика, ещё остается вопрос времени. Время выполнения работ надо всегда держать на особом контроле.

Если не получилось составить ТЗ до контракта, или не удалось получить подробную документацию, то стартовать работы нужно сразу после заключения контракта.

Одновременно с этим следует запрашивать:

• Тестовые данные (почему важно как можно скорее получить тестовые данные, мы подробно писали в статье «Информационная Система с данными и без»).
• Доступы и сетевые связности.
• Подготовку документов для юридического обоснования интеграции.

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

Но не стоит оттягивать старт упомянутых активностей, какими бы ни были отношения с заказчиком и командами.

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

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

Что делать, когда интеграция пошла не по плану

Есть печальная новость: если интеграции зашли в тупик, то хороших вариантов действия уже нет.

Особенно, если вы разрабатываете в рамках госконтракта, и не предусмотрели пункт о сдаче на эмуляторах.

Есть пара возможных действий, с которыми можно пробовать продвигаться вперед:

• Начинаем писать официальные заказные письма Заказчику с требованиями предоставить доступ, документацию и т.п. Здесь сильно помогает пункт контракта «Вклад Заказчика», на который и будем ссылаться. Эти письма помогут доказать, что не вы виноваты в проблеме сдачи контракта в полном объеме.
• В соответствии с ФЗ-44 и Гражданским кодексом вы можете приостановить работы по контракту до получения нужной информации. Для этого сценария вам следует предварительно изучить вопрос.

Надо понимать, чтобы оба этих пункта это уже, по сути, конфликтная ситуация с Заказчиком, что само по себе крайне плохо. Ждать условия завершения контракта можно долго, а вы ведь рассчитывали на определенные сроки выполнения. У вас команда разработки простаивает.

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

Резюме

Итак, что нужно сделать при проектировании и разработке интеграции:

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

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

Принципы и приемы интеграции систем контроля и учета доступа с другими информационными системами предприятия

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

СКУД с интеграциями и без

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

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

Пока сведения о проходах и прочая статистика хранятся только в системе контроля и учета доступа, она практически недоступна для исследования и визуализации. В сфере информационной безопасности существуют системы защиты периметра, которые также фиксируют входящий и исходящий трафик, регулируют доступ. События пропуска и блокировки трафика фиксируются в журналах устройств и программного обеспечения. Но, в отличие от СКУД, эти журналы изначально предназначены для анализа и экспорта в специальные аналитические системы, способные не только анализировать данные, но и строить прогнозы, – SIEM (Security Information and Event Management). Специалистам по информационной безопасности такой инструмент доступен, а сотрудникам физической СБ – нет.

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

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

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

Рис. 1. Синергия безопасности

Рис. 2. Синергия СКУД и ИТ

HRM. Системы управления персоналом

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

Поэтому первым делом, если в организации есть система кадрового делопроизводства и автоматизированная система контроля и управления доступом, необходимо исключить двойной ввод данных, а именно:

• При оформлении сотрудника в системе КДП на основании сведений о подразделении, должности, графике работы система управления персоналом должна сформировать пакет данных для СКУД в составе:- фотографии; – перечня групп доступа; – ФИО; – других параметров, критичных для службы режима предприятия.На основании пакета СКУД должна полностью сформировать карточку сотрудника, назначить ему группы доступа, доступность площадок, видов авторизации, заполнить остальные поля карточки сотрудника в базе данных СКУД.В HRM также удобно настроить печать пропуска сотрудника, если компания использует персонифицированные пропуска на базе меток RFID. В таком случае уже после оформления документов новый сотрудник автоматически получает корректный согласованный доступ на территорию предприятия без ошибок и проволочек.
• При оформлении кадрового перевода сотрудника или оформлении замещения HRM должна повторно определить группы доступа сотрудника на основании новой должности, места работы и оповестить СКУД об изменении.
• После оформления приказа об увольнении СКУД должна получить команду на блокировку прохода сотрудника с момента увольнения.Службе режима не нужно будет следить за тем, чтобы на территорию не попадали бывшие сотрудники, у которых забыли изъять пропуска.
• Замену пропуска после утери можно сделать как через отдел КДП, так и через пост охраны, но лучше отдать эту функцию КДП, чтобы полностью исключить операторский доступ комендантов в СКУД. Коменданту достаточно отображения фото и ФИО сотрудника, проходящего контроль.

Рис. 3. HRM – системы управления персоналом

Взаимодействие HRM и СКУД не ограничивается только данными о сотрудниках и их полномочиях. Система контроля и управления доступом может стать поставщиком данных для автоматизированного выполнения таких процессов кадрового делопроизводства и управления персоналом, как:

• табелирование;
• контроль исполнения правил внутреннего трудового распорядка (опоздания, ранние уходы, частые перекуры, отлучения с предприятия);
• контроль начисления заработной платы “мертвым душам”.

Поскольку HRM обладает сведениями о графике сотрудника, составить фактический табель на основании данных о проходах и уходах не составляет труда. Можно вычислять не только явку, но и реальную продолжительность смены, если СКУД установлена в цеху.

Контроль правил ВТР открывает обширное поле для работы сотрудников кадров, специалистов по мотивации и руководителей подразделений.

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

На исполнении правил внутреннего трудового распорядка нужно остановиться особо. Американские социологи-криминалисты Джеймсон Уилсон и Джордж Келлинг в 1980-х гг. сформулировали теорию разбитых окон. Название происходит от приводимого авторами типичного примера действия теории: “Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна”. Нужно также вспомнить историю про исправление криминогенной ситуации в Нью-Йорке, которая началась с борьбы с мелкими преступлениями, такими как безбилетный проезд, граффити и т.п.

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

Рис. 4. Теория разбитых окон (подробнее по QR-коду)

ERP. Управление ресурсами предприятия

Объем возможной синергии при интеграции с ERP-системами не такой большой, как с системами управления персоналом, но здесь тоже можно найти несколько удачных примеров, которые позволили сократить штат и повысить безопасность бизнес-процессов предприятия.

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

Рис. 5. Автоматизация и фото-видеофиксация весовых пунктов и оборудования

Автоматическое формирование отгрузочных документов клиенту на горнодобывающем предприятии без участия сотрудников

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

Перед началом работ по интеграции нужно произвести следующую подготовку:

а) периметр компании должен быть огорожен, а въезд для клиентского грузового транспорта оборудован автоматическим шлагбаумом с системой СКУД, распознающей номер автомобиля;

б) автоматические автомобильные весы должны быть подключены к системе управления продажами предприятия так, чтобы ERP могла автоматически получать значение веса автомобиля;

в) на въезде на весы со стороны площадки хранения также нужно установить шлагбаум с системой распознавания номеров.

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

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

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

Безусловно, такая организация процесса не отменяет сложные схемы мошенничества с подменой качества гравия или фракции, но существенно снижает риски хищения.

Рис. 6. Схема взаимодействия TMS и WMS и функциональность

Автоматический расчет логистического плеча при убытии транспорта с территории площадки

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

Анализ перемещений сотрудников по предприятию

Расстояние между считывателями вычислить несложно. По данным событий СКУД можно построить пути перемещения сотрудников по предприятию и выявить наиболее “длинные процессы”. Перемещения – это один из видов потерь, по теории бережливого производства, с которым можно и нужно бороться. Анализ перемещений сотрудников поможет выявить производственные цепочки, которые построены неэффективно, а также административные процессы, которые требуют от сотрудника несколько раз за смену пересекать всю территорию предприятия для выполнения своих обязанностей.

Рис. 7. Табло информационной системы YMS

WMS/TMS. Системы управления складом и транспортом

Возможности СКУД в области распознавания номерных знаков транспортных средств могут существенно облегчить работу логистическим подразделениям компании за счет предоставления сведений о проезде транспорта через КПП и регулирования разрешений выхода транспорта с территории предприятия, например:

• Разрешение на въезд под погрузку выдается только тем транспортным средствам, которые указаны в открытых маршрутных листах.
• Доступ на корпоративную стоянку регулируется списком разрешенных номеров, которые формируются TMS- и HRM-системами.
• Факт постановки автомобиля в конкретный док автоматически сообщается WMS, которая перестраивает работу участка отгрузки.
• Разрешение на выезд транспорта на КПП выдается WMS только при наличии всех оформленных документов и заключения врача.

На рынке даже присутствуют специализированные решения YMS (система управления двором), которые представляют собой конвергенцию СКУД и ТМS и предназначены для автоматизированного управления движением транспорта, очередями и механизацией ворот.

Охрана труда

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

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

Рис. 8. Схема SIEM-системы

SIEM. Система управления событиями безопасности

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

Я уверен, что это далеко не полный список классов корпоративных информационных систем, с которыми имеет смысл интегрировать СКУД, но приведенные примеры помогут вам найти собственные уникальные решения для своей организации.

Принципы интеграции

Принципы интеграции СКУД с другими системами не отличаются от классических правил интеграции. Они очень просты и логичны.

• Доверяйте профессионалом. Любые системы интеграции работают без человека, а пользователь доверяет тому, что они работают, и работают корректно. С развитием цифровой культуры компании руководители все больше и больше начинают полагаться на 100%-ную бесперебойность работы процессов, и каждый сбой грозит остановкой работы площадки или целого предприятия. В таких условиях было бы разумно доверить интеграцию между системами производителю или авторизованному партнеру производителя одной из систем. К примеру, если вы интегрируете СКУД с “1С: Зарплата и управление персоналом”, поручите эту работу опытному франчайзи 1С, поскольку интеграцию нужно не только создать, но создать так, чтобы последующее обновление HRM не сломало ее.
• Должно работать само. Если у вас по бизнес-процессу хоть в одном месте должен принимать решение человек, то такая интеграция работать не будет. Человек, принимающий решение, все равно руководствуется правилами или опытом.Правила нужно актуализировать, опыт оцифровать и описать, а на основе полученного документа определить автоматические правила и исключить человеческий фактор.
• Если не работает – сообщает. В состав требований высокого уровня обязательно включите требование мониторинга работы интеграции и оповещение о наличии ошибок, конфликтов и блокировок. Это позволит узнать о проблеме раньше, чем ее влияние почувствует бизнес.Согласитесь, что если на вопрос бизнеса о том, что случилось, вы выдаете полную картину ситуации, то накал страстей бывает существенно ниже, чем если бы вы ответили, что впервые слышите о проблеме.
• Учитывайте 152-ФЗ. Согласно разъяснению Роскомнадзора фотография сотрудника в совокупности с его ФИО являются биометрическими данными и должны быть защищены соответствующим образом. Если сервер СКУД размещен на территории третьего лица, то должно быть оформлено соглашение о передаче персональных данных.
• Обрабатывайте исключения. В процессе проектирования необходимо рассмотреть все варианты отказов, которые можно предположить на этапе создания системы, например:- отказ одной из систем; – повреждение пакета с данными; – ошибка разработчика при формировании пакета с данными; – различие версий фактически используемого и поддерживаемого протокола и пр.
• Оставляйте пути для работы вручную. Всегда должен оставаться аварийный план. Если вдруг интеграция сломалась серьезно и починить ее быстро невозможно, то ответственный сотрудник должен достать регламент бумажного процесса, сдуть с него пыль и начать работать без ИТ-систем.

Рис. 9. Интеграция по принципу точка-точка

Протоколы интеграции

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

Обмен файлами

Самый старый и самый простой механизм. Одна система записывает файл и сохраняет в общем каталоге, который доступен и отправителю, и получателю. Получатель при появлении файла в каталоге открывает его в режиме чтения и загружает информацию. Это самый ненадежный способ передачи. Он имеет множество уязвимостей и потенциальных мест отказа. Разработчику нужно следить не только за содержимым и версией разметки содержимого, но и за доступностью каталога, наличием необработанных пакетов и множеством других параметров для обеспечения максимальной отказоустойчивости. Данный протокол подходит для разовых или очень редких обменов, которые выполняются под контролем администратора.

Прямой вызов исполняемых файлов

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

Прямое обращение к базе данных

Самый быстрый протокол в реализации. Любая промышленная СКУД хранит свои данные в базе данных. Обычно не составляет большого труда разобраться в том, где и как система контроля хранит данные, и забрать оттуда то, что требуется для приемника. Сложнее с необходимостью записать что-либо в базу данных СКУД.

Простота структуры базы данных может быть обманчива. Некоторые производители, даже 1С, в лицензионном соглашении запрещают прямой доступ к базе данных, поскольку разработчик может учесть не все нюансы структуры и сломать работу системы так, что потребуется восстановление из резервной копии.

Самый распространенный и самый безопасный способ обмена. Системы взаимодействуют между собой как веб-серверы в сети “Интернет”.

Отправитель отправляет запрос, получатель его авторизует, обрабатывает. Всегда можно разобраться в том, что пошло не так, поскольку журналы веб-серверов доступны, а за работой системы интеграции и передачей пакетов администратор может следить в реальном времени.

С другой стороны, наличие промежуточной системы уменьшает производительность системы интеграции. Из всех перечисленных он самый медленный.

Ремарка для коллег из ИТ. Приведенные выше оценки не являются исчерпывающими. Мне знакомы системы интеграции REST, которые работали гораздо быстрее, чем RPC, но это скорее исключение, чем правило.

Рис. 10. Интеграция по принципу точка-центр (рисунок автора)

Виды интеграции

Это самый распространенный вариант интеграции. Две системы связываются напрямую. Связь может быть как однонаправленная, так и двунаправленная.

• Быстро реализовать. Нужно знать протоколы только двух систем.
• Легко поддерживать. По интеграционной связи передаются четко определенные ограниченные данные.
• Стандартизация не нужна. Для каждой связи “точка-точка” может быть использован свой уникальный протокол.

• Данные остаются в локальных системах.Невозможно агрегировать и анализировать данные нескольких систем и находить взаимосвязи.
• Трудно поддерживать множество разнородных связей интеграции. Если используются разные протоколы, то для каждого или группы сходных нужен отдельный профильный специалист.

“Точка-центр”

Такой тип интеграции используется редко. В качестве мастер-системы выбирается одна, как правило ERP, с которой остальные системы строят связи “точка-точка”. Пакеты данных периферических систем отправляются в мастер-систему, которая перенаправляет их в другие системы, если такое заложено логикой интеграции.

• Полученные данные можно использовать повторно. Пакеты, полученные из одной связанной системы, могут быть отправлены более чем в одну связанную систему.
• Данные можно анализировать и агрегировать.Поскольку центральная система вынуждена хранить получаемые и отправляемые данные внутри себя, то задача извлечения и анализа данных не является технически сложной.
• Стандартизация желательна, но не обязательна, так как каждая связанная система может обмениваться с центром по своему протоколу.

• Большая нагрузка на центральную систему.Множество связанных систем вызывают интеграционные компоненты центральной системы, что существенно увеличивает требования по производительности серверов приложений и базы данных. Учитывая, что центральная система и так сильно нагружена, большое количество интеграций может ее “уронить”.
• Хранение избыточных данных. ERP, которую чаще всего выбирают в качестве центральной системы, не предназначена для хранения промежуточных данных обменов. Прежде всего это система управления предприятием, а не хранилище. Расширение базы данных центральной базы негативно сказывается на общей производительности ERP.
• Сложный поиск и исправление ошибок синхронизации. Использование различных протоколов усугубляется их взаимодействием с логикой транспорта до других связанных систем внутри центральной системы. Найти точку отказа, когда связанная система-“отправитель” отправила, а связанная система-“получатель” получила что-то не то, очень сложно.

Рис. 11. Шина данных (рисунок автора)

ESB. Шина данных

Шина данных – это специализированный программный продукт. Единственной его задачей является транспорт данных между информационными системами предприятия. Примерами таких решений могут послужить Microsoft Biztalk Server, Datarion, 1С: Шина данных и др.

Шина данных состоит из следующих компонентов:

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

• Легко подключать новые системы. Достаточно использовать коннектор, поставляемый поставщиком, или написать свой.
• Нет нагрузки на бизнес-системы. Шина данных работает в отдельной инфраструктуре.
• Удобный контроль и версионирование данных. Системы типа ESB имеют специальную функциональность для разрешения коллизий и гарантированной доставки пакетов данных.

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

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

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

Рис. 12. Озеро данных как часть интеграции (рисунок автора)

Заключение

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

1 Абсентеизм (absenteeism) – уклонение от работы без уважительной причины.

2 Теория разбитых окон (англ. broken windows theor y) – криминологическая теория, рассматривающая мелкие правонарушения не только как индикатор криминогенной обстановки, но и как активный фактор, влияющий на уровень преступности в целом. Сформулирована американскими социологами Джеймсом Уилсоном и Джорджем Келлингом, впервые опубликована в 1982 г. в журнале The Atlantic Monthly.

Опубликовано в журнале “Системы безопасности” № 4/2022

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

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

Качество данных

Отсутствие качественных данных (приведенных к единому формату, недублирующихся, согласованных между собой, без “мусорных” записей) в информационных системах многих компаний является данностью, с которой приходится работать. Зачастую этот факт при внедрении новых ИС не учитывается, и в конце реализации проекта компания получает еще одну систему со своим набором данных, слабо согласующимися с данными других систем. В таких случаях при попытке настройки взаимодействия несогласованность данных приводит к тому, что интеграция систем есть, а интеграции данных нет. Может даже получиться несколько наборов данных в одной системе идентичных по сути, но разных по представлению (например, “юр. лицо” и “Юридические лица”).

Решать задачу согласованности данных призваны системы управления мастер-данными (Master Data Management, MDM). Но сегодня эти системы в российских компаниях являются больше экзотикой, чем нормой (об этом свидетельствует список референсов основных поставщиков MDM-решений). В отсутствии единой MDM-системы в компании задачи согласования данных и обеспечения их качества ложатся на процессы интеграции. Для этого разрабатываются бизнес-правила преобразования данных, создаются таблицы соответствия и т.п. решения, что по сути своей представляет систему MDM для одного или группы интеграционных процессов.

Конечно, не рекомендуется решать задачи интеграции, миграции данных и задачи улучшения качества данных, дедубликации в рамках одного проекта. Но если выхода нет, то прежде чем начинать разрабатывать бизнес-правила и таблицы соответствия, необходимо изучить данные, провести их предварительный анализа путем профилирования (Data Profiling). Проведение профилирования позволяет получить информацию о содержании, качестве и структуре данных. Этот важный этап, предшествующий этапу проектирования процессов интеграции, очень часто игнорируется, что приводит в итоге к несогласованности данных в интегрируемых системах. Еще одной важной задачей профилирования данных является сужение множества передаваемых данных, ведь в процессе анализа можно выявить “мусорные”, дублирующиеся или ненужные вообще для передачи данные.

Итак, к типичным проблемам интеграции, связанным с качеством данных, можно отнести:

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

Организационные трудности

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

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

Еще одной сложностью, с которой приходится сталкиваться – это закрытость служб сопровождения и разработчиков информационных систем компании Заказчика. Например, при построении хранилища данных необходимо проводить анализ данных и их структуры, хранящихся в системах-источниках. Но зачастую изучить их не получается по причине того, что не предоставляется документация, запрещается доступ к системе-источнику, отсутствуют примеры данных и т.д. В таком случае специалистами Заказчика применяется следующий подход при взаимодействии с Разработчиком: “Скажите, что Вам нужно, а мы дадим только то, что из этого есть в системе”. Это приводит к тому, что у бизнес-аналитиков и специалиста по модели данных складывается неполная картина о имеющихся данных в компании. Как результат, неполное хранилище данных. Избежать этого можно только путем правильной ориентацией специалистов Заказчика на взаимодействие с консультантами Разработчика.

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

Резюмируя перечень организационных трудностей, можно сказать, что к ним относятся:

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

Технические трудности

Процесс организации интеграции сводится к следующим действиям:

• определение источника/приемника данных;
• анализ данных источника;
• выбор инструмента интеграции;
• согласование форматов, способа и периодичности обмена данными (согласование регламента интеграции);
• проектирование и разработка процессов интеграции;
• тестирование;
• промышленная эксплуатация.

При этом почти всегда основные трудности возникают на этапах разработки и тестирования. Но причины для их появления закладываются раньше.

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

Еще одной ошибкой, связанной с интеграционной платформой, является её неправильное использование. Нет смысла покупать Informatica PowerCenter для того, чтобы всю логику преобразования данных реализовать на языке PL/SQL базы данных Oracle.

Стремление разработчиков к универсальности и применению передовых технологий, форматов, шаблонов и т.п. может излишне усложнить решение по интеграции. Организация обмена данными через web-сервисы порой приводит к задержкам передачи и обработки большого объема данных, усложнению выявления ошибок в данных в огромных xml-файлах и т.д. Все стремится к простоте. При организации процессов интеграции не следует их усложнять без необходимости протоколами с шифрованием, web-сервисами, гарантированной доставкой и т.п.

Подводя итог под техническими трудностями, можно сказать, что к ним относятся:

• выбор неподходящей платформы интеграции;
• неверное использование платформы интеграции;
• излишнее усложнение решения.

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