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

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

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

В статье я расскажу про своё решение, что меня вдохновило на его создание, как оно решило проблему и как оно может применяться в других проектах. Вы можете взять его за основу, если нужно создать «паспорт/профиль организации и риски, с ней связанные». Такой подход поможет разрешить конфликт интересов: исполнитель — руководитель исполнителя — главный руководитель. Ситуация станет понятной, прозрачной и управляемой для каждого участника процесса.

В статье вы узнаете:

• Про дерево. Как анализировать данные с помощью дерева данных.

• Про риск-мониторинг. Как наложить слой риск-мониторинга на дерево и увидеть масштаб пожара.

• Про управление рисками. Как управлять рисками и тушить пожар с помощью проверок.

• Про проекты. Как применить данный подход в своих проектах.

Предыстория

Контролирующий орган Х проверяет закупочную деятельность бюджетных организаций в городе N. У одной организации может быть более 10 тысяч контрактов в год. Срок плановой проверки — 1 месяц.

Инспектор проводит проверку:

• Закупка проведена в соответствии с правилами процедуры?

• Контракт исполняется надлежащим образом или есть нарушения?

• То, что было заявлено, доставлено или есть нарушения?

Если обнаружили нарушение, то выписывают предписание его устранить и штраф.

У группы инспекторов есть руководитель. Над ними стоит высшее руководство.

Модель AS IS. Проверка проводилась вне ИС. В систему загружался только результат — акт и предписание по итогам проверки. Далее документы опубличивались (см. Реестр плановых проверок в ЕИС). Процесс был не прозрачен и не управляем для высшего руководства. Результаты проверок его не устраивали — штрафов было мало. 

Для анализа ситуации важную роль сыграл тот факт, что за 12-летний опыт работы в ИТ я погрузилась в надзорную деятельность с разных сторон: 

• была заказчиком со стороны государства в «Росаккредагентстве»;

• была инспектором по проверке исполнения контрактов со стороны госзаказчика в «Информэкспертизе»;

• была исполнителем по разработке ИС для госоргана в роли руководителя проектов в «Мосгосстройнадзоре».

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

Проблемы

В процессе анализа ситуации выявилось несколько проблем.

Основная проблема — конфликт интересов:

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

Из этого вытекали другие проблемы:

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

• Ограниченность ресурсов. Инспекторы успевали проверить десятки контрактов, а надо тысячи.

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

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

Сложный заказчик: 1,5 года — среднее время согласования одной доработки ИС. Согласовать часто не получалось, так как решение не нравилось как минимум одной из сторон.

Модель AS IS, или как до этого работали

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

Было много неэффективного ручного труда при дефиците кадров. Процесс сбора данных занимал 80% времени, и на анализ контрактов практически не оставалось ресурсов. 

Решение

Чтобы решить выявленные проблемы, нужно было сделать пять шагов.

Шаг 1

Провести анализ и сделать кликабельный макет в AXURE.
Это помогло сразу выявить множество подводных камней. 

Шаг 2

Перевести процесс сбора данных для проверки в ИС:

После пробной выгрузки данных для макета выяснилось, что контрактов очень много. Не 100, а 14,5 тысяч в одной организации. Разница более, чем в 10 раз. Это был неожиданный результат для руководства Заказчика:

Шаг 3

Наложить на данные риск-мониторинг:

Шаг 4

1. Упростить восприятие большого массива данных для всех участников процесса.

2. Помочь определить наиболее важные контракты для проверки.

Потому что в табличном виде данные использовать тяжело:

• более 10 тысяч строк — контракты;

• более 50 колонок — описание и риск-мониторинг.

Шаг 5

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

В поисках идеального решения я просмотрела десятки диаграмм. После двух месяцев мук творчества пришла идея соединить несколько решений:

• 3D Tree;

• фрактальное дерево на Python;

• слой «Пробки» из «Яндекс.Карты».

Вот что получилось:

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

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

Остановлюсь подробнее на визуализации.

Инфографика

Для упрощения восприятия информации было внедрено два вида инфографики:

1. квадраты (клевер) — предложил Заказчик;

2. граф (дерево) — моя инициатива, которую поддержало моё руководство и затем Заказчик.

Квадраты (клевер) — общая картина, по которой видно, сколько контрактов выбрано в проверку относительно общего объема закупочной деятельности: в штуках и в рублях. Так заказчик в лице высшего руководства хотел видеть, какой же процент контрактов охватывается проверками:

Граф — дерево, где каждая веточка — это контракт. По дереву виден масштаб закупочной деятельности и, что особо важно, можно перейти к конкретному контракту:

Диаграммы удачно дополняют друг друга и дают объёмное понимание ситуации: 

Как работает дерево данных

Полноценное большое дерево выглядит так:

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

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

В дереве можно настроить 15+ фильтров:

По фильтрам можно проводить многомерный анализ данных:

Далее на дерево накладывается слой риск-мониторинга. По идее он похож на «Яндекс.Пробки». Когда контракты попадают в проверку, то веточки начинают гореть.

Если горит много веточек — это пожар. Вся закупочная деятельность организации в огне:

Далее добавляется ещё один слой — управление рисками — это то, как тушится пожар. В данном проекте это были проверки.

Перед проверкой у инспектора есть данные:

1. общий объём контрактов (базовое дерево);

2. пожар риск-мониторинга — какие из контрактов обладают признаками нарушений, какое количество;

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

Далее инспектор начинает включать в проверку контракты по тем или иным признакам. Такие контракты отмечаются синим цветом:

При добавлении в проверку контракта система автоматически фиксирует, на каком шаге он был добавлен (см. колонку «Шаг включения»). 

Пользователь может вручную добавить комментарий, почему именно был выбран данный контракт (см. колонку «Комментарий»). 

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

Система автоматически фиксирует, на каком шаге был добавлен контракт в проверку:

Далее у каждого участника процесса есть возможность добавить комментарий, почему именно важно включение данного контракта в проверку (см. колонку «Комментарий»).

Кейс: высшее руководство в любой момент могло само зайти в проверку, поменять состав контрактов и оставить комментарий, например, «Решение мэра»:

В итоге выиграли все три стороны:

Где можно применять дерево данных

Дерево данных принесёт пользу в проектах, где важно видеть картину в целом, «паспорт/профиль организации и риски, с ней связанные».

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

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

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

Вывод

Сделать дерево очень просто. Открытый код: 3D Tree. Далее код нужно немного кастомизировать и доработать под ваши задачи. 

При этом внедрение дерева принесёт много пользы:

• облегчит восприятие информации;

• подсветит проблемы;

• повысит прозрачность и управляемость процесса.