Согласование заявок на закупку
Автор задачи - А. Белайчук
(Задача находится в процессе разработки)
Имеется энергетическая компания, основные активы которой - котельные и сопутствующая инфраструктура (котлы, теплотрассы и т.п.), разбросанные по просторам Сибири. Число котельных исчисляется тысячами.
Заказчик просит: автоматизировать процесс "Согласование заявок на закупку". Речь идет о ежегодной закупке труб для ремонта теплотрасс, комплектующих (вентили и т.п.) к ним, оборудования (например, котлов), ремонтных комплектов к нему и т.п. Помимо товаров, закупаются услуги. Все эти позиции приобретаются ежегодно в рамках подготовки к зиме.
В общих чертах со слов заказчика процесс выглядит так:
Инженер проводит дефектацию оборудования на месте и составляет перечень потребностей.
Заявки от котельных отправляются "наверх" на согласование. Путь наверх лежит через два промежуточных уровня иерархии: участок и регион. На каждом происходит согласование. Заявка может корректироваться, возвращаться назад на доработку и т.п.
Кроме того, заявки агрегируются, т.е. количество по сходным позициям суммируются. Делается это для того, чтобы в итоге разместить не множество мелких заказов, например, на трубы, а один большой - это позволяет добиться от поставщиков существенно более выгодных цен.
Сами заявки на закупку формируются на верхнем уровне - в головном офисе компании. При этом следует учитывать, что часть заявок можно удовлетворить товарами со склада, но большая часть потребностей покрывается закупками.
Суммарная агрегированая заявка на потребности разбивается на несколько заявок на закупки, т.к. разные виды товаров поставляют разные поставщики - например, трубы одни, фитинги к ним другие, а ремкомплекты к котлам - соответствующие производители. Таким образом, исходные заявки сначала группируются по товарам, потом разгруппировываются по товарным группам и/или поставщикам.
По каждой заявке на закупку проводится независимый конкурс среди поставщиков с соблюдением формальных правил: объявление конкурса, прием предложений от поставщиков, выбор победителя.
Согласовать тысячи исходных заявок и провести десятки тендеров - задача сама по себе не простая, особенно если учесть, что решается она с помощью только Excel и электронной почты. Процесс согласования заявок, группировки и разгруппировки позиций еще больше усложняется из-за того, что заказчик может вносить изменения и отзывать свою заявку асинхронно, после того, как она ушла на согласование.
В этой ситуации анализ бизнес-процесса и автоматизация работы с помощью BPMS выглядят вполне оправданными. Экономическое обоснование проекта не составляет труда, поскольку на кону очень большие деньги и очень большие потери в случае сбоя процесса. Причем потери не только финансовые, но и личные для руководителей: представьте себе поселок в Арктике, оставшийся не готовым к зиме.
Опытный аналитик знает: "заказчик просит не то, что хочет, а хочет не то, что ему на самом деле нужно". Применительно к процессам, этот закон означает, в частности, что в качестве "процесса" вам будут подсовывать фрагмент. И это именно такой случай.
Вот что выяснилось в разговоре с заказчиком:
"А еще бывает, что когда заказанные трубы наконец приходят, часть их "растаскивают" на авральные работы - где-то авария, и трубы ушли на ее ликвидацию. Оно бы и ничего - еще есть время дозаказать. Но проблема в том, что котельная, оформившая заявку на эти трубы, даже не узнает, что они ушли "налево"!
Примечательно, что сообщил это генеральный директор. Это, кстати, хороший урок для бизнес-аналитика: никогда не ограничивайтесь общением только с одним представителем бизнес-заказчика. Подход к работе, основанный на выделении одного т.н. "эксперта предметной области", себя не оправдывает. Постарайтесь хотя бы коротко, но пообщаться с руководителем - понять, как он видит бизнес-проблему. А также поговорите с теми, кто непосредственно делает работу. Очень часто в качестве эксперта предметной области выступает менеджер среднего звена, который стремится ограничить общение аналитика с кем-либо, кроме него: "зачем это вам, я вам расскажу все, что надо". Не поддавайтесь на эти уговоры - как правило, знает он не все, а отвечать за результаты анализа в конечном итоге вам, а не эксперту.
Что же означает эта "маленькая подробность"? Что с самого начала неверно обозначены границы процесса!
Напомню: исходно заказчик говорил о процессе "Согласование заявки на закупку". Соответственно, начинается он тем, что формируется заявка от котельной, а заканчивается тем, что из множества заявок котельных, прошедших группировку (по товарным позициям) и разгруппировку (по товарным группам и/или поставщикам) формируется набор заявок на закупку.
Можно продлить процесс дальше, включив в него размещение заявок у поставщиков, проведение тендеров и выбор победителей.
Но достаточно ли этого? Выясняется, что нет: заявки могут быть идеально сформированы, согласованы и заказаны, но заказчик свои трубы не получит, так как они ушли "налево". Это означает, что если мы хотим решить бизнес-задачу - обеспечения потребностей котельных в материалах, комплектующих, оборудовании и сопутствующих услугах - то нам не обойтись без того, чтобы расширить рамки процесса, включив в него контроль отгрузок по заявкам на закупку, превратившимся в договора с поставщиками.
Причем этот контроль отгрузок должен включать такую специфическую операцию, как "разноска" поступившего товара по заявкам котельных. Напомню: на этапе согласования заявки мы сгруппировали (просуммировали) множество заявок котельных. При оприходовании груза должна быть произведена обратная операция - надо решить какие заявки мы закроем, а какие останутся ждать.
И если из-за возникшей форсмажорной ситуации мы, например, часть труб из поставки забрали, то мы можем это проконтролировать и принять меры, чтобы дозаказать новую партию или как-то еще решить проблему с котельными, которым труб теперь не хватит.
Очевидно, название "Согласование заявки на закупку" такому содержимому соответствовать не будет. Не зря говорится, что "как вы корабль назовете - так он и поплывет". Назвали процесс "Согласование заявки" - получили согласованную закупку. И только!
Итак, мы выяснили, что "Согласование заявки" - явно не "end-to-end" процесс. Какими же должны быть рамки процесса, чтобы он решал бизнес-проблему? Как его лучше назвать, чем он должен начинаться и чем заканчивать?