Дмитрий Владимирович Пермяков
Бизнес-процессы. Стажировка нового сотрудника. Шаблоны бизнес-процессов (BPMN и EPC). Отдел продаж
Введение
Отдел продаж – эта тема не перестаёт быть актуальной на протяжении всего времени, что работаю на рынке управленческого консалтинга. И в нулевых годах, и в 10-х и сейчас этот вопрос остаётся самым освещаемым, самым болезненным, самым востребованным на рынке консалтинга. И действительно, именно в этом вопросе самое сложное сочетание бизнес-процессов и моделей управления персоналом. Сравниться по сложности с отделом продаж может разве что управление программистами – разработчиками программных продуктов – ну или отдел маркетинга, хотя и он, опять же, из области продаж.
При этом в отделе продаж есть множество моментов, которые практически под копирку одинаковы в разных направлениях бизнеса и для практически абсолютно любой численности этого самого отдела. Оговорюсь, что в данном случае мы будем рассматривать отдел продаж больше с позиции B2B (бизнес для бизнеса) рынка.
Где-то в 1/3 случаев моими заказчиками становятся не собственники бизнеса или директора, а сами руководители отделов продаж. Как один из них пояснил мне, что ему выгоднее нанять специалиста самому и тем самым окончательно закрепиться на новом месте, чем повторно искать работу. А если и не получится тут, то это будут его знания, которые он сможет продать и другому работодателю. С этим сложно поспорить.
Это издание нельзя назвать книгой в полном смысле, это скорее справочник или сборник бизнес-процессов. В некоторых случаях мы будем с вами уходить за рамки отдела продаж, так как его работа проникает в деятельность практически всего предприятия. Когда у нас будет возникать такая необходимость, мы будем рассматривать процессы за пределами отдела продаж в обобщенном виде.
В этом справочнике приводятся уже готовые шаблоны бизнес-процессов, которые были применены на практике.
Когда имеешь дело с бизнесом, который резко вырос, а у собственника это первый масштабный бизнес, нужна хоть какая-то точка отсчёта. Вот как раз в этом случае шаблон и выручает. В классике жанра принято при разработке бизнес-процесса опираться на то “как есть”, а потом улучшать. Но иногда это может быть невозможно, потому что в растущей компании с каждым крупным клиентом работают по-своему, и каждый сотрудник может работать по-своему, совсем не так, как его коллега. И классический путь в этом случае будет намного дольше. Шаблон может сработать как провокация, обсуждения которое позволит сразу найти оптимальное решение.
Собственники развивающегося бизнеса часто испытывают сложности при приеме на работу персонала. Бизнес не структурирован, и тяжело объяснить, как нужно работать и не забыть важные нюансы. И если качественный соискатель способен самостоятельно разобраться в особенностях продукции или услуг, то быстро наладить неформальные связи, на которых держится рутинная работа, ему будет сложно. Если же у вас есть прозрачная логика взаимодействия с бухгалтерией, складом, снабжением, если чётко описано, как нужно заключать договор, как регулируется ценовая политика, то ему будет комфортнее работать. Значит он быстрее выйдет на необходимый доход, меньше будет отвлекать коллег и значит, проще включится в работу. Согласитесь, вопрос расширения штата вопрос важный, а в некоторых случаях, определяющий успех.
Хотелось бы сразу предупредить, что прямое копирование бизнес-процессов может нанести и вред. Далеко не всегда бизнес-процесс, который вам понравился, можно просто взять и внедрить. Даже когда происходит адресная разработка бизнес-процесса, он всё равно должен пройти через не одно обсуждение. После того как все вопросы в режиме обсуждения решены, бизнес-процесс нужно проиграть. Попробовать пройти по нему, выполнив все элементы, убедиться, что оно именно так и работает. Это правило относится и к шаблонам
Бизнес-процессы представлены в 2-х формах: графическое отображение и текстовое описание. Самый рациональный вариант читать описание и смотреть на графику. Во многих случаях так проще разобраться.
В некоторых моментах я буду выныривать из предельно формализованной стилистики описания и иллюстрировать сложные моменты примерами.
Далее мы немного поработаем с теорией и перейдем к практике – рассмотрению основных процессов отдела продаж.
Основы работы с бизнес-процессами
Немного о заблуждениях в отношении бизнес-процессов
Даже среди программистов и бизнес-аналитиков нередко приходится сталкиваться с не совсем верным пониманием бизнес-процессов и нотаций, при помощи которых они отображаются. Чаще всего понимают так, что нотация – это графическая модель, при помощи которой отображается бизнес-процесс. На самом деле, это немного не так.
Нотация – это акцент на определенную методологию рассмотрения бизнес-процесса. В каком-то случае больше делается акцент на ресурсы и управление взаимодействием (это IDEF0), в другом больше внимание уделяется логике и логическим операциям, содержащимися в процессе (это BPMN), в другом случае акцент на действия и результаты (это EPC). Кстати, именно этот вариант наиболее удобен для написания инструкций, адресованных на конкретного исполнителя, а вот BPMN лучше подходит для описания взаимодействия между отделами и написания регламентов.
Соответственно, когда мы говорим о глубокой проработке организации, то потребуется использовать все 3 нотации. Обращаясь к той или иной, в зависимости от задачи, которая перед нами стоит.
Так как это издание больше прикладного характера, не буду уходить в теоретические изыскания, которые скорее всего будут интересны профессионалам в области бизнес-процессов, а не непосредственным потребителям плодов этого инструмента. Мы с вами будем использовать только 2 нотации (BPMN и EPC). В процессе того как вы будете изучать шаблоны, вы с лёгкостью сможете читать графику. Базовые понятия мы с вами разберем в этой главе.
В некоторых случаях мне приходилось полностью отказываться от привычной графики и отрисовывать бизнес-процесс в форме своеобразного комикса. Я не считаю, что это неправильно, а даже наоборот. В конечном итоге, бизнес-процессы (далее БП) – это всего лишь инструмент синхронизации и объяснения логики и если в каких-то случаях лучше уйти от классических канонов, то это нужно делать. Но это делается на уровне передачи результатов разработки рядовому сотруднику, но ни в коем случае не может делаться на этапах разработки или поддержания актуальности БП.
Собственно, вот мы с вами и добрались до следующего важного заблуждения о БП.
БП – это не кирпич, он живой и постоянно меняется. Понятное дело, что бизнес меняется вслед за ситуацией на рынке, вслед за новыми технологиями, а БП – это отражение этих изменений. Собственно, именно поэтому работа с БП требует поддержания их актуальности.
На практике нередко приходится сталкиваться с ситуациями (как правило это в крупных компаниях, холдингах), когда организация накапливает такое количество недостоверных регламентов и бизнес-процессов, что их нужно не то, что актуализировать, а практически заново проектировать.
Происходит это именно из-за того, что в хорошие времена уделялось время структурированию, а потом на это перестали обращать внимание, потом накопилось, а потом объём необходимых актуализаций стал столь велик, что придавил. В итоге система знаний компании (бизнес-процессы можно с уверенностью назвать памятью организации) просто обесценивается. Ей перестают верить сотрудники, начиная с рядовых, заканчивая топ уровнем.
Чтобы этого не происходило, работа с бизнес-процессами должна быть так же встроена в повседневную модель управления, как и контроль дебиторки, или уровня продаж, или контроль запасов. Если актуальность бизнес-процессов поддерживать каждый день, то это вполне выполнимая работа даже для небольшого бизнеса. В противном случае, даже ресурсов холдинга не хватит, чтобы своевременно навести порядок.
Собственно, это наиболее важные моменты, которые нужно знать по поводу бизнес-процессов.
Если вы уже знакомы с бизнес-процессами, то можете пропустить эту главу, так как я тщательно комментирую сложные элементы БП. Описание обозначений и технических особенностей БП и нотаций – это скорее дань академичности.
Нотация BPMN
На текущий момент эта нотация наиболее распространена. Это и понятно, так как она сосредоточена именно на процессе, его ходе. Она очень удобна для описания СRM и ERP и схожих систем, собственно этим и объясняется её популярность.
Business Process Model and Notation – тут даже переводчик не нужен. Даже из названия видно, на чём делали акцент разработчики этой нотации. Кстати, она была разработана в 2004 г, а последнее дополнение к ней вышло совсем недавно, в 2013 году. Так что можно считать, что это свеженький инструмент.
В состав этой нотации вначале входило всего десять обозначений, а в современной версии их уже ближе к сотне. Мы будем пользоваться в основном краткой версией, в некоторых случаях будем использовать и элементы полной версии. Но пусть это вас не пугает, её понятность это только увеличивает. Если будут возникать сложности, то вы всегда можете найти меня в социальных сетях и задать вопрос.
Ну а пока вот базовые элементы этой нотации:
Событие (круг);
Задача (прямоугольник);
Шлюз, развилка (ромб);
Поток, ход (стрелка);
Базы данных, документы;
Сноски, Пулы.
У нас всегда есть стартовое событие, запускающее процесс. Оно обозначается кружком с тонкой линией, в который может быть вписан значок, уточняющий характер этого события (Рис. 1. Примеры стартовых событий)
Рисунок 1. Примеры стартовых событий
События могут возникать и посередине БП. В этом случае процесс будет течь дальше, только тогда, когда это событие произойдет. В нашей графике это будет нечасто. Вот несколько примеров таких событий (Рис. 2. Примеры промежуточных событий). Обратите внимание, что у промежуточных событий кружок с двойной границей.
Рисунок 2. Примеры промежуточных событий.
Любой БП – это движение к результату, другими словами, он завершается событием. При чтении графики это сильно облегчает восприятие. И в отношении конечных событий мы будем применять практически весь доступный арсенал. Так как они будут подробно закомментированы, а кроме того, в текстовой части БП вы всегда найдёте описание таких событий, приведу только несколько примеров (Рис. 3. Примеры конечных событий.)
Рисунок 3. Примеры конечных событий.
Единственное замечание, которое нам осталось сделать о событиях, это закомментированность этого элемента графики. На мой взгляд, крайне важно контролировать целостность восприятия графики. То есть смотря на схему, пользователь должен сразу же видеть (считывать) основную мысль. Именно поэтому я сам всегда комментирую события и всем рекомендую (Рис. 4. Пример комментированности события). Под значком события просто добавляю лаконичный текст. Если случай совсем сложный, то пользуюсь и выносками (комментарии, как на наших рисунках под квадратной скобкой или овалы, как на этом рисунке).
Рисунок 4. Пример закомментированности события.
Теперь, давайте познакомимся с Задачами – это прямоугольник, в котором написана задача. С этим элементом графики всё достаточно просто. Нам нужно уметь отличать Задачи, которые будут детализированы (являются отдельным БП), и те, которые далее уже не будут детализировать.
В вопросах детализации (декомпозиции – если придерживаться классической терминологии) есть один хитрый нюанс. По сути, можно детализировать любую Задачу, но главное не переборщить. Можно же при помощи графики описать и процесс набора текста на клавиатуре компьютера, но вот нужно ли это… Мы будем понимать под термином вложенный “бизнес-процесс” (см. Рис. 5) задачу, которая требует 2-го уровня детализации. Например, “Подписание рамочного договора с клиентом” – это вложенный БП. Чтобы его подписать, необходимо проверить благонадёжность клиента, оценить его влияние на рынок, выбрать оптимальные условия сотрудничества и т.д. (нужно ещё много чего сделать). Причем в этом случае может быть задействован руководитель отдела, который должен одобрить условия такого договора, может быть привлечена служба безопасности, юристы. Проще говоря, это работа не только менеджера, но и ряда коллег или смежных отделов.
Если же мы с вами имеем дело с такой задачей, как размещение заказа на складе, то дальнейшая детализация будет уже описывать его действия. То есть мы с вами выйдем на уровень инструкции. В этом случае мы не предполагаем детализации на уровне BPMN, а сразу начинаем описывать действия в нотации EPC.
Отличить простую задачу от вложенного процесса легко – у вложенного БП есть крестик. (Рис. 5. Простая задача и вложенный БП.)
Рисунок 5. Простая задача и вложенный БП.
В рамках этой нотации нам осталось разобраться только со “шлюзами” и сделать пару замечаний по поводу стрелок.
Шлюз – это один из самых важных элементов БП, так он показывает логику процесса работы. В полной версии BPMN порядка 6 видов шлюзов. Мы будем использовать только основные. Их я укажу ниже (Рис.6).
В зависимости от того, как расположен шлюз, он может немного менять логику. На этот момент нужно обращать особое внимание. Тут как в русском языке – неправильно поставили запятую и казнили человека, вместо того чтобы помиловать. Этот момент лучше осваивать на практических примерах, поэтому затронем его поверхностно. Кстати, те, кто помнит формальную логику (вузовский предмет), очень легко воспринимают “Шлюзы”. Так как по сути – это всё те же логические операции, только сильно упрощённые. Вот перечень основных шлюзов (Рис. 6 Основные шлюзы):
Рисунок 6. Основные шлюзы.
Если шлюз стоит перед задачей, то он управляет входом в эту задачу, если после, то расшифровывает логику выхода из этой задачи.
Например, нам нужно на графике отобразить такую ситуацию: Если «все требования выполнены» (товар оплачен, менеджер подтвердил отгрузку), то «совершить отгрузку» (нижняя часть графики). ИЛИ «Оплата товара не произведена» и «необходимо сообщить об этом менеджеру» (Рис. 7. Пример исключающего ИЛИ на выходе)
Рисунок. 7. Пример исключающего ИЛИ на выходе.
Этот же шлюз может быть расположен перед задачей, тогда он будет читаться по-другому (справедливости ради, в этой ситуации его можно заменить OR (ИЛИ), но это задаёт тонкости прочтения, пока их опустим). Например, у нас вот такая ситуация: Мы проводим проверку зарезервированных товаров под заказы. Среди них мы обнаруживаем те, у которых срок резервирования просрочен более, чем на 3 дня. Их мы должны снять с резерва. Кроме того есть заказы, по которым срок резерва вышел сегодня или вчера. В отношении этих заказов нужно связаться с клиентом. В результате этого, часть заказов нужно будет снять с резерва, а часть оставить. В графике это будет выглядеть так (см Рис. 8. Пример исключающего ИЛИ на входе).
Рисунок 8. Пример исключающего ИЛИ на входе.
Обратите внимание, что на выходе применён “Исключающий ИЛИ” с маркером (“Х” в ромбе), а на входе в задачу «Снятие товара с резерва» просто пустой ромб. Хотя и то, и другое обозначение относятся к одному и тому же Шлюзу, применение разных обозначений более наглядно – графика подсказывает вам, что “Х” в ромбе – это исходящий Шлюз, а пустой ромб – входящий. Входящее расположение XOR указывает на то, что «снятие товара с резерва» выполняется тогда, когда срок резерва просрочен на 3 и более дней. Кроме того, если резерв по каким-либо причинам не актуален, то мы тоже снимаем товар с резерва.
