В портфолио Sphere есть проект для государственного заказчика: автоматизация получения данных для ведомственной системы. Задача здесь не в том, чтобы построить систему с нуля. Нужно, чтобы сведения попадали в неё сами, без ручного ввода, писем с вложениями и переписывания таблиц.
В этом кейсе разбираем, из чего состоит автоматизация сбора данных для ведомственной системы, какие решения приходится принимать и как мы подходим к таким задачам по своим этапам. Подробности проекта и заказчика по договорённости не раскрываем, поэтому говорим о задаче этого типа в целом.
Что значит автоматизировать получение данных
Во многих организациях данные в информационную систему попадают так: источник выгружает таблицу, отправляет её по почте, сотрудник открывает файл, сверяет и переносит значения вручную. Это работает, пока источников немного и данные приходят редко.
Когда источников много, а обновления нужны регулярно, ручной процесс начинает ломаться. Появляются опечатки, пропущенные файлы, разные версии одной таблицы, задержки из-за отпусков и больничных. Никто не может быстро ответить, откуда взялось конкретное значение и когда оно обновилось.
Признаки того, что ручной сбор данных пора автоматизировать:
- сотрудники тратят часы в неделю на перенос данных из файлов и писем;
- одни и те же ошибки повторяются: опечатки, перепутанные коды, пропущенные строки;
- данные в системе отстают от реальности на дни или недели;
- непонятно, какой источник прислал конкретное значение и когда;
- подключение нового источника каждый раз превращается в отдельную ручную процедуру;
- процесс держится на одном-двух людях, которые знают все форматы и исключения.
Автоматизация обмена данными убирает из этой цепочки ручные шаги. Данные приходят по согласованному каналу, проверяются и загружаются, а сотрудники работают только с исключениями: записями, которые не прошли проверку или требуют решения человека.
Источники данных и каналы обмена
Первая задача — составить карту источников. Для каждого фиксируют: какие сведения он передаёт, в каком формате, как часто, кто за него отвечает и что он технически умеет. От этого зависит канал получения данных.
| Когда подходит | Что учесть | |
|---|---|---|
| API | У источника есть программный интерфейс или его можно сделать | Авторизация, лимиты, версии API |
| Обмен файлами | Источник умеет выгружать данные по расписанию | Единый формат, контроль полноты выгрузки |
| Форма ввода | Данные передают люди, а не системы | Проверка полей, справочники, понятный интерфейс |
| Ручная загрузка файла | Источник редкий или временный | Шаблон и проверка файла при загрузке |
Часто в одной задаче используются сразу несколько каналов: крупные источники подключаются через API, небольшие передают файлы или заполняют формы. Важно, чтобы после получения все данные проходили один и тот же путь проверки и загрузки.
Качество данных: проверка до загрузки
Автоматическая загрузка без проверки опаснее ручного ввода: ошибка источника мгновенно попадает в систему, и её никто не замечает. Поэтому между получением и загрузкой стоит слой проверки.
- формат и тип каждого поля: даты, числа, коды;
- обязательные поля заполнены;
- значения соответствуют справочникам системы или отраслевого реестра;
- нет дублей внутри пакета и с уже загруженными записями;
- логические связи между полями не нарушены;
- объём пакета похож на обычный: резкий провал или всплеск — повод остановиться и проверить.
Записи, которые не прошли проверку, не теряются. Они попадают в отдельный список с понятной причиной отказа, а источник или оператор получает уведомление. Так ошибки исправляют там, где они возникли, а не правят вручную внутри системы.
Автоматизация сбора данных стоит ровно столько, сколько стоит доверие к загруженным данным.
Надёжность обмена: что будет, если что-то сломается
Источник может быть недоступен, файл — прийти не полностью, сеть — оборваться посреди передачи. Система обмена должна переживать такие сбои без потери данных и без участия разработчика.
- Повторные попытки. Если источник не ответил, запрос повторяется по расписанию, а не теряется.
- Идемпотентность. Повторная загрузка того же пакета не создаёт дублей.
- Журнал операций. Для каждой записи видно, откуда и когда она пришла, какие проверки прошла и что с ней стало.
- Мониторинг и оповещения. Ответственные узнают о сбое сразу, а не когда кто-то заметит устаревшие данные.
- Возможность отката. Ошибочный пакет можно отменить целиком.
Журнал операций отвечает на вопрос «откуда это значение» за минуту, а не за день переписки. Для ведомственной системы, где данные используются в отчётах и решениях, это особенно важно.
Интерфейс для сотрудников: работа с исключениями
Даже при полной автоматизации людям нужен рабочий экран: посмотреть, что пришло, разобрать ошибки и принять решения там, где правила не справляются. Без него сотрудники снова начнут вести параллельные таблицы.
Что обычно нужно на таком экране:
- таблица записей с фильтрами по источнику, дате, статусу;
- статусы загрузок: успешно, с ошибками, в ожидании;
- список отклонённых записей с причиной и возможностью исправить и загрузить повторно;
- история изменений по каждой записи;
- роли и права: кто может только смотреть, а кто — подтверждать или исправлять.
Если часть сведений приходит в виде сканов и документов, а не таблиц, распознавание можно добавить отдельным шагом. Результат всё равно проходит те же проверки и попадает к человеку при сомнениях.
Интеграция с государственной информационной системой: на что закладывать время
Разработка для госсектора отличается не столько технологиями, сколько требованиями. Государственные информационные системы подчиняются требованиям к защите информации, а если в данных есть персональные сведения, — ещё и законодательству о персональных данных. Конкретный состав мер определяет государственный заказчик и его служба безопасности.
Для команды разработки это значит несколько практических правил:
- формат обмена и справочники обычно задаёт принимающая система, и под них подстраиваются источники;
- передаются только те данные, которые нужны системе;
- каналы обмена шифруются, доступ разграничивается по ролям, действия пользователей журналируются;
- инфраструктуру, тестовую среду и порядок доступа согласовывают с заказчиком заранее;
- документацию готовят параллельно с разработкой, а не после неё.
Как мы подходим к автоматизации обмена данными
Sphere — агентство разработки из Москвы: мы делаем сайты, приложения и веб-сервисы, в том числе интеграции между системами. Задачу автоматизации сбора данных мы раскладываем по своим этапам:
- Аналитика и разбор процессов. Составляем карту источников и текущего процесса: кто, что и как передаёт, где теряется время и возникают ошибки. Изучаем систему-получатель, её форматы, справочники и ограничения.
- Техническое задание и архитектура. Для каждого источника выбираем канал обмена, описываем форматы, правила проверки, обработку ошибок, роли и требования безопасности.
- Дизайн рабочих экранов. Проектируем интерфейс для сотрудников: мониторинг загрузок, разбор исключений, история записей. Проверяем сценарии на тех, кто будет работать с ними каждый день.
- Разработка и тесты. Реализуем подключения к источникам, проверки, загрузку и журналирование. Прогоняем обмен на копии реальных данных, проверяем сбои и повторную загрузку.
- Запуск и развитие. Подключаем источники поэтапно, параллельно со старым процессом, пока не убедимся, что данные совпадают. Затем отключаем ручные шаги и подключаем новые источники по мере появления.
Тот же подход работает и в коммерческих проектах: синхронизация сайта с учётной системой, обмен данными между CRM и складом, сбор отчётности от филиалов. Другие задачи такого рода можно посмотреть в разделе проекты IT-агентства Sphere.
Частые вопросы
Что такое автоматизация сбора данных для информационной системы?
Это замена ручного ввода, писем и пересылки таблиц автоматическим получением сведений из источников: через API, обмен файлами по расписанию или формы ввода. Данные при этом проверяются, приводятся к единому виду и загружаются в систему с журналом, по которому видно, что, когда и откуда пришло.
Что делать, если у источника данных нет API?
Есть рабочие варианты: регулярный обмен файлами в согласованном формате, выгрузка из базы источника по расписанию, веб-форма или шаблон для тех, кто передаёт данные вручную. Иногда API дорабатывают на стороне источника. Выбор зависит от объёма, частоты обновления и того, кто отвечает за источник.
Как сделать, чтобы автоматическая загрузка не испортила данные в системе?
Каждую запись проверяют до загрузки: формат, обязательные поля, соответствие справочникам, дубли. Ошибочные записи не попадают в систему, а уходят в отдельный список с причиной отказа. Все операции журналируются, загрузку можно повторить или откатить. Перед запуском обмен прогоняют на копии реальных данных.
Чем интеграция с государственной информационной системой отличается от коммерческой?
Технически принципы те же: каналы обмена, проверка данных, журналирование. Отличаются требования: формат обмена обычно задаёт принимающая сторона, к защите информации и документации предъявляют повышенные требования, а изменения проходят согласования. Это стоит учитывать в сроках с самого начала.
Берётся ли IT-агентство за разработку для госсектора?
Да, если команда готова работать с требованиями государственного заказчика к защите информации, согласованиями и документацией. В портфолио IT-агентства Sphere есть проекты для государственных заказчиков, а интеграции и автоматизацию обмена данными мы ведём для компаний из Москвы и по России.
