17 000 документов, 2000 сотрудников и 450 машин: как мы автоматизировали пропускной режим на Ямале

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

Например, оформление пропуска.

Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.

Что здесь вообще автоматизировать?

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

• Около 2000 сотрудников

• 450 единиц техники

• Более 17 000 документов

• Разные заказчики с разными требованиями

• Документы на сотрудника, автомобиль, прицеп и находящееся в машине оборудование

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

И одна отсутствующая «бумажка» может закончиться тем, что тяжёлый автомобиль проедет 700 километров, развернётся на проходной и поедет обратно.

У заказчика было известно как минимум о пяти подобных случаях.

Эту задачу мы решали в рамках внедрения разработанной нами АСК «Легарус». Но дальше речь будет не столько о самой системе, сколько о конкретном бизнес-процессе и технических решениях, которые пришлось использовать для его автоматизации.

Довольно быстро выяснилось, что мы автоматизируем вовсе не «учёт пропусков».

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

можно ли конкретному сотруднику на конкретной машине с конкретным оборудованием попасть на конкретный объект конкретного заказчика в конкретную дату?

Поясню, как мы к этому пришли и как в итоге устроили процесс.

Как всё работало до автоматизации

Заказчик — транспортно-строительная компания на Ямале, работающая в том числе на объектах нефтегазовой отрасли.

Около 2000 сотрудников и примерно 450 единиц техники.

Значительная часть внутренних процессов исторически существовала в чатах, файлах и головах конкретных людей.

Это, кстати, совершенно обычная ситуация.

Процесс есть.

Все по нему работают.

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

С пропусками было примерно так же.

Для допуска одного сотрудника к объекту может потребоваться порядка двух десятков документов.

Но сотрудником дело не заканчивается:

• Есть автомобиль

• Прицеп

• Оборудование внутри автомобиля

• У каждого заказчика свои требования

• У документов разные сроки действия

Сотрудник сегодня может соответствовать требованиям одного объекта и не соответствовать требованиям другого.

А иногда маршрут до объекта заказчика проходит через территорию другой компании — и тогда появляется ещё один набор требований.

До автоматизации всем этим занимались от четырёх до шести специалистов.

И даже при таком количестве людей ошибки происходили.

Сколько может стоить один отсутствующий документ

Самый наглядный пример выглядел так.

Тяжёлый автомобиль отправили на объект примерно за 700 километров.

Он приехал.

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

На объект машину не пропустили.

Автомобиль развернулся и отправился обратно.

Получилось примерно 1400 километров бесполезного пробега тяжёлой техники.

Топливо. Рабочее время водителя. Амортизация.Простой.

Плюс сорванная работа, которую машина должна была выполнять на объекте.

И всё из-за одного документа.

Это был не единственный случай. Нам известно как минимум о трёх похожих.

Кроме того, заказчики выставляли штрафы за проблемы с пропусками и разрешительной документацией. Компания оценивала такие потери примерно в 1,5–2 млн рублей в год.

После этого вопрос о целесообразности автоматизации особенно не обсуждался.

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

Первое очевидное решение — собрать все документы в одном месте.

Есть сотрудник Иванов.

У него есть паспорт, удостоверение, медосмотр, обучение и ещё пятнадцать документов.

Сохранили файлы, записали даты окончания — казалось бы, задача решена.

Но наличие документа само по себе почти ничего не означает.

Системе нужно ответить не на вопрос:

«Есть ли у Иванова медицинская справка?»

А примерно на такой:

«Может ли Иванов завтра проехать на автомобиле №123 с прицепом №45654 и геодезическим прибором серийный номер 85746374 через территорию компании А и выполнить работу на объекте компании Б?»

А это уже несколько связанных сущностей и несколько независимых наборов правил.

В итоге у нас получилась примерно такая логика:

 То есть в центре модели находится не документ и даже не пропуск.

В центре находится правило допустимости определённой комбинации.

Система проверяет не наличие отдельного документа, а допустимость всей комбинации «субъект + заказчик + объект + комплект документов» на момент оформления пропуска.

Как мы разложили процесс на сущности

В упрощённом виде модель выглядит так:

Для разных типов субъектов используется общая логика через связи.

Но здесь оказалось важным не пытаться сделать одну огромную сущность вроде:

«Иванов + КамАЗ + прицеп + сварочный аппарат + объект №17».

Мы пошли другим путём:

• Сотрудник — отдельная заявка

• Автомобиль — отдельная

• Оборудование — отдельное

А объединяются они уже внутри одного комплексного запроса.

С моей точки зрения, такая модель в итоге оказалась значительно проще для сопровождения.

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

Матрица требований вместо условий в коде

Следующая проблема — требования заказчиков постоянно отличаются.

Одному для водителя нужен определённый набор документов. Другому — другой. Для инженерно-технического сотрудника набор уже третий.

Для самосвала требования отличаются от требований к легковому автомобилю.

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

По сути, одна запись требования отвечает на вопрос: для этого заказчика, этого типа пропуска и этого типа субъекта требуется вот этот тип документа.

