Что это и зачем нужно

Бизнес-процессы в 1С Битрикс: уровень 1

1 уровень – интуитивно все понятно из интерфейса, но почитать стоит.

Недоступно в лицензиях: Старт, Стандарт, Малый бизнес

Структура конструкции

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

С версии 22.400.0 модуля Бизнес-процессы ветки условий можно легко менять местами и копировать с помощью стрелок. Для экономии места на схеме можно свернуть всю конструкцию с помощью кнопки.

Проверка условий выполняется слева направо. Если условие выполняется, то действия, расположенные в ветке под ним, будут исполнены. Если же условие не выполняется, то происходит переход к условию, расположенному правее, и так до тех пор, пока какое-либо условие не будет выполнено.

Типы условий

В списке типов могут отображаться не все типы условий, перечисленные ниже (зависит от самого бизнес-процесса и наличия переменных/параметров).

Если ни одно из условий не выполнится, то бизнес-процесс продолжит выполнять действия расположенные под конструкцией Условие.

Подробнее об И/ИЛИ

При выборе И ветка условий будет исполняться при выполнении обоих условий, а при ИЛИ – любого из указанных.

Простое пояснение логики без привязки к бизнес-процессам

Отдельное внимание обратим на условие не равно. Если вы хотите сделать проверку неравенства поля нескольким значениям, то есть смысл использовать только И. В случае использования ИЛИ, условие всегда будет истинным, так как поле окажется всегда не равно одному из значений.

Если несколько условий

При использовании нескольких условий и одновременно сравнений И и ИЛИ, приоритет будет у И. В виде формулы это можно представить так: (УСЛ1 И УСЛ2) ИЛИ (УСЛ3 И УСЛ4)

Описание условий

Как работать с условиями в SEO копирайтинге

Меньше

Сравнивает указанные значения между собой. Если первое значение меньше второго, то выполняется ветка условия. Это аналогично записи Var1 < Var2.

Представим, что с 01.06.23 мы изменили правила подготовки документов по сделке. Какие документы готовить, старые или новые, проверим условием по дате начала сделки. Готовим по старому алгоритму, если:

• Тип условия: Поле документа
• Поле документа: Дата начала
• Условие: меньше
• Значение: 01.06.23

Не больше

Сравнивает указанные значения между собой. Если первое значение меньше или равно второму, то выполняется ветка условия. Это аналогично записи Var1 <= Var2.

Решим предыдущую задачу другим способом:

• Тип условия: Поле документа
• Поле документа: Дата начала
• Условие: не больше
• Значение: 31.05.23

Содержит

Проверяет, содержится ли второе значение в первом. Если содержится, то выполняется ветка условия. Оно работает в том числе по подстроке.

Предположим, вы настроили интеграцию интернет-магазина на 1С-Битрикс: Управление сайтом с Битрикс24. Теперь заказы из магазина приходят в Б24 в виде сделок с автоматически формируемыми названиями Eshop0 #1, Eshop0 #2 и т.д.

Создадим условие, которое будет проверять содержится ли в названии сделки слово Eshop, чтобы потом переносить такие сделки в другую воронку:

• Тип условия: Поле документа
• Поле документа: Название
• Условие: содержит
• Значение: Eshop

Не содержит

Проверяет, не содержится ли второе значение в первом. Если не содержится, то выполняется ветка условия. Особенности работы аналогичны предыдущему условию.

Вы постоянно тестируете разные сценарии на специально созданных тестовых сделках. В названиях таких сделок есть слова тест или тестовая. Чтобы шаблон пропускал такие сделки используем условие:

• Тип условия: Поле документа
• Поле документа: Название
• Условие: не содержит
• Значение: тест

Не заполнено

Ветка выполнится, если значение не заполнено (пустое).

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

Можно разветвить процесс таким условием:

• Тип условия: Поле документа
• Поле документа: Важно
• Условие: не заполнено

Между

Условие выполнится, если значение попадает в заданный промежуток / период времени (включая крайние значения). Доступно с версии модуля 23.400.0 для полей / переменных типа Число или Дата и время.

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

• Тип условия: Поле документа
• Поле документа: Дата создания элемента
• Условие: между
• Значение 1: 01.01.2022 00:00:00
• Значение 2: 31.12.2022 23:59:59

Оптимизация и реинжиниринг бизнес-процессов: различия

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

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

Оптимизация бизнес-процессов: технология или искусство?

Таблица 1. Различия между реинжинирингом и оптимизацией бизнес-процессов

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

