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

Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 2011 и 2012 году они показывали высокую прибыль, при которой можно забыть об оптимизации и просто фигачить как можно быстрее дальше, пока получается. «Что тут думать, трясти надо» — оптимальная бизнес-стратегия на таких нормах прибыли. В 2013-м году из-за общей экономической ситуации стало понятно, что прибыль будет снижаться. Соответственно, первое, что начало делать большое руководство — это разбираться, куда и как конкретно тратятся деньги, чтобы найти то, что можно безболезненно оптимизировать или просто убрать.

Что я делаю

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

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

Руководство холдинга решило разобраться, куда идут деньги…

Здесь их ждал сюрприз в системе документооборота. Говоря строгим научным языком, она напоминала спонтанное перекрёстное опыление. Ну, или p2p-сеть. Представьте, что вы — сотрудник одной из компаний холдинга. Вам нужно согласовать и подписать договор. Процедура предусматривает множество решений, из которых главные — это определение ваших лимитов, возможности подписывать договор в рамках полномочий, производственной необходимости, плюс согласование с десятком человек от финдиректора до юриста и руководителей технических подразделений в зависимости от того, что за документ. Переводя на русский — есть квест на 20 подзадач, который каждый раз меняется в зависимости от договора. Самое весёлое — никто точно не знает, как этот документ надо обрабатывать, и все подзадачи нашего квеста рисуются по дороге. Руководитель подразделения, отвечающего за реализацию технической части, например, может отправить вас ещё к трём людям, которые поставляют ему сырьё для производства — а каждый из них ещё и к своим юристам и финансистам.

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

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

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

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

И принимается решение о введении тотального контроля на всех точках принятия решений.

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

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

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

Когда коллеги произнесли фразу «постоянство изменений», на сцене появилась моя команда. Постоянство изменений — это именно то, с чем лучше всего справляется BRMS.

Зачем нужен BRMS в этом случае

BRMS — это репозиторий бизнес-правил. Например, если вы страховая компания, и к вам приходит клиент, заполняет анкету, плюс вы собираете кучу данных про него, нужно понять, сколько будет стоить страховка. Фиксированная система (в той или иной степени ERP, CRM, BPM) позволяет в таком случае легко и просто просчитать это автоматизированно. Проблем нет. Сложности начинаются тогда, когда маркетинг решает поменять тарифы. Задач там две:

1. На каждый чих нужно ходить в IT-отдел и просить внести изменения в логику обработки.
2. Не всегда можно заранее предположить, что получится — правила расчёта могут взаимоисключать друг друга, выпадать из расчёта из-за ошибок, смещение одного из коэффициентов на 0,5% может вызвать резкий скачок прибыли вниз — всё это надо знать заранее.

И вот тут появляется BRMS-система. Это место, где собираются все правила компании и накладываются на остальные системы. В случае страховой компании — BRMS знает кому, что и как считать. Для телекома — позволяет строить прогнозы прибыли по текущим абонентам с известными профилями в случае изменения тарифов. Для банка — точно знать, кому выдавать кредит и при каких условиях, а кому — нет. Что очень важно — управляется она не IT-отделом, а теми, кто принимает решения. То есть непосредственно финансистами, маркетингом и так далее.

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

До BRMS это означало бы обязательный поход в IT-отдел за новой фичей. Вот простой случай: новый тариф телекома. Делов-то — дойти до IT-отдела и попросить поменять коэффициенты. Но нет, нужно ещё сохранить старый тариф для совместимости. А у него там ещё пять костылей для совместимости с другими костылями. Если делать с гарантией надёжности (без ошибок в бизнес-логике и технической части), процесс начинает напоминать археологическую экспедицию. Если делать быстро — нет гарантии, что всем будет считаться правильно.

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

Пример работы BRMS

Что мы сделали

В итоге мы развернули BRMS в достаточно необычном виде — как архитектурный элемент системы электронного документооборота. Решилось две очень важных задачи: расчёт маршрута договора и установление лимитов.

С маршрутом история такая. Обычный электронный документооборот чисто архитектурно считает маршрут один раз в начале, а дальше его контролирует. Можно внести 2-3-5-10 узлов по дороге для точек пересчёта, но количество этих узлов должно определяться на архитектурном уровне или около него. В нашем же случае каждый узел согласования становился точкой пересчёта маршрута договора: «А здесь неправильно согласовали, нужно с другим списком подписывающих». По логике — бумагу надо пульнуть в начало цепочки и начать снова, но тогда бизнес потеряет ещё по крайней мере пару недель.

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

