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

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

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

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

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

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

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

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

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

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

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

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

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

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

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