company_banner

Процесс постоянных изменений в компании — как это автоматизируется

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

    Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 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 даже скриншот результата показать нельзя без того, чтобы не вычистить из него все числа и буквы.
    КРОК
    IT-компания

    Comments 15

      +3
      Очень интересно, спасибо. А что за название у этой BRMS? Сам занимаюсь CRM, но с интересом бы ознакомился с этой системой.
        +2
        По проектам — не имею права говорить, что и где внедрялось. Но советую посмотреть, например, в сторону Oracle BRMS, Progress Corticon, FICO Blaze Advizor, Red Hat Jboss BRMS, IBM ODM.
          0
          По проектам даже и не пытался узнать. За список благодарю, посмотрю на досуге кто есть кто.
            0
            К вашему списку я бы еще добавил Pegasystems. Эта платформа также позволяет реализовать системы принятия решений на основе бизнес-правил.
              –1
              Вы, наверное, имели в виду Oracle BPM (Oracle Business Process Management Suite)?
            0
            Приведенные скриншоты сняты с IBM ODM. Соглашусь, что это хорошая BR-система, но нельзя сказать, что самая лучшая.
            Если вы занимались CRM системами, то вам стоит обратить внимание не только на BRMS, но и на BPMS (Business Process Management System). Посмотрите, например, отчет Gartner BPM Magic Quadrant за 2014 год (можно скачать с сайта IBM, оставив им контактные данные, есть отдельно сравнительная диаграмма из статьи или можно еще погуглить)
            Даже если просто взять за основу их сравнительную диаграмму и посмотреть информацию по тройке лидеров (Pegasystems, Appian, IBM BPM), то уже можно составить базовое представление об области.
            +1
            Наверное, это все круто, управление бизнес-процессами, управление правилами и прочие всякие ERP управляемые прямоугольничками.

            Интересно вот, насколько этим всем кто-то может правильно пользоваться, ведь как мы знаем SQL — тоже создавался для пользователей не-программистов.
              0
              Лет так тридцать (или сорок назад) было мнение, что в будущем системы управления будут писать на Prolog. Насколько современные системы BRMS приблизились к Prolog логике?
                +1
                Не могу сказать, что современные BRMS и BPMS движутся в сторону Prolog-а, это было бы некорректным утверждением.
                Но если говорить о декларативных вычислениях в целом, то в IBM пока такой возможности нет, там все еще доминирует процедурный образ мышления (нынче модно это называть SOA-архитектурой).
                Насколько я знаю, в Appian также нет такой возможности, но с этим продуктом я близко не знаком, так что могу ошибаться.
                Зато такая возможность есть и активно используется в Pega: там несколько различных типов декларативных правил, самым простым из них является declare expression, задающий формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком Pega (PRPC) одним из двух вариантов:
                1. Пересчитывать результат при каждом изменении любой переменной, входящей в формулу;
                2. Пересчитывать результат при каждом чтении значения рассчитываемой переменной.

                При этом, декларативные правила используются именно как дополнение к основному процессу. Это инструмент, который можно применять там, где он эффективен.
                0
                Вы правы, на нашем рынке пока очень мало людей, которые действительно знают, как применять BPM-системы. Но опыт американского и европейского рынков подсказывает, что мы тоже к этому придем.
                На мой взгляд, из собственного опыта, залог успеха кроется в нескольких простых пунктах, практически независимых от выбранной платформы:
                • Знать свою платформу: очень часто в реальных проектах на платформах реализуется то, что итак есть, но чуть-чуть по-другому (другой пользовательский портал, своя система уведомлений и т.п.).
                • Еще раз — знать свою платформу: не менее часто в реальных проектах на таких платформах пытаются реализовать что-то, для чего они не предназначены (как правило — всякие учетные системы).
                • Ставить бизнес-цели: если проект делается для того, чтобы «потратить бюджет», то вряд ли он будет успешным, какая бы хорошая платформа ни была выбрана. В противовес этому, если проект делается с пониманием, что его внедрение позволит компании сэкономить 5-10 миллионов рублей ежемесячно, тогда у людей появляется стимул принимать нужные решения.
                • Вовлекать бизнес-пользователей в процесс разработки: еще одна частая проблема в том, что в больших проектах расстояние от бизнес-заказчика до программиста измеряется парой десятков руководителей, аналитиков с обеих сторон, архитекторов, прочих сочувствующих и мегабайтами документов. В результате делается не то, что нужно.
                  +1
                  Даже нечего добавить к вашему комментарию. То, что вы написали — залог эффективной работы с системой. Если этого не будет — пусть она будеть хоть трижды гениальной — толку никакого от внедрения.
                +1
                Ух, как хочется поучаствовать в разработке и внедрении такой системы. CRM/ERP уже приходилось, а это, судя по описанию что-то мнего интереснее.
                  0
                  Расшифруйте, пожалуйста, в тексте статьи аббревиатуру BRMS
                    0
                    Business Rules Management System

                  Only users with full accounts can post comments. Log in, please.