Реинжиниринг требуется в тех случаях, когда на рынке произошли существенные изменения, например:

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

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

Искусство или технология?

Наша статья рассматривает описание бизнес-процессов не как высокое искусство “haute couture”, а как технологию, поэтому таких примеров в ней не будет.

В последние годы увеличилось число специалистов именно по вопросам оптимизации деятельности: директоров по развитию, консультантов и т. д. Они получили специальное образование и имеют большой опыт решения задач оптимизации, а также владеют технологиями оптимизации. Технология в отличие от искусства – это последовательность действий, которая приводит к гарантированному получению результата и может быть передана другому человеку за короткий промежуток времени. Понятно, что технология описания бизнес-процессов не поможет создать шедевр мирового уровня как “Черный квадрат” Малевича , но на окрашенной с соблюдением соответствующей технологии в черную краску классной доске действительно можно будет писать мелом, так чтобы написанное могли прочитать и ученики на задней парте, а не только учитель.

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

Мысли глобально, действуй конкретно. Основные принципы технологичной оптимизации

Можно выделить четыре главных принципа.

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

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

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

Из данных принципов достаточно логично следуют условия и шаги проведения оптимизации:

1. Перед тем как начинать работу по оптимизации, необходимо описать существующие в компании бизнес-процессы «как есть» (создать их модели). Описания бизнес-процессов должны быть четкими, однозначными и затрагивать уровень, на котором видна конкретная работа сотрудников. Объем моделей может быть разным: как по отдельно выделенному бизнес-процессу, так и по группе взаимосвязанных бизнес-процессов. Безусловно, чем больше бизнес-процессов описано в модели, тем лучше и шире можно оценить их оптимальность.

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

3. Проанализировав каждую процедуру и определив ее явные недостатки, можно оценить оптимальность управления бизнес-процессом и оптимальность группы процессов. Результатами оценки оптимальности должны стать выявленные недостатки в процессе и/или группе процессов.

4. Затем надо разработать предложения по исправлению выявленных недостатков, перестроить описание модели бизнес-процесса («как будет»), учитывая данные предложения, пересмотреть действия исполнителей и кандидатуры самих исполнителей (если это необходимо), а самое главное — улучшить средства труда. Улучшение средств труда заключается, конечно, не в разработке экспертных систем (осуществляемой в процессе реинжиниринга), а в усовершенствовании форм фиксации, хранения и первичной обработки данных, используемых при выполнении конкретной процедуры. Например, когда полномочия устанавливать правила предоставления скидок делегируются менеджеру по продажам, можно вставить в электронную форму бланка-заказа поля, при заполнении которых расчет скидки будет производиться автоматически (при этом может использоваться обычный Microsoft Excel).

5. На завершающем шаге надо оценить возможные ухудшения от предлагаемых улучшений в других местах процесса, в том числе и возможное сопротивление сотрудников.

Каким должно быть «правильное» описание бизнес-процесса

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

Рис. 1 Пример малоинформативной схемы бизнес-процесса (простая часто встречающаяся схема)

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

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

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

1. Операция — это минимальная из анализируемых частей деятельности отдельного сотрудника, выполняемая им без проведения осознанного контроля, «машинально», автоматизм ее выполнения приобретается за счет многократного повторения (например, переключить скорость или нажать Ctrl+B в редакторе Microsoft Word, чтобы сделать начертание слова полужирным шрифтом). Любая операция когда-то была действием.

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

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

4. Направление деятельности — это укрупненная часть деятельности организации, состоящая из одной или нескольких групп бизнес-процессов базового уровня.

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

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

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

Кроме того, при описании бизнес-процесса важно уделять внимание таким, казалось бы, мелочам как способы передачи информации и носители информации (например, информация, переданная устно, в лучшем случае может быть «испорченным телефоном», а в худшем — потеряться). Именно они могут стать одним из объектов оптимизации.

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

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

Затем договор попадает к юристу, который проверяет его правомочность. Он определяет, не противоречит ли договор законодательству, не нарушены ли интересы компании, сможет ли компания выиграть дело в суде, если оно будет возбуждено. Юрист также подтверждает своей подписью то, что он проверил договор, а значит, несет ответственность за правомочность данного договора.

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

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

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

По такой схеме (при наличии знаний и опыта участия в бизнес-процессе) уже можно проводить оценку оптимальности.

Параметры оценки оптимальности