Для сотрудников и транспорта администратор видит обычную двумерную сетку:

тип документа × тип сотрудника или транспорта.

Поставил отметку — требование есть.

Убрал — требования нет.

Для оборудования используется список документов по заказчику.

Технически при сохранении это обычный «обновить или создать» либо удаление соответствующей ячейки.

Но с точки зрения бизнеса получилось важное свойство:

изменение требований заказчика не требует выпуска новой версии программы.

Меняется матрица. И следующая заявка уже проверяется по новым правилам.

Откуда заявка понимает, какие документы ей нужны

У заявки на пропуск есть метод запрос_требуемых_документов().

Каждый раз при проверке заявки он обращается к текущей матрице требований.

Учитывается:

• заказчик

• тип пропуска

• тип сотрудника либо группа транспорта

• требуемые типы документов

Объект при этом задаёт контекст самой заявки и связан с заказчиком.

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

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

Но в нашем случае этого не потребовалось.

Почему мы не сохраняем комплект требований один раз при создании заявки

Тут есть ещё один важный архитектурный момент.

Матрица требований — живая.

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

Администратор добавляет соответствующую ячейку в матрицу.

Следующий вызов запрос_требуемых_документов() уже увидит новое требование.

Не нужно мигрировать заявки или менять код.

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

То есть у нас получились два разных уровня:

• текущие правила — живут в требованиях

• что реально отправили при конкретном оформлении — сохраняется отдельным снимком в пакетах документов запроса

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

Как проверяются документы

После согласования заявки запускается проверка_документов().

Для каждого требуемого типа система ищет актуальный документ.

Проверяется как минимум две вещи:

• документ вообще существует?

• срок действия не меньше текущей даты и документ имеет статус актуален?

Если нужного файла нет или срок действия закончился, система не просто показывает пользователю красную строку. Она создаёт задачу тому подразделению, которое отвечает за данный тип документа. У типа документа для этого указано подразделение.

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

Это кажется мелочью, но именно здесь информационная система начинает отличаться от обычной базы данных.

База сообщает: «документа нет».

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

Снятие признака валидности с уже существующего документа работает аналогично: «отметить как не корректный» снова создаёт задачу на актуализацию.

У срока действия оказалось сразу три уровня

Ещё одна вещь, которая сначала кажется простой: даты.

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

Первый — сами документы

У документа есть срок действия и признак проверен.

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

Второй — заявка и пропуск

У запроса на пропуск и пропуска собственные сроки выдачи и сроки действия.

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

Иначе очень быстро появляются несколько одновременно существующих «истин» относительно того, какой именно пропуск действует.

Третий — фоновое состояние

Есть периодическая задача обновления истекших пропусков.

Если у пропуска статус выдан, но срок действия уже прошёл, он автоматически переводится в «истёк».

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

То есть система сама приводит состояние процесса в соответствие с течением времени.

Для пропусков это принципиально. Сегодня документ действителен — завтра уже нет. Сегодня сотрудник работает в компании — завтра уволен. Сегодня пропуск существует — через неделю истёк.

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

Что именно отправляется заказчику

Есть ещё одна проблема.

Допустим, заявка проверена сегодня. Через месяц один из документов сотрудника обновили.

Как потом понять, какой именно комплект был фактически отправлен заказчику при оформлении пропуска?

Поэтому непосредственно перед отправкой создаётся снимок пакета документов по заявке.

Туда попадают только документы, которые на этот момент:

• указаны как проверенные и актуальные

• соответствуют требованиям заявки

• подходят по дополнительным признакам, включая указание организации

Из этого набора формируется пакет, в том числе ZIP для передачи заказчику.

Таким образом, живой документ сотрудника и документ, отправленный в конкретной заявке, — это не одно и то же.

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

А что произойдёт, если заказчик завтра изменит правила?

Это был один из важных практических вопросов.

Допустим, заказчик сообщает, — «С понедельника для всех водителей требуется ещё один документ.»

В нашей модели программист для этого вообще не нужен. Ответственный сотрудник меняет матрицу требований.

После этого:

• новые заявки сразу начинают требовать новый документ

• повторная проверка существующей заявки идёт уже по новой матрице

• если документа нет, появляется задача ответственному подразделению

• новые комплекты формируются уже с учётом изменившегося правила

При этом уже выданные пропуска не изменяются. И ранее сохранённые пакеты документов по заявке тоже остаются такими, какими были в момент оформления. То есть исторические данные не «переписываются» вслед за текущими правилами. В этом есть определённый компромисс.

Сама матрица требований у нас не версионируется как отдельный исторический снимок.

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

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

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

Процесс — это не только данные, но и роли

Отдельно пришлось описать, кто на каком этапе имеет право что делать.

Упрощённо маршрут выглядит так:

Комплексный запрос проходит статусы:

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

За проверку отвечает члены отдельной группы безопасности.

За согласование – тоже отдельная группа.

После согласования отдел пропусков выполняет фактическое оформление и фиксирует в системе выданный пропуск: номер, сроки действия, площадку и дополнительные признаки.

Например, признак транзита используется для транзитного пропуска, когда объект нужно только пересечь по пути к другой площадке.

Telegram мы оставили, но перестали хранить в нём процесс

До автоматизации значительная часть общения происходила в мессенджерах.

Попытка сказать 2000 сотрудникам:

«С завтрашнего дня Telegram больше не используем»

закончилась бы предсказуемо.

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

Уведомления о задачах и событиях продолжают приходить в Telegram.

Но сам бизнес-процесс находится не там:

• Заявка

• Статус

• Ответственный

• Документы

• История согласований

• Комментарии

• Результат

Всё это хранится внутри системы.

Мне кажется, это довольно важный принцип корпоративной автоматизации.

Не обязательно бороться с удобным интерфейсом коммуникации.

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

Начали мы, кстати, вообще не с пропусков

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

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

А дальше с ними происходило примерно всё что угодно.

Кто-то записал себе. Кто-то запомнил. Кому-то отправили сообщение.

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

Поэтому первым делом автоматизировали задачи и совещания:

• Повестка

• Решения

• Поручения

• Ответственный

• Срок

• Статус

Только после этого начали переходить к более специфическим производственным процессам.

С моей точки зрения, это оказалось правильным решением.

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

Самая частая фраза проекта: «А у нас ещё бывает вот так»

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

Причём вопрос, — «Расскажите, как вы работаете», обычно помогает не очень.

Сотрудник рассказывает стандартный сценарий. Мы его описываем. Согласовываем. Автоматизируем. Запускаем. Проходит неделя.

Приходит руководитель подразделения:

— Всё хорошо. Но у нас ещё бывает вот так.

— А почему раньше не сказали?

— Ну это редко бывает.

И выясняется, что «редко» означает три раза в месяц и без этого сценария процесс нельзя считать автоматизированным.

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

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

И только после этого становится понятно, насколько правильно вы описали процесс.

Что в итоге сделали

В качестве базовой платформы для проекта использовали АСК «Легарус», а специфические процессы транспортно-строительной компании реализовали в виде дополнительных модулей.

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

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

Система развёрнута в частном облаке заказчика. Есть интеграции с 1С, электронной почтой и Telegram. 

Что изменилось после внедрения

Сегодня через систему контролируется более 17 000 документов по примерно 2000 сотрудникам и 450 единицам техники.

До автоматизации пропускным режимом занимались 4–6 сотрудников.

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

Штрафы, связанные с проблемами оформления пропусков и разрешительной документации, до внедрения компания оценивала примерно в 1,5–2 млн рублей в год.

После внедрения: примерно в 0–0,5 млн.

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

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

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

За год мы автоматизировали примерно четверть процессов. И это нормально

С заказчиком мы работали около года.

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

Это именно наша экспертная оценка, формального реестра со 100% процессов компании мы не составляли.

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

Мы двигались иначе:

• Нашли процесс, в котором есть проблема

• Описали

• Поняли экономику

• Автоматизировали

• Посмотрели на реальную эксплуатацию

• Исправили исключения

• Перешли к следующему

 Здесь, наверное, стоит ещё раз оговориться. В статье я показываю реализацию на АСК «Легарус», потому что именно эту систему мы разрабатываем и именно на ней выполнялся проект. Но перечисленные выше проблемы — матрицы требований, сроки действия документов, необходимость сохранять исторический комплект, меняющиеся правила заказчиков и исключения из бизнес-процессов — не являются особенностями конкретного программного продукта.

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

Что я вынес из этого проекта

Первое.

Не нужно автоматизировать процесс, который вы ещё не поняли.

Программирование хаоса даёт автоматизированный хаос.

Второе.

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

В нашем случае матрица Requirement позволила отделить правила заказчиков от логики самой системы.

Третье.

Текущие правила и исторический факт — разные вещи.

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

Для этого и появился пакет документов по заявке.

Четвёртое.

Срок действия — это часть состояния системы, а не просто поле с датой.

Если документ или пропуск истёк, система должна сама перестать считать его действующим.

Пятое.

Почти всегда существует сценарий «а ещё бывает вот так».

Поэтому первая версия автоматизированного процесса практически никогда не является последней.

Шестое.

Информационная система должна не только обнаружить ошибку, но и запустить действие по её исправлению.

Недостаточно показать:

Нет медицинского документа.

Нужно понять, кто за него отвечает, и автоматически поставить этому человеку или подразделению задачу.

И последнее.

Считать нужно не количество написанных функций.

В нашем случае гораздо важнее не то, сколько моделей, экранов и фоновых задач мы реализовали.

Важно, что вместо 4–6 сотрудников с процессом сейчас справляются двое, количество ошибок существенно снизилось, а одна просроченная справка больше не должна обнаруживаться после того, как автопоезд проехал 700 километров.

Собственно, с моей точки зрения, именно это и есть нормальная автоматизация.