Процессная эффективность, Автоматизация | Олег Брагинский, Максим Мухтаров
Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают о том, как эффективно выстроить процесс автоматизации обновления корпоративной отчётности в многопрофильных отечественных медицинских учреждениях.
В крупной сети медицинских учреждений стартовал проект по внедрению BI-системы. После первых успехов и принятия в эксплуатацию, кратный рост запросов со стороны бизнес-подразделений и расширение команды технических специалистов вынудили задуматься о регламентации доработок.
Предстояло определить понятия и ввести классификации, обозначить зоны ответственности и выделить обобщённые роли, зафиксировать этапы и прописать обязанности, подготовить инфраструктуру и разграничить доступ. Приступили к исполнению замысла по порядку.
BI-продукт определили как потребность в полезной информации нужной формы для обработки специалистом. Выкристаллизовали функцию приложения: вбирать данные из различных источников, не служа интеграционным хабом. ИТ-шники учли в планах развития архитектуры.
Важным критерием посчитали тип запроса: а) ручной – информация необходима однократно и в ближайшие день-два; б) автоматический – числа смотрят периодически (ежедневно, еженедельно, ежемесячно, ежеквартально), полную или частичную реализацию можно распределить в спринт.
Узнав о возможностях нового подразделения доставать данные гибко, заказчики стали заваливать требованиями на выгрузки, чтобы не ждать разработчиков отчётных модулей исходных систем. Быстро поняли: будем ориентировать коллег на всеобъемлющее покрытие процессов отчётностью.
Постепенно остались ad hoc-запросы, которые принимали как допустимые: характеризовались сложной логикой вычислений, практически невозможной к воспроизведению при работе с предоставляемыми видами автоматических BI-продуктов для самостоятельной аналитики.
Автоматический продукт разделили по виду интерфейса: а) элемент сервера отчётов Power BI – дэшборд или постраничный отчёт SQL Server Reporting Services с выгрузкой в Excel; б) OLAP-куб SQL Server Analysis Services; в) представление над таблицей в хранилище витрин.
Визуализации в браузере вывели рядовым пользователям. Большинство предпочитало дэшборды с фиксированным отображением показателей верхнего уровня. SSRS-отчёты носили подчинённый характер: раскрывали агрегаты в детали для сверки с источниками, повышая доверие к числам.
OLAP-кубы корневых бизнес-процессов создавали для любителей drill-down и мастеров Excel. Потенциал сводных таблиц уменьшал потребность в выгрузках и прототипировал дэшборды, на разработку которых потом создавались задачи, чтобы числа были доступны всем через браузер.
Представления готовили для продвинутых пользователей, но по локальным процессам или частным расширениям основных: списание материалов на госпитализации, дебиторская задолженность физических лиц при оказании услуг, управленческий отчёт о прибылях и убытках.
Описав элемент поставки, перешли к проектированию процесса. Разнообразие BI-продуктов не пугало: этапы и участники едины. В зависимости от типа запроса и вида интерфейса менялись наполнение работ и скорость прохождения карточки с задачей по виртуальному конвейеру.
Выделили четыре роли с концептуальной функцией:
- Заказчик – формулирует потребность в данных и пользуется ими.
- Верификатор – разрабатывает методику и проверяет расчёты.
- Эксперт по информационной системе – знает базу источника.
- Аналитик – создаёт BI-продукт:
Конечные заказчики образовывались из категории простых пользователей, внедряющих просмотр отчётности в свою ежедневную практику. К ним относился многоуровневый руководящий состав структурных подразделений клиник и менеджмент различных звеньев управляющей компании.
Верификаторами выступали аналитики функциональных направлений. Финансы, операционная эффективность, продажи, медицина, безопасность, HR, закупки, IT, аудит выделяли сотрудников, разбирающихся в бизнес-процессах из зоны ответственности и тонкостях расчётов KPI.
Экспертами по системам-источникам стали штатные сотрудники отделов технической поддержки и представители вендора: отправляли документацию, делились скриптами из отчётных модулей, подсказывали механики отражения в базе данных информации из графического интерфейса.
Аналитики управления по работе с данными сочетали компетенции визуализаторов, разработчиков хранилища, инженеров трансформаций: компактная команда не требовала горизонтального разделения труда. Сотрудников закрепляли за функциональными подразделениями заказчиков.
Наиболее технически подкованные и желающие развиваться из среды верификаторов получали расширенные права и самостоятельно выступали в роли аналитиков, разрабатывая дэшборды и витрины в предписанных базах, что органично встраивалось в общую архитектуру BI-системы.
Способствуя ускорению поставки отчётности и упрочнению культуры самореализации в компании, BI-разработчики основного подразделения готовили место в инфраструктуре для внешних коллег, ставили расчёты в расписание, консультировали по вопросам оптимизации SQL-запросов.
Предусмотрели этапы фиксации состояния BI-продукта:
- Идея – оформлена потребность в данных и представлении.
- Согласование технического задания – утверждён прототип.
- Разработка – выложен на проверку.
- Тестирование – верифицирован.
- Релиз – открыт на просмотр.
На первом этапе заказчик описывает KPI и способ мониторинга. Верификатор задаёт уточняющие вопросы и рассказывает о готовых BI-продуктах, покрывающих интересующие процессы. Аналитик сообщает принципиальную возможность разработать необходимое и альтернативные реализации.
На следующем шаге верификатор фиксирует разрезы и показатели, описывает алгоритм расчётов, ищет исходные данные в отчётном модуле соответствующей системы или на экранах, определяет интерфейс BI-продукта, моделирует визуализации в Excel, формирует справочники атрибутов.
Аналитик обсуждает ТЗ с верификатором, исследует источник, декомпозирует задачу в трекинговом приложении согласно типу BI-продукта. Эксперт по информационной системе отвечает на вопросы по модели данных, способу подключения, графическому интерфейсу, документации.
Далее задачу с финализированным ТЗ аналитик распределяет по спринтам. Когда подходит время, приступает к разработке: загружает справочную информацию, проектирует витрины в хранилище, организует поток данных, создаёт визуализации, выкладывает продукт в тестовый контур.
Затем верификатор акцептует продукт: сверяет вид с прототипом, убеждается в работоспособности интерактивных элементов, за выбранный период сравнивает числа с источником, устанавливает адекватность сопоставлений в справочниках и наполненность дополнительных атрибутов.
Аналитик устраняет выявленные в результате тестирования недочёты. Существенное изменение требований от верификатора после модельного использования вынуждает возвращаться на этап согласования технического задания и планировать доработки в предстоящий спринт.
Верифицированный продукт аналитик выкладывает в промышленный контур, доступный конечным заказчикам, и настраивает расписание обновления. Разработка сменяется поддержкой: реагированием на оповещения, плановым мониторингом, обработкой заявок в службе одного окна.
Неоднократно убеждались: ключ к успеху лежит в неукоснительном соблюдении обязанностей каждой ролью – все знают «что для кого», «откуда», «как», «когда» и «в каком виде» считаем, а правильно оформленное ТЗ одновременно служит и документацией, помещаемой в базу знаний.