Что такое BPMS

    Логотип BPMSСегодня в отечественном бизнесе набирает популярность новый вид программного обеспечения для управления бизнес-процессами, а именно, BPMS-системы. И, естественно, их появление вызвало много вопросов. Зачем они нужны? Как они работают? В чем их принципиальное отличие от других вариантов автоматизации бизнеса?

    Когда я впервые столкнулся с BPMS, у меня также возникли все перечисленные выше вопросы. Я далеко не сразу понял, зачем нужен новый инструмент, почему нельзя реализовать все необходимые для успешной работы бизнес-процессы в уже имеющихся системах учета или CRM, и в чем принципиальное отличие BPMS от других вариантов автоматизации бизнес-процессов.

    В этой статье я хочу рассказать о том, что такое BPMS-системы, зачем они нужны и чем процессный подход отличается от традиционных методов работы. Я не буду говорить о технических аспектах BPMS (о моделировании и разработке бизнес-процессов), этому будет посвящена следующая статья. Сейчас я постараюсь раскрыть сущность и смысл BPMS максимально простым и понятным языком:

    Что такое BPMS?


    BPMS — еще одна аббревиатура из разряда ERP, CRM, которая не имеет четкого определения. Хотя определений достаточно много: и зарубежных, и российских. Кроме того, компании, которые выпускают собственные BPM-системы, также дают свои, особые определения, что вносит дополнительную путаницу. К тому же нередко BPMS объединяют с другими системами (например, BPMS+CRM, BPMS+ERP) и тогда разработчики дают определение BPM-системы, исходя уже из этого контекста.

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

    BPM (англ. Business Process Management, управление бизнес-процессами) — концепция процессного управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям, и полагающаяся на такие принципы, как понятность и видимость бизнес-процессов в организации за счёт моделирования бизнес-процессов с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность динамического перестроения моделей бизнес-процессов силами участников и средствами программных систем.

    Википедия.

    BPMS (англ. Business Process Management System) — это в первую очередь программное обеспечение для поддержки концепции BPM в компании. BPMS-системы нужны для того, чтобы реализовывать в программной среде концепцию BPM.

    BPMS рассматривает работу компании как набор процессов, а не как набор функций. Объектом BPM-системы является не работа отдела продаж или закупок, а процесс продажи, процесс поддержки клиентов, процесс управления снабжением и т.д. И уже исходя из этого понимания, строится работа по реинжинирингу бизнес-процессов в BPMS.
    BPM-cистема направлена, главным образом, на совершенствование работы компании, на более прибыльную деятельность предприятия путем оптимизации и контроля бизнес-процессов.

    Работа пользователей в BPMS и других системах


    Для лучшего понимания сути BPMS, нужно понять, как обыкновенные системы (ERP-системы, CRM) подходят к работе пользователей. Например, пользователю необходимо составить заказ клиента. Каковы его действия?

    Пользователь может заполнять документ произвольно, если не запрограммирована последовательность его работы:
    • Может сначала открыть форму заказа, подобрать товары, указать цены, потом определить клиента.
    • Может сначала создать клиента, потом — его заказ.

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

    BPM-система рассматривает пользователя как еще один кирпичик в системе. Человек должен четко знать, в каком процессе он работает и что он должен делать.

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


    Способы реализации бизнес-процессов


    BPMS — это один из способов реализации бизнес-процесса. Рассмотрим, какие способы представлены в реалиях российского бизнеса для понимания, зачем же нужна BPM-система.

    Выделим три подхода:

    1. “Бумажный” подход;
    2. Автоматизированный подход (с применением других систем);
    3. Процессный подход в системе BPMS.

    Для примера возьмем бизнес-процесс согласования счета на оплату, так как он достаточно простой и наглядный.
    В моей практике был такой случай: клиент мне оплатил полностью счет, хотя на тот момент должен были внести только часть оплаты в размере 50%. Почему это произошло?

    Потому что у них в компании не было процедуры согласования счета. Узнали мы с директором компании об этом совершенно случайно. Я узнал, что в их компании на этапе согласования счета происходят периодические сбои, а директор с удивлением обнаружил, что он оплатил не 50% счета, как планировал, а сразу 100%.

    Почему так случилось? Все просто. Сработал, так называемый, “испорченный телефон”. Специалист принес с бухгалтерию счет к оплате с фразой “Надо оплатить 50% от суммы”. Бухгалтер уточнила у руководителя, оплачивать этот счет или нет. Руководитель, будучи уверенным, что речь идет о 50% суммы, подтвердил оплату. А бухгалтер, в свою очередь, забыла о том, что вслух было сказано о половине суммы, и поняла руководителя так, что надо оплатить весь счет. Что и было сделано.

    На примере этой компании и этого бизнес-процесса мы и рассмотрим все три подхода.

    “Бумажный” (не автоматизированный) подход

    Как раньше происходило согласование счета в этой компании?

    • Сотрудник получает счет, передает его в бухгалтерию;
    • Бухгалтерия вписывает счет в платежную ведомость, согласовывает ее с руководителем;
    • Если руководитель одобряет и подписывает запрос, бухгалтерия оплачивает счет.

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

    Автоматизированный подход

    Как правило, компании стараются контролировать тот или иной бизнес-процесс в учетной системе, в которой они уже работают. Но это также неправильно. Рассмотрим, какие минусы есть при таком варианте.


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

    Как это выглядело:

    • В системе назначаются ответственные лица за согласование расходов;
    • На основании какого-либо документа (заказа поставщику, поступления товаров или другого документа) создается документ Заявка на расходование денежных средств в статусе Не согласовано;
    • Если ответственный согласовал заявку и поменял статус на Согласовано, то счет направлялся в бухгалтерию;
    • Если ставился статус Отклонено, значит, заявка уходила обратно к лицу, инициировавшему процесс.

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

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

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

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

    1. деньги (сколько мы должны выплатить);
    2. получатель (кому мы должны выплатить);
    3. назначение (за что выплачиваем).

    А, значит, заполняя лишнюю информацию, сотрудник теряет время, и процесс согласования затягивается.

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

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


    Итак, основные отличия ведения бизнес-процессов в BPMS от учетной системы:

    1. В BPMS важно именно то, что делается. Здесь важна не учетная информация, не отчетность, а необходимость быстро принять решение, чтобы бизнес-процесс продвинулся дальше. С учетной системой так не получится, здесь мы должны указывать, какие документы за счет каких создаются и т.п. — это неудобно. Здесь нет четкого контекста.
    2. Простота логики и разработки. Если мы ведем бизнес-процесс в учетной системе, то должны учитывать большое количество логических связей: как проводятся документы, транзакции, на что это влияет, какие дополнительные лицензии надо покупать и т.п. — хотя, казалось бы, ответственному за согласование лицу это не нужно. Но в учетной системе мы обязательно должны привязываться к объектам конфигурации либо дорабатывать их, что не очень правильно.


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

    Теперь перейдем к третьему подходу и рассмотрим, как же должен быть решен этот бизнес-процесс в системе BPMS.

    Процессный подход в BPMS

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

    В нашем примере их будет три:

    1. Создание заявки на согласование счета;
    2. Проверка заявки;
    3. Результат заявки:
      • если одобрено — распечатка заявки,
      • если не одобрено — сообщить об этом поставщику

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

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

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

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

    Если другие системы направлены на то, чтобы операция была выполнена, то в BPMS мы сконцентрированы на действиях.

    BPM-систему можно сравнить с японской техникой стрельбы из лука Юми. В школах стрельбы из юми проповедуют следующий подход: если вы хотите попасть, не нужно концентрироваться на цели, нужно делать правильно каждое действие сейчас. Т.е. здесь используется принцип, который применяют в уже упомянутой мною японской стрельбе из лука Юми: сосредоточьтесь на каждом действии, на каждом этапе, качественно выполняйте каждое действие. И тогда вы обязательно придете к цели!
    .
    И если перенести такой подход на конкретное предприятие, каждый из сотрудников должен делать то, что необходимо. И концентрироваться только на этом. Сотрудник не должен думать о цели, он должен делать только то, что необходимо в конкретный момент.

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

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

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

    • Разделение зон ответственности;
    • Концентрация работы сотрудников на конкретных действиях;
    • Оповещение пользователей об изменениях в процессах (или о необходимости внести изменения), в которых они участвуют.

    В BPM-системе мы описываем бизнес-процесс в нотации BPMN 2.0. В этой нотации уже есть многие моменты, подсказывающие, как нужно настраивать тот или иной бизнес-процесс. Есть другие различные системы автоматизации бизнес-процессов, но они опираются на свою логику, которая не является общепризнанной. Для того, чтобы смоделировать бизнес-процесс на основе таких систем, необходимо в этих системах разобраться, понять их логику работы, настройки форм и взаимосвязей.

    BPMN 2.0 — это общепризнанный стандарт описания бизнес-процесса и люди, знакомые с этой нотацией, сразу поймут модель бизнес-процесса, написанную в этом формате.

    Заключение


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

    Еще статьи по данной теме:



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

    Trinion
    60,00
    Внедрение систем ERP и CRM.
    Поделиться публикацией

    Похожие публикации

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

      +1
      Что такое BPMN 2.0 сказали, а вот из чего он состоит: www.bpmb.de/images/BPMN2_0_Poster_RU.pdf
      • НЛО прилетело и опубликовало эту надпись здесь
        –3
        bpm это следующее слово в эпохе документооборота workflow
        • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Мне кажется, некорректно делать вводное описание систем BPMS ясно не позиционировав их относительно других типов систем, где широко используется такие понятия как workflow или бизнес-процесс. В первую очередь от систем документооборота\ECM, ERP и всевозможных issue-tracker'ов.

          А то человек не в теме решит либо: «А у нас уже есть BPMS. СЭОДО 10 лет как внедрили», либо наоборот захочет проблемы подходящие, скажем для JIRA, решать через BPMS.
            0
            Очень интересная статья и очень правильный посыл — нужно ускорять принятие решений и спорить тут не с чем. Просто хотел уточнить:

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

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


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

            И такой еще вопрос:

            Представьте, что счетов очень много. У нас, например, бухгалтерия только платежки носит пачками по 250-300 листов за раз (с сопрводительными документами, естественно). На чем в реальной жизни зарабатывает тортики и даже серьезные откаты финансовый департамент? На ускорении либо замедлении проплат по счетам.

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

            Если же финансист получает деньги угрожая затянуть платеж, то уже после подписи шефа он может подержать счет еще неделю, собирая пропущенную информацию.

            Так что, что жестко регламентировать придется каждый этап — и я опять-таки не вижу особой разницы в подходе.
              –1
              Еще такое замечание:
              При этом в учетной системе приходилось заполнять много лишней информации для создания и согласования заявки: расчетный счет получателя и собственной компании, контрагент, статья расходов, статья движения денежных средств, основание и т.д. Вся эта информация, на самом деле, не нужна генеральному директору для принятия решения, но, тем не менее, ее необходимо заполнять сотруднику, отправляющему заявку.

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

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

              деньги (сколько мы должны выплатить);
              получатель (кому мы должны выплатить);
              назначение (за что выплачиваем).

              А, значит, заполняя лишнюю информацию, сотрудник теряет время, и процесс согласования затягивается.

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

              Вы извините, что я чот прям накинулся. Просто с корпоративными проплатами натерпелся.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Я представляю себе ситуацию, например, так: поступает счет, учетную информацию — конкретно расчетный счет — можно, по вашим словам, пока пропустить и нести руководителю на подпись. Теперь вы возвращаетесь к р/с и обнаруживаете, что он не совпадает со счетом в контракте. Насколько я знаю, большая разница — платить в местный банк или в оффшор.
                  +1
                  Эпоха BPM началась 10 лет назад и успешно загнулась 5 лет назад. BPMS — это инструмент окучивания толстого клиента, которому можно показать на экранчике схемку как работает его компания. Но мы-то с вами, конечно, понимаем, что это всего лишь один из способов программирования конечного автомата, и что десятками лет люди делают то же без всякого BPM.

                  Основные части BPMS:
                  1. Красивая схемка т.н. «бизнес процесса», желательно с визуальной программулиной, позволяющей расставлять на листе «ящички». И которая еще позволяет «запускать» процессы и показывать где он сейчас выполняется. Без этого не ничего продастся.
                  2. Некий навороченный «BPM-движок» весом в 30кб (jBPM), позволяющий «выполнять» позадачно диаграмму. Практически всегда требует базу данных, чтобы состоянию было куда-то сохраняться.
                  3. Fallback в какую-нибудь реальную среду проргаммирования: java, xquery, PL, etc… Как ни вертись, а ящики на диаграмме никакой полезной нагрузки не несут — приходится все-таки на чем-то кодить.
                  4. Паровозом предлагают средства интеграции с внешним миром: какую-нибудь самопальную ESB, JEE коннекторы, адаптеры, вебсервисы, etc…
                  5. Ну и самая основная часть — портал для Human Task-ов. Без него все ваши BPMS вообще не имеют смысла (а до 2005 года они скромно назывались Workflow). Визуально список папок по таскам а ля Outlook, на каждую задачу убогая стандартная формочка с данными, которую чтобы кастомизировать, то проще свой портал написать.

                  Что не так с BPM? А практически все.
                  — Вопреки изначальной идее, как ни старайся, динамически процесс изменить не удастся. Бизнес аналист расставит ящики и стрелочки. Затем каждый ящик закодит кодер. Затем аналист поменяет местами ящики в надежде, что все будет работать, но процесс благополучно упадет. Сколько ни пытался Oracle сделать колаборацию двух тулзов: BAM и BPM — хорошо все только на поверпоинтах.
                  — Резко поменалась бизнес логика, но половина процессов еще идет по старой версии. А интерфейсы, среда, база, модель — все уже новое. Версионность — основной бич всех BPM. Если в своем велосипеде ты полностью контролируешь педали, и можно эволюционировать запущенные процессы, просто актуализнув базу, то в пропиетарной BPMS — хрен ты до чего докопаешься.
                  — Возможности портала убоги. Всегда плохо адаптируется к реальным потребностям в интерфейсе. Интегрировать BPM в свой корпоративный портал тот еще танец с бубном.
                  — Одним BPM-ом сыт не будешь. Ящики должны выполнять какие-то полезные действия. Не всем же только управлять! Поэтому кодить все-равно придется. Но всегда где-то сбоку в окошке или через задницу.
                  — Интеграция. Достижение нашей BPMS в том, что есть специальный ящик, который умеет вызывать вебсервис. Правда хост намертво прибит гвоздями без возможности поменять, и все мэппинги нужно мышкой прокликивать в специальном окошечке, но это не беда.
                  — Ну и как бы зачем? Есть миллион других способов биться головой об стенку. Практика показывает, что эти решения не работают.

                  Вобщем, BPM — это исключительно инструмент бизнес-аналиста, и пусть таким и остается. А у нас, кодеров, свои приблуды. И нехрен мешать дерьмо с мармеладом!
                    0
                    Интересный комментарий. Была бы карма, поставил бы плюс 

                    Но всё таки это, немного, видение ситуации со стороны программиста. Положительный эффект для организации от внедрения BPMS может достигаться несмотря на весь негатив от ИТ. Только сформулировать его для себя я пока не могу.

                    Автоматизация основных бизнес-процессов? Не лучше в ERP это сразу делать. Настраиваемые бизнес-процессы сейчас даже в 1С есть.
                    Автоматизация неосновной деятельности? Здесь есть СЭДО, всевозможные issue-tracker’ы. Тоже все с воркфлоу.
                    Интеграционная платформа? Тут тоже явно есть более зрелые кандидаты. BizTalk, например. Тоже с оркестрацией.

                    При этом рынок BPMS вроде растёт, какие-то внедрения идут.
                    Что это? Чистый гербалайф?

                    Хотелось бы услышать от автора статьи его мнение, какой он идеальный для клиента кейс внедрения BPMS?
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Я примерно представляю основные возможности BPMS систем. Мой вопрос был не про то что они могут. Мой вопрос был про то когда их целесообразно применять.
                        Статья по ссылке не даёт никакой информации на эту тему, к сожалению.

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

                  Самое читаемое