В первом случае директор смотрит на схему, думает и говорит: «Плохо, что передача информации является устной, необходимо подавать замечания в письменном виде за два дня!» Он просит своего секретаря подготовить соответствующее распоряжение. В результате нового описания бизнес-процесс не улучшается, подача замечаний в письменном виде только растягивает и без того длительный процесс согласования, а также отнимает время у всех исполнителей процедур. Раньше специалисты могли быстро устно сформулировать свои замечания, а теперь им приходится письменно выражать свои мысли, что для них мучительно сложно. Форма не задана, образцов нет, навыков, как правило, тоже (из тех исполнителей, которые перечислены на рис. 2, навык письменной речи нужен, пожалуй, только юристу, да и то лишь иногда). Суть описанного бизнес-процесса и алгоритм принятия решений остались прежними. Кроме того, допустим, что замечания согласующим лицом подаются за два дня. После их устранения Менеджер направляет проект договора на повторное согласование согласующему лицу. Согласующее лицо опять-таки в течение двух дней либо согласует, либо дает новые замечания. И так далее – количество итераций по согласованию не ограничено (то есть на согласование с одним специалистом уходит от 2 до 2*N рабочих дней, где N- количество итераций по согласованию).

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

Кратко остановимся на проведении оценки по некоторым из этих параметров, используя в качестве примера описание бизнес-процесса заключения договора на предоставление телекоммуникационных услуг.

Качество конечного результата. Как сидит костюмчик?

В описанном выше бизнес-процессе клиентов не устраивало два аспекта: время, затрачиваемое на их обслуживание, и уровень понимания их потребности. Заключают договор на высокоскоростное подключение, а в ходе исполнения выясняется, что кабельная линия не обеспечивает требуемого трафика. И клиенту предлагают доплатить за прокладку оптоволоконного кабеля или говорят «подождите весны» (ибо оптоволокно зимой не сваривают). А у него бюджет уже сверстан и он резонно спрашивает: “А где же вы раньше были? При подготовке Договора?”. И уже неважно, что юрист предусмотрел нужный пункт в Договоре – лояльность клиента потеряна, и пошло тратиться время начальника отдела продаж, директора и юристов на разрешение конфликтной ситуации.

Руководство компании было недовольно следующим:

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

Качество промежуточных результатов

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

Бизнес-процесс должен быть описан так, чтобы пользователь следующей процедуры должен получать результат в виде и форме наиболее удобном для работы (по возможности). Например, когда юрист может не читать каждое слово в типовом договоре? В двух случаях: если типовой договор является ксерокопией, и вся специфическая информация вписана от руки, или если менеджер пользуется файлом, закрытым для редактирования, кроме ввода данных в специальные поля. Если же исполнитель пользуется обычным документом в формате Microsoft Word – читать надо внимательно и аккуратно, кто его знает, что он ещё поменял в исходном выверенном тексте.

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

Содержательность действий исполнителей

Как говаривал профессор Преображенский : «Я сторонник разделения труда. В Большом пусть поют, я буду оперировать. И никаких разрух».

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

Помимо этого, юрист, проверяя договор проекта, иногда совершает следующие действия:

Теперь расскажем о том, каковы критерии оценки оптимальности процедуры. Итак, процедуру можно назвать оптимальной, если выполняются перечисленные ниже условия:

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

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

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

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

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

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

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

Оценка схемы описания и эффективности управления бизнес-процессом

Оценка схемы описания бизнес-процесса и эффективности его управления — обширная тема. Мы не будем раскрывать ее в рамках данной статьи, приведем лишь некоторые показатели и критерии.

При оценке схемы описания бизнес-процесса используются следующие показатели и критерии (критерии приведены в скобках).

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

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

А вот менеджера процесса часто просто не удается выявить, поскольку за конкретный случай прохождения процесса чаще всего никто не отвечает. Все стремятся «отвечать за пуговицы». И даже если менеджер процесса установлен, то возникает проблема наличия у него рычагов воздействия на исполнителей процесса (то есть полномочий для принятия тех или иных решений).

Внедрение рекомендаций по оптимизации

Юридический отдел разработал формы типовых договоров и совместно с начальником отдела продаж установил четкие правила определения, договор какого типа должен быть заключен в том или ином случае Начальник отдела продаж разработал бланк-заказ, который помогает менеджеру точно узнать требования клиента, условия работ, стоимость и тип договора.

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

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

Реализуя только эти меры, мы уже частично уменьшили сложность согласования, а значит, и сократили время согласования.