Второй момент — это сложная система доверенностей, лимитов по бюджету и срокам и так далее. Здесь было важно по огромному своду правил (тем самым матрицам на А3) проверять, всё ли в порядке с документом, можно ли его тащить дальше и так далее. Заносить всё это в документооборот — обрекать систему на своего рода фрактал из костылей через 3-4 года. Тоже вынесли в BRMS.

С этого момента всё пошло как-то легче. Когда у руководителя есть полный контроль над своей частью системы — это счастье. А его более старший руководитель, в свою очередь, может просмотреть, что и как было точно со всеми документами. Получается такой прозрачный отчёт.

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

Страховая

Второй примечательный случай BRMS был в страховой. Они давали своим офисам огромный XLS-файл, где была куча связанных ячеек и макросов, собранные по клиентам данные. Дальше всё это считалось и давало результат. Нормальное решение для малого бизнеса, в целом, здравое — для среднего, но компания успела вырасти до уровня большого. Очень большого.

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

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

Обновлялось всё это отправкой документа в подразделения (каждый офис) по почте или FTP.

В общем, это был классический случай внедрения BRMS, когда клиент больше не мог терпеть такие процессы, и хотел разгрузить IT-отдел. Получилось, благо с типизацией данных проблем не было: всё было готово, рассортировано и проверено. Просто нужен был современный инструмент. Всегда бы так.

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

У нас

У нас в КРОКе примерно две с половиной тысячи проектов в год (из них более 200 с бюджетом более 1 миллиона долларов), 2500 сотрудников.

Мы всегда внедряем у себя всё наиболее современное, BRMS-система не была исключением, но была реально очень нужна. Главный вопрос был финансовый — нужно было считать себестоимость и рентабельность проектов и делать what-if анализ.

Раньше стоимость крупных комплексных проектов считалась руками. Например, для того, чтобы просчитать себестоимость трудозатрат на проект нужно было учесть около 14 параметров (такие как должность, департамент, ставка вовлеченных сотрудников и пр.) Теперь это делается буквально за пару минут, плюс можно считать себестоимости более четко и детально. Так как все делается теперь в системе, то мы усложнили формулы, учли больше параметров – теперь их порядка 170. В ведении наших финансистов появилась своего рода матрица управления, они могут распределять налоги и накладные расходы по комплексным проектам, управлять коэффициентами, и даже влиять на продажи. Например, они могут легко узнать, что будет с финансовыми показателями, если вдруг ставки сотрудников повысятся на 10%, или налог изменится, или поменяется что-то ещё. Счастье как оно есть.

Пример расчета трудозатрат на проекте

Для директоров по продажам это тоже вылилось в удобный инструмент – финансовый калькулятор проектов. Благодаря репозиторию правил они могут самостоятельно – «без участия финансистов» — рассчитать стоимость проекта в зависимости от его параметров, таких как количество и должности вовлеченных сотрудников, объем человеко-часов, направления работ, и пр.

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

Слияния и поглощения

BRMS часто используются в Европе и США при слияниях и поглощениях компаний. Например, был один банк, который что-то поглотил и стал, фактически, двумя структурами под одной вывеской. «А в этом отделении мы не можем так сделать, перейдите через дорогу в другое». Разный персонал, разные правила, разные АБС. Если нет плана переходить на одну платформу (а это своего рода утончённый вид суицида), есть только один логичный выход. Всё это относительно безболезненно (насколько это вообще можно при слиянии-поглощении) соединяется через BRMS-системы.

Ещё раз

BRMS:

• Быстрое изменение правил (т.е. можно оперативно внести изменения в работу бизнеса)
• Мгновенный пересчет и моделирование комплекса бизнес-правил
• Сохранение всей истории создания алгоритмов бизнес-правил
• Использование всегда единой версии правил для всех систем
• Контроль обязательного соблюдения правил
• Высокая производительность вычисления: тысячи правил в секунду
• Анализ «What If» (Что, если…)
• Всё это — без похода в IT-отдел. А в сочетании с интеграционной платформой – доступ к правилам из любого процесса и приложения.

А вот предыдущий пост про BRMS на примере первых докомпьютерных систем автоматизации при царе.

Если есть вопросы, неспешно отвечу в комментариях или, на особо конкретные, по почте splaunov@croc.ru. Единственное — все данные будут от абстрактных компаний, мне по NDA даже скриншот результата показать нельзя без того, чтобы не вычистить из него все числа и буквы.

Автор:

Источник