Читать книгу Практические советы и рекомендации закупщикам. Сборник серии публикаций «От азов до совершенства» - Виктор Викторович Ковальский - Страница 22

3.1. Принципы описания и создания процессных моделей

Для отображения бизнес-процессов существуют определенные правила (нотации), такие как EPC, BPMN, IDEF, VAD и ряд других. Простой процесс, состоящий из нескольких действий, можно отобразить в произвольной нотации, используя набор графических примитивов. Но если процесс состоит из множества действий и событий, имеет ветвления и условия этих ветвлений, в процессе циркулируют десятки документов и другой информации, если процесс связан с другими процессам (что-то от них получает и что-то передает), если процесс частично проходит в информационной системе, частично – вне ее, то его отображение с помощью графических примитивов не только исказит действительность, но и приведет к различным ее толкованиям и запутыванию дел. В задачи данной книги не входит обзор нотаций и методов моделирования бизнес-процессов. В дальнейшем описании мы привержены положениям BPM CBOK (Business Process Management Common Body of Knowledge) и используем элементы нотаций VAD, IDEF 0, EPC.

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

Инициирующее событие – событие, с которого начинается процесс.

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

Важно определить начало и конец процесса, то есть его границы. Начальной границей (входом) может быть точка, где выходы других процессов стыкуются с Вашим процессом (служба технического обслуживания и ремонтов (ТОиР) сформировала заявку на товарную позицию – компрессор высокого давления – в рамках бюджета подразделения и инициирует перед закупочным подразделением ее реализацию). Конечной границей (выходом) является точка, в которой выход Вашего процесса служит входом в другие процессы (после выполнения заявки и поставки ее на складской терминал необходимо провести комиссионный входной контроль совместно с инициатором и лабораторией диагностики и после этого передать подразделению в монтаж). Необходимо принимать решение, включать службу диагностики в процесс или ограничиться только инициатором (службой ТОиР).

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

На этапе определения границ процесса важно определить основных поставщиков и потребителей и их требования. Потребители делятся на разные типы: первичные, вторичные и косвенные, потребители и не потребители. Давайте разбираться. Первичным потребителем является потребитель, который получает ресурс на первичном выходе процесса (в нашем случае – служба ТОиР). Вторичным потребителем является потребитель, получающий ресурс (продукцию или услугу) на вторичном выходе (в нашем случае – служба диагностики). Косвенным потребителем является потребитель после первичного потребителя (в нашем случае – монтажная организация). Все перечисленные типы потребителей являются внутренними подразделениями компании. Внешние потребители делятся на потребителей и не потребителей. Последние – это, как правило, дистрибьюторы или торговые представители. Потребителями являются конечные пользователи продукции или услуг. Без определения границ процессов, их входов, выходов и потребителей невозможно выстроить качественный бизнес-процесс.

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

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

События сменяют функции, передавая управление и ресурс от одной функции к другой.

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

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

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

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

1. Определить ожидания руководства от процесса, его границы (зоны ответственности), показатели результативности и эффективности.

2. Определиться с нотацией для описания функциональной модели и бизнес-процессов.

3. Определить границы процесса и построить функциональную блок-схему процессной модели и цикла закупок.

4. Сформировать целевую организационную структуру подразделения закупок.

5. Сформировать ролевую модель процесса.

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

7. Разработать процессную модель «как есть», желательно с применением средств автоматизации.

8. Проанализировать процессную модель «как есть» на оптимальность, разработать процессную модель «как надо». Обратить внимание на шаблоны документов.

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

10. Построить IT-архитектуру «как есть» на основе разработанной процессной модели, определить проблемные зоны в ландшафте автоматизации процесса закупок, разработать IT-архитектуру «как надо», приступить совместно со службой информационных технологий к разработке автоматизированных органайзеров и закупочных модулей.

11. Определить показатели процесса для его мониторинга.

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

13. Провести работы по автоматизации процесса.

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

3.2. Ландшафт процессов закупок

Любой процесс имеет определенную последовательность шагов (функций). Такое верхне-уровневое представление можно отразить в виде цепочки создания ценности. Универсальная цепочка создания ценности закупочного процесса представлена на рис. 7.

Рис. 7. Универсальная цепочка создания ценности

для закупочного процесса

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