Но на этом возможности описания нового бизнес-процесса не исчерпываются. Следующим шагом будет оптимизация самого процесса — превращение последовательного согласования в параллельное. Проблема существующего процесса заключается в том, что если на последнем этапе согласования допускается какая-либо ошибка, необходимо вновь проводить все предыдущие этапы. Поскольку согласование договора является последовательным, то затраты на него все время складываются. Таким образом, при условии, что согласование с непосредственным руководителем — это X часов, с юридическим отделом — Y часов, с финансовым отделом — Z часов, получаем общее время согласования X+Y+Z. Если сделать данный процесс параллельным и нормировать время на проведение согласования, то получим, что процесс согласования может быть осуществлен за N часов. В подавляющем большинстве случаев N будет гораздо меньше, чем сумма X+Y+Z. Например, в отделении одного крупного западного завода в России есть норма на получение подписи на договоре — один рабочий день. Процесс последовательный. Для получения трех подписей вам потребуется три дня. А если сделать данный процесс параллельным, подписи можно собрать за один день.

Но при этом нельзя забывать, что решения по оптимизации редко бывают однозначными! Неоднозначность решения по оптимизации в нашем примере может заключаться в том, что даже после того, как мы сделали процессы параллельными, нам сложно проверить договор, разработанный менеджером как единое целое. То есть подписи юристов и финансистов на разных вариантах договора есть, а вот как их собрать на конечный экземпляр? Кроме того, сложно понять, какие замечания были к договору у всех заинтересованных лиц, ведь в конечном итоге нам необходимо проверить исправлены ли они. Выход из данной ситуации в добавлении в описание бизнес-процесса еще одного документа – Листа согласования. То есть теперь в нашем оптимизированном процессе каждое согласующее лицо обязано в письменной форме отражать все свои замечания в документе “Лист Согласований”. Листов согласований должно быть столько же, сколько у нас в процессе присутствует согласующих лиц. Если хоть один из согласующих лиц не согласен с представленной версией договора, он дорабатывается и вновь высылается всем заинтересованным лицам на согласование с пометкой измененных мест! И так до тех пор, пока замечания не закончатся. Листы согласований хранят всю историю согласований. Договор считается согласованным, когда все согласующие подтвердили его правильность.

Итак, вернемся к описанию бизнес-процесса заключения договора на предоставление телекоммуникационных услуг связи. Мы изменили бизнес-процесс, а именно:

Мы увидели, как можно оптимизировать такой маленький фрагмент, такого небольшого бизнес-процесса, если знать основные принципы оптимизации, которые мы приводили выше. Что же необходимо сделать для этого?

Бизнес-процесс — это стандартный и повторяемый набор действий, который использует компания для достижения конкретной цели. То есть пошаговое руководство, что и как делать для получения результата.

Бизнес-процессы есть в каждой организации — даже если они не прописаны. Любая компания делает последовательные шаги А ➡️ Б ➡️ В ➡️ Г ➡️ для получения результата Д (продукт, услуга, продажа).

Это основа функционирования организации. А если процессы описаны, то в компании и в работе каждого сотрудника меньше хаоса. Ресурсы используются оптимально, и это ведёт компанию к лучшим результатам 🙂

Виды бизнес-процессов

Обычно выделяют пять видов бизнес-процессов — хотя можно и больше. Предлагаю остановиться на основных, чтобы не запутаться и понять, чем они отличаются друг от друга.

Те, благодаря которым и создаётся конечный продукт. Это процессы, которые непосредственно приносят прибыль, — то есть компания благодаря им живёт.

К примеру, для производителя одежды основные бизнес-процессы — планирование коллекции, закупка материалов, производство продукции, продвижение товара на рынке, продажа и доставка.

Обеспечивающие

Те, что делают возможными основные процессы. Здесь клиентами выступают сотрудники компании.

Это бухгалтерский учёт, юридическое, кадровое обеспечение, IT-обслуживание — и элементарно закупить воды и печенек в офис.

Вспомогательные

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

Это обслуживание и ремонт оборудования, закупка более продвинутого софта, ремонт и улучшение офиса.

Процессы развития

Эти процессы нужны для усовершенствования уже готового продукта или услуги.

Например, улучшение рецептуры, повышение эффективности при работе с клиентом, повышение прибыльности, снижение затрат, обучение персонала.

Процессы управления

Они ничего не производят, но без них другие процессы не будут работать. Такие процессы регулируют стратегическое и корпоративное управление и операции. Они устанавливают стандарты и цели, которые обеспечивают эффективную работу других бизнес-процессов.

Это контроль, планирование и мониторинг.