Что такое "сквозной бизнес-процесс"?

23 марта 2015
30

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

Один из таких терминов - "сквозной процесс".

Начнем с трудностей перевода. Термин этот исходно английский: "end-to-end process", и было бы лучше переводить его не как "сквозной" процесс, а как процесс "от и до".

Но от чего и до чего? От самого начала и до самого конца, естественно. А что считать самым началом и самым концом? Вот это самый интересный вопрос.

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

Кейс №1: "Энергетика" ( Часть 1)

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

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

В общих чертах со слов заказчика процесс выглядит так:

  • Инженер проводит дефектацию оборудования на месте и составляет перечень потребностей.
  • Заявки от котельных отправляются "наверх" на согласование. Путь наверх лежит через два промежуточных уровня иерархии: участок и регион. На каждом происходит согласование. Заявка может корректироваться, возвращаться назад на доработку и т.п.
  • Кроме того, заявки агрегируются, т.е. количество по сходным позициям суммируются. Делается это для того, чтобы в итоге разместить не множество мелких заказов, например, на трубы, а один большой - это позволяет добиться от поставщиков существенно более выгодных цен.
  • Сами заявки на закупку формируются на верхнем уровне - в головном офисе компании. При этом следует учитывать, что часть заявок можно удовлетворить товарами со склада, но большая часть потребностей покрывается закупками.
  • Суммарная агрегированая заявка на потребности разбивается на несколько заявок на закупки, т.к. разные виды товаров поставляют разные поставщики - например, трубы одни, фитинги к ним другие, а ремкомплекты к котлам - соответствующие производители. Таким образом, исходные заявки сначала группируются по товарам, потом разгруппировываются по товарным группам и/или поставщикам.
  • По каждой заявке на закупку проводится независимый конкурс среди поставщиков с соблюдением формальных правил: объявление конкурса, прием предложений от поставщиков, выбор победителя.

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

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

Так что, формируем команду проекта, составляем план-график и беремся за работу? Или еще подумаем над постановкой задачи?

Оставляйте ваши предложения в комментариях. Ответ на вопрос и продолжение кейса - через неделю.

14468
Поделиться
Коментарии: 30

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    23.03.2015 16:08

    Оставлю это здесь просто чтобы подписаться на комментарии. Ну и заодно сообщить читателям: автор тут, готов ответить есличо.

  • Дмитрий Бацюро
    Рейтинг: 10
    -
    независимый эксперт по управлению ИТ
    23.03.2015 16:50

    Последний абзац явно намекает на подвох в постановке задачи. :-)

    У меня лично дискомфорт вызывают две вещи:
    1) Почему первоначальные заявки о потребностях асинхронно претерпевают изменения? Если инженер провёл диагностику и зафиксировал потребность в ремонте и материалах для него, то что заставляет эту потребность меняться? Может быть, начинать процесс надо не с фиксации потребности, а с фиксации текущего состояния - точнее, его отклонения от нормы, которая и вызывает потребность в ремонте? И согласование заявок тогда будет на чём-то основываться - что она соответствует устраняемому дефекту. Либо заявки тогда вообще можно будет централизованно формировать вместо того, чтобы согласовывать по двум уровням.
    2) Где тут конец процесса? Выбрали победителя конкурса, а где закупка, доставка, монтаж и, в конечном итоге, закрытие заявки, с которой всё началось?

    P.S. В этом кейсе явно не один процесс, а целый хореографический ансамбль. :-)

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    23.03.2015 17:09

    Дмитрий
    1) Видимо квалификация исполнителей бывает очень разной. Проще говоря, косячат. А кто без греха?
    2) Не, ну так не интересно. Убили всю интригу :)

  • Дмитрий Бацюро
    Рейтинг: 10
    -
    независимый эксперт по управлению ИТ
    23.03.2015 23:18

    Мне просто интересно дальнейшее повествование, а тут как-то не активно участвуют в дискуссии обитатели, поэтому немного ускорил. :-)

  • Андрей Семёнов
    Рейтинг: 10
    Клуб ИТ директоров Тюменской области
    Председатель правления клуба
    08.04.2015 16:02

    Вот так всегда, тема хорошая, экспертов мало или эксперты все заняты, поэтому здесь их мало. Верно Дмитрий Сергеевич подметил, нужно всё-таки дописать "до"! Будет интереснее!

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    08.04.2015 16:37

    Андрей, продолжение тут. С дискуссией.

  • Игорь Столяренко
    Рейтинг: 10
    АО "Россельхозбанк"
    Информационная безопасность
    12.04.2015 20:08

    Отвечу и здесь.
    Совершенно согласен.
    Цель поставлена. Заказчик присутствует. Определяем всех заинтересованных лиц. Формируем от них матрицу требований и состав рабочей группы (РГ), как представителей заинтересованных сторон. По итогам работы РГ определяем детальные бизнес-требования и уже после этого формируем план работ с участием всех уполномоченных лиц (команды проекта), перечнем работ и сроками по ним.

    • Дмитрий Бацюро Игорь
      Рейтинг: 10
      -
      независимый эксперт по управлению ИТ
      12.04.2015 20:24

      Игорь, подвох тут в том, какая именно цель поставлена - то есть в одном из первых ваших утверждений. Цель - реализовать процесс согласования заявок на трубы? Или цель - обеспечить своевременное обслуживание и ремонт? Эти разные цели породят разный набор проектных задач и, возможно, разные составы рабочих групп.

      • Виктор Федько Дмитрий
        Рейтинг: 298
        АО МПО им.И.Румянцева
        Зам. начальника управления информационных технологий
        12.04.2015 20:57

        Подвох тут в другом, на мой взгляд. Понятно, что "согласование заявок на трубы" цель не конечная. Но в этом случае и "обеспечить своевременное обслуживание и ремонт" тоже не окончательная цель. Далеко не окончательная. Можно выстроить цепочку следующих за ними следующих целей, которые достигаются предыдущими. Некую последовательность , которую вполне можно при великом желании назвать сквозным бизнес-процессом. И получим в итоге неуправляемого монстра. За то смотреться будет красиво. BPM во всей красе. Живет и побеждает.

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

        • Игорь Столяренко Виктор
          Рейтинг: 10
          АО "Россельхозбанк"
          Информационная безопасность
          12.04.2015 21:19

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

          • Виктор Федько Игорь
            Рейтинг: 298
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            12.04.2015 21:30

            Так это понятно. Цель проекта определяется потребностями бизнеса. В лице полномочного заказчика. Все остальные появляются потом.

      • Игорь Столяренко Дмитрий
        Рейтинг: 10
        АО "Россельхозбанк"
        Информационная безопасность
        12.04.2015 21:12

        Для этого есть куратор проекта. :)

  • 16.04.2015 15:25

    Самая главная проблема, с которой разработчик столкнется при реализации системы, в условиях кейса неявно обозначена, но, как мне кажется, не отрефлексирована.
    Это проблема классификатора предметов закупки. Если сейчас вся работа ведется в экселе и по электронной почте -- 100% вероятности, что такого классификатора нет. В результате при агрегировании заявок и их декомпозиции по предметам закупок и поставщикам будет огромное количество трудноустранимых ошибок. Можно отстроить прекрасный процесс и поддержать его замечательным механизмом BPM, но без создания единой системы НСИ по закупкам всё это будет работать через пень-колоду.

    • Анатолий Белайчук
      Рейтинг: 10
      Comindware
      Chief Evangelist
      16.04.2015 15:53

      Где Excel и где BPM...

    • Виктор Федько
      Рейтинг: 298
      АО МПО им.И.Румянцева
      Зам. начальника управления информационных технологий
      16.04.2015 15:58

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

      • Виктор
        16.04.2015 16:06

        Вы имеете в виду ОКПД-2, ОКВЭД или что? Ни один из общероссийских классификаторов невозможно использовать при организации закупок. Там очень многого не хватает, особенно если речь идет о конкретной продукции.

  • 16.04.2015 15:57

    Да жизнь показывает, что они могут оказаться в одном и том же нетрадиционном отверстии, если не учесть нетехнологические составляющие проекта.
    А НСИ в них как бы не самая дорогостоящая и трудоемкая часть.

    • Дмитрий Бацюро
      Рейтинг: 10
      -
      независимый эксперт по управлению ИТ
      16.04.2015 17:10

      Считаете, нужно начать BPM-инициативу с выстраивания бизнес-процесса ведения НСИ.

      • Дмитрий
        16.04.2015 17:49

        На самом деле создание практически любой ИС масштаба предприятия должно начинаться с:
        - аудита НСИ;
        - приведения НСИ в порядок;
        - выстраивания процесса ведения НСИ.

        Если, конечно, это уже не было сделано раньше :-)

        • Дмитрий Бацюро
          Рейтинг: 10
          -
          независимый эксперт по управлению ИТ
          16.04.2015 19:48

          Вот про процесс ведения НСИ - я думаю, надо отдельную дискуссию заводить. Есть ли вообще в природе такой процесс как "Ведение НСИ" и не двоюродный ли это брат "процесса" "Бухгалтерский учёт".

          • Дмитрий
            16.04.2015 19:57

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

            Обеспечение единства НСИ при децентрализованном ведении -- задача очень не тривиальная.

            • Дмитрий Бацюро
              Рейтинг: 10
              -
              независимый эксперт по управлению ИТ
              16.04.2015 23:45

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

              • Дмитрий
                17.04.2015 13:40

                Вот когда НСИ появляются в ходе "определенных бизнес-процессов", потом как раз и получается, что один и тот же товар заведен тремя разными людьми по-разному. И потом делаешь поиск по базе данных, и получаешь результат, который то ли достоверный, то ли нет. А то еще хуже (пример из жизни): сотрудники одного из подразделений, не желая изучать общий классификатор и искать, куда в нем отнести свои объекты, заводят новую ветку...

                Для того, чтобы этого не было, ведение НСИ выделяется в отдельный процесс, который должен быть регламентирован и контролироваться.

                • Дмитрий Бацюро
                  Рейтинг: 10
                  -
                  независимый эксперт по управлению ИТ
                  17.04.2015 14:41

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

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

      • Анатолий Белайчук Дмитрий
        Рейтинг: 10
        Comindware
        Chief Evangelist
        16.04.2015 17:50

        В любой непонятной ситуации наводи порядок в НСИ! :D

        • Анатолий
          16.04.2015 19:40

          Порядок в НСИ надо наводить в любой ситуации -- понятной, непонятной, запутанной, простой…
          Потому что отсутствие порядка в НСИ потом отзовется очень неприятными последствиями.
          Наведение порядка в НСИ, разумеется, никакую ситуацию не разрешит -- само по себе. Остальное делать тоже надо (определять границы бизнес-процесса; проектировать и оптимизировать сам бизнес-процесс; разрабатывать регламенты и инструкции; обучать людей следованию регламентам и инструкциям… часто этого достаточно для повышения эффективности и без автоматизации :-)

          • Анатолий Белайчук
            Рейтинг: 10
            Comindware
            Chief Evangelist
            17.04.2015 08:06

            К.О., перелогиньтесь! ;)

            • Анатолий
              17.04.2015 13:41

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

  • Анатолий Белайчук
    Рейтинг: 10
    Comindware
    Chief Evangelist
    17.04.2015 08:09

    Продолжение статьи:

Предметная область
Отрасль
Управление