Что такое бизнес процесс в программировании

Что только не писали на Хабре про бизнес-процессы: про общую философию, про программирование процессов, про многочисленные BPM-системы, про нотации и т.д. В принципе, вендору всё понятно: взял процесс, очистил его от очисток, смоделировал, автоматизировал и запускай экземпляры, когда нужно. Дел-то. Между тем, бизнес, которому статьи адресованы, зачастую не понимает главного — зачем ему эти бизнес-процессы? Он ведь не Газпром какой и не концерн Калашников. Тут бы главные дела решить: чтобы сроки не срывались, сотрудники бы не теряли документы и не валили бы вину друг на друга, а то среди этого бардака уже и прибыли не видно…

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

Pikabu.ru. Типичная организация процесса в компаниях любого уровня: «Лебедь рвется в облака, Рак пятится назад, а Щука тянет в воду. Кто виноват из них, кто прав, — судить не нам; Да только воз и ныне там».

На мысль об этой статье нас натолкнула собственная же статистика. Дело в том, что в RegionSoft CRM встроен модуль бизнес-процессов, которым мы гордимся: нативный графический + логический редактор, простое управление, возможность проектировать самые сложные процессы без знания программирования. Но нет.

Функциональностью бизнес-процессов пользуются около 12%-14% клиентов. Это мало, это непонятно, это странно — иметь надёжный и простой инструмент и игнорировать его.

За проверкой гипотезы (на самом деле, мы и так знаем ситуацию, но всё же) идём в Google Trends. Собственно, это всё, что нужно знать про интерес российского бизнеса к бизнес-процессам:

• зона интереса — крупные мегаполисы, где сосредоточены большие и продвинутые в ИТ-плане компании
• уточнение интереса (конкретные запросы) — скорее образовательные: «бизнес процесс пример», «бизнес процессы», «бизнес процесс это» и т.д.
• с 2008 года стабильное падение интереса (влияние кризиса).

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

Бизнес-процессы — это цепочки действий и событий, которые происходят в компании и приводят к конечному результату. Пример: приём на работу и адаптация сотрудника, закупка и запуск ПО, рассылка и т.д.

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

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

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

• неэффективными — при больших трудозатратах приносить минимально приемлемый вариант, задействовать слишком много ресурсов;
• медленными — из-за несогласованности участников процесса и отсутствия чётко обозначенных этапов и сроков, отведённых на каждую задачу;
• ненадёжными — такие процессы приводят не к ожидаемому результату, а к его частичной реализации либо к полному отсутствию итогового результата;
• дублирующимися — не самый плохой вариант, однако такие процессы перегружают работников и потребляют больше ресурсов, чем это делает один оптимизированный процесс;
• избыточными — слишком большое количество этапов,  задач и связей перегружают процесс, и в итоге достижение цели откладывается либо обходится слишком дорого;
• неработающими — без комментариев, это явно кризисное явление (такое происходит, например, в случае, когда подразделения не обмениваются информацией: технари разработали новый софт, маркетологи придумали продвижение, 15 октября всё выгрузили на сайт и в сторы, а продажники об этом даже не слышали, поэтому не могут отвечать на вопросы клиентов и работать в принципе);
• лишними — в компании сохраняются старые процессы или процессы, которые стали неактуальными в рамках текущей деятельности; худший вариант, когда такие цепочки обязательны к исполнению.

Откуда столько бед с бизнес-процессами?

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

Первая причина кроется в том, что процессы включают в себя очень много человеческого труда. Если нет автоматизации, то почти всё делает человек: выписывает документы, совершает звонки, вносит или не вносит задачу в календарь, выполняет свою основную деятельность. У каждого сотрудника своя мера ответственности, пунктуальности, добросовестного отношения к работе и т.д. А поскольку в каждом процессе задействовано несколько человек, ошибки накапливаются и выливаются в сорванный процесс или в совсем не тот результат, который необходим.

Например, программное агентство работает в Казани. Заказчик из Владивостока просит доработку, допустим, CRM-системы в кратчайшие сроки, поскольку через неделю запускает новую линейку продукции. Доработка — сущая мелочь, нужны требования и подписанное ТЗ. Менеджер из Казани должна утром связаться с заказчиком, опросить его, согласовать детали и получить документы. Но она вспоминает об этом в 17:00. Всё, как минимум сутки простоя программистов по этому проекту обеспечены — им теперь нужно смещать проекты, перепланировать время, чтобы смочь взять проект в работу как только появятся конкретные требования. Процессы «поехали».  

Вторая причина — плохой контроль. Мы уже сотню раз писали в своих статьях о том, что контролировать нужно не то, как работает человек, а то, какие показатели и какое качество он выдаёт. Сегодня пошла какая-то повальная мода следить за каждой секундой рабочего времени, а итог всё равно г****. Знаете, в чём причина? Люди а) боятся б) имитируют так, как угодно системе (

вот я сижу за компом, у меня открыт очень важный документ и я уже 2 часа гоняю в нём пару строчек / пишу и переписываю код одной функции). Это плохой контроль. Хороший контроль — это умение так поставить задачи и увязать с ними мотивацию, чтобы сотрудник сам с радостью организовал своё рабочее время и выполнял задачи (тут как раз речь о делегировании, методологиях разработки и системе KPI, если речь идет о менеджерах и коммерсах).

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

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

Что делать с бизнес-процессами?

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

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

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

Итак, какие плюсы даёт автоматизация бизнес-процессов?

Формальная прописанная логика и чёткое исполнение. Автоматизированный процесс — это «запрограммированная» модель, доступные данные и логирование всех действий. За смену этапов, уведомления, документы, письма и ещё некоторые атрибуты отвечает программа — именно она от раза к разу запускает всё в нужные сроки и заданные интервалы времени (17 апреля запустить экземпляр процесса, 18-го отправить напоминание участникам А и Д, 19-го на основании работы А и Д сформировать счёт и отправить в оплату, отправить уведомления Е, напоминания Б, Ж, З, 22-го на основании всей выполненной работы сформировать отчёт и отправить Х).

Обоснованность решений. Бизнес-процессы пронизывают всю деятельность компании и, когда они автоматизированы, накапливается точная и актуальная информация о клиентах, сделках, ассортименте и т.д. То есть, допустим, если у вас BPM встроен в каком-либо виде в CRM-систему (как, например, это сделано в RegionSoft CRM), то все данные в течение реализации процесса разносятся по своим таблицам, а значит, появляется информационная база для анализа и обоснования принимаемых решений. Кстати, в «чистых BPM-системах» вся информация также накапливается, но не всегда в том разрезе, в каком она необходима для оперативной работы.

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

Рост производительности труда. Всё просто: часть работы перекладывается на программу, поэтому «вкалывают роботы, счастлив человек». Чаще всего автоматизируются именно рутинные процессы (то есть те, которые циклично повторяются и требуют однообразного труда, поддающегося формальному описанию), поэтому у сотрудников появляется больше времени для работы, нацеленной на общение с клиентами, развитие продукта и т.д.

Вот например, статья на Хабре или в Форбс в большой компании. Автор выбирает тему, списывается со всеми, согласует, потом пишет, всем пишет, что написал, все читают, вносят сто миллионов правок, он снова пишет, все читают и т.д., потом кто-то мастерски это дело верстает, ищет/рисует картинки и т.д. Море формальной переписки, которую можно заменить на оповещения по действию «Файл загружен». А высвободившееся время можно направить на более глубокую работу с текстом.

Гибкость компании по отношению к изменениям. Увы, в наше время изменения могут прилететь откуда угодно: уволились сотрудники, принят новый закон, наложили санкции на санкции и вот уже бизнес вынужден адаптироваться к изменениям. Даже если они очень хорошие, для компании это всегда стресс. Автоматизированные процессы легко изменяются и ориентируются под новые условия — бизнес быстро перестраивается на нужные рельсы. Сегодня гибкость и умение адаптироваться — залог успешной эволюции бизнеса на рынке. К сожалению, бюрократизированные неповоротливые динозавры вымрут.

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

Года три назад в одной из зарубежных аналитических статей я прочитал хорошее разъяснение важности процессов на примере Википедии. Этот проект = мега распределённая команда (весь мир) + мега рутинные задачи (тексты, правки, фактчекинг) + мега отлаженный процесс с максимальной автоматизацией. В итоге за счёт постоянного улучшения регламентов, форм, коммуникаций так называемая «совместная анархия» обрела классную и полезную форму.  

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

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

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

Защита непрерывности бизнеса от кадровых проблем. HR-проблемы случаются постоянно: болезни, отпуска, текучка кадров (особенно, среди продажников, телемаркетологов, менеджеров среднего звена и т.д.). Когда сотрудник выпадает из рабочего процесса, это всегда определённый кратковременный (или не очень) коллапс в зоне его ответственности. Автоматизированный бизнес-процесс легко перенастроить, назначив нового сотрудника — и всей команде сразу будет понятно, кто за что отвечает. Опять же, коллапс будет, но минимально короткий и без последствий со стороны организации процесса.

Ускоренная адаптация сотрудников. Вообще, новые сотрудники сегодня и лет 10 назад разительно отличаются. Если раньше даже самый блистательный сотрудник первое время включался в работу и никак себя не проявлял, то сегодня можно встретить таких, которые в первый день демонстрируют активность. Конечно, чаще всего такая активность — головная боль всей команды, но и руки отбивать этим ребятам не хочется. Включение новичка в бизнес-процесс, который он может видеть, помогает ему максимально быстро адаптироваться, а заодно не выйти за рамки своей ответственности. Субординация соблюдена, проект как на ладони, коммуникации с коллегами очевидны — можно спокойно работать. Тут же раскрывается ещё одна ценность процессов — аккумуляция и трансляция бизнес-знаний.

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

Измеримость и оценка результата. Автоматизированные процессы накапливают море информации, могут измеряться (отчёты, KPI), журналируют информацию и всегда красноречиво демонстрируют, достигнут результат или нет. В случае, если вам кажется, что причиной неудачи послужила неоптимальная архитектура процесса, её всегда можно исправить, перенастроив параметры в редакторе процессов.

А что такое BPM-системы и какую выбрать?

BPM-системы — это как CRM, только BPM. Шутка. Это программное обеспечение для моделирования и работы бизнес-процессов. BPM-системы правда чем-то похожи на CRM-системы и относятся к классу корпоративного ПО. В интерфейсе такой системы создаются модели процессов (чаще всего с помощью нотации BPMN 2.0 или в нативном редакторе), появляется графическое и логическое представление, сохраняется на сервере, потом запускаются экземпляры процессов на десктопе или в web-браузере. Сама по себе BPM-система, в отличие от CRM или ERP, не может обеспечить сквозную автоматизацию бизнеса, поэтому нередко требует интеграций (часто у вендоров есть сразу несколько систем). В конечном итоге BPM-системы довольно дороги, сложны в управлении и в чистом виде нужны компаниям с ну очень сложными процессами (промышленность, гос. закупки, экспорт, наукоёмкие производства и т.д.). Откровенно говоря, лучше, чем на картинке ниже, и не расскажешь, они зачастую реально античеловечные и монструозные:

Но и без бизнес-процессов в компании любого уровня совсем плохо, поэтому вендоры CRM-систем не растерялись и включили модули для моделирования и управления процессами в свои системы. Мы не будем называть конкретные бренды, но прямо скажем — получилось это у всех с разной степенью успешности: кто-то втащил себе BPMN 2.0, кто-то взял элементы нотации и превратил её в совершенно убогий интерфейс, а у некоторых вышло очень даже хорошо, внятно и по-деловому. И это оптимальный вариант для большинства компаний — универсальное решение без трудностей интеграции и обмена данными.

Мы ввели бизнес-процессы еще в релизе RegionSoft CRM 5.0, собрали данные и отзывы, сами поработали в системе, поняли свои промахи, оценили достижения и в версии RegionSoft CRM 6.0 провели глубокий рефакторинг модуля бизнес-процессов, который перекочевал и в более поздние версии. Опыт показывает, что в нашем редакторе можно настраивать и запускать максимально сложные процессы.

Ну ок, система есть, что дальше, как проектировать бизнес-процессы?

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

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

1. Проанализируйте существующие процессы, вычлените главное, исключите лишнее и попробуйте набросать схему на бумаге. Небольшой лайфхак: если вы не знаете, как подступиться к этой процедуре, записывайте сами и попросите сотрудников записывать всё, что они делают в течение дня — таким образом можно будет выявить рутинные задачи и приступить к их формальному описанию.
2. Зафиксируйте цели процесса — обозначьте, зачем он нужен, какие задачи он решит и какую часть деятельности покроет. Подумайте, какие критерии успешного завершения у конкретного бизнес-процесса.
3. Составьте план процесса — шаги, ведущие к результату. Выделите крупные этапы и детальные вехи внутри этих этапов. Пропишите ответственных, примерные сроки и промежуточные результаты для каждого этапа.
4. Составьте на бумаге подробную схему со всеми параметрами, обсудите итоговый вариант с ответственными, внесите окончательные правки.
5. Создайте модель бизнес-процесса в CRM или BPM-системе, сохраните.
6. Запустите тестовый экземпляр процесса, прогоните его на тестовых данных, внесите исправления.
7. Запустите процесс в реальном рабочем режиме.
8. После того, как бизнес-процесс завершится, проанализируйте результат, ход, сроки, журналы процессов. При необходимости оптимизируйте модель.
9. Запускайте экземпляры бизнес-процессов по мере рабочей необходимости.
10. В случае изменений не бойтесь провести реинжиниринг всех существующих процессов.

Работая с бизнес-процессами, учтите пару важных моментов:

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

Когда начинать автоматизировать бизнес-процессы?

Ответ на этот вопрос лаконичный: сразу, даже если вы только что создали компанию. Давайте не будем лить воду, а посмотрим сразу на примере, какие процессы есть даже в самой молодой компании.

• Приём заказа покупателя и его обработка;
• Заказ товара у поставщиков; Работа с подрядчиками;
• Доставка заказа покупателю;
• Обработка обращения, сервис-деск, прием товара в гарантийный ремонт или сервис;
• Работа служб телемаркетинга и доведение клиента до сделки в холодных продажах;
• Согласование документов разными отделами или сотрудниками внутри компании;
• Процессы в информационных технологиях: ввод и обслуживание ПК, администрирование, инциденты и т.д.

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

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

Управление бизнес-процессами никогда не остаётся без эффекта. По данным исследования AIIM, компании, обратившиеся к BPM, получают до 41% роста ROI. 62% отмечают улучшение коммуникации между сотрудниками компании, 33% —  сокращение бюрократии и уровней согласования, 42% — большую организационную гибкость.

Внедрить и автоматизировать бизнес-процессы — это значит перестать решать бизнес-задачи как задачи и перейти на уровень управления по целям, работать на результат. Это значит больше свободы рук и голов от рутины и суеты, меньше конфликтов и корпоративных войн. Бизнес-процессы — это не фишка для избранных и великих, не прерогатива Газпрома или Росатома, это прозрачный, удобный и доступный всем рабочий инструмент, значительно улучшающий дела в компании. Так что, если у вас есть CRM (или планируется к внедрению), не игнорируйте возможности — пользуйтесь ими. Будьте уверены: спустя короткий промежуток времени вы будете говорить «Процесс пошёл» и с удовольствием запускать очередной его экземпляр.

Наш сайт с абсолютно десктопным ПО для бизнеса и нашей флагманской RegionSoft CRM.

Наш пока живой Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь.

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

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

Что такое бизнес-логика?

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

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

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

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

Как результат данные обновляются и в списке появляется новый пассажир.

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

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

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

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

Бизнес-процессы в AppMaster.io

Как и при классическом подходе, в AppMaster.io бизнес-логика строится из бизнес-процессов. БП предназначены для работы с данными: поиск, создание, удаление, обновление, изменение и отвечают за выполнение любых действий в приложении.

На платформе есть специальный редактор для работы с бизнес-процессами. Для создания БП используются блоки.

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

У каждого блока БП, за исключением блоков start и end, есть два типа коннекторов — точек подключения (входные In, выходные Out):

Бизнес-процессы делятся на три категории:

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

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

В веб и мобильных приложениях существуют следующие типы БП:

Как создать бизнес-процесс на AppMaster.io?

Для работы с бизнес-процессами на платформе AppMaster.io существует редактор бизнес-процессов.

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

Редактор БП состоит из:

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

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

На левой панели блоки распределены в группы по видам:

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

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

Чтобы добавить переменные, необходимо выделить нужный блок бизнес-процесса и нажать на иконку плюс на панели Variables.

Различают локальные и глобальные переменные.

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

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

Локальные и глобальные переменные могут иметь любой тип: от простых int и string, до массивов моделей и энамов. Хранятся исключительно в оперативной памяти.

Пример бизнес-процесса

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

*Все данные уже были введены в базу данных. Ниже описано только создание бизнес-процесса. Полный урок доступен тут.

Чтобы создать новый процесс, перейдите в раздел Business Logic и нажмите на Create business process.

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

По умолчанию в нашем БП уже есть два блока: Start и End.

В блок Start мы добавляем несколько выходных переменных. Для этого кликните на нужный блок и в правой части экрана напротив Variables нажмите иконку +.

В новом окне введите название переменной, укажите ее тип и задайте дефолтное значение, если необходимо.

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

Далее нам нужно получить ID рейса из базы данных. Для этого мы добавляем блок GetOneFlight.

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

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

Добавляем блок Expand Passenger и получаем ID пассажира. При помощи блока GetOne Passenger проверяем запись о нем в базе данных.

Теперь нам нужно создать саму регистрацию. Для этого используем блок Make Registration. Устанавливаем связи между блоками.

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

Созданный бизнес-процесс отвечает за выполнение следующих действий: поиск данных о рейсе в базе данных, поиск и получение ID пассажира, создание и сохранение регистрации.

На нашем YouTube-канале вы можете пройти полный курс AppMaster.io 101 и научиться работать с no-code платформой. Так легко и наглядно при помощи блоков и визуальных связей на платформе AppMaster.io можно собирать бизнес-процессы любой сложности без написания кода. Попробуйте создать свой бизнес-процесс и приложение, зарегистрировавшись на пробный период на платформе.

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Бизнес-процесс

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

Карта маршрута

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

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

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

Точка действия

Точки этого вида описывают отдельную операцию (единицу работы), соответствующую определенному этапу (шагу) в жизненном цикле бизнес-процесса:

Точка действия содержит информацию кто и что должен сделать на данном этапе, например:

• бухгалтер — принять оплату наличными;
• кладовщик — выдать товар со склада по накладной;
• системный администратор — зарегистрировать нового сотрудника в сети и электронной почте.

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

Групповая и коллективная маршрутизация

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

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

Персональная и ролевая маршрутизация

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

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

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

Условная маршрутизация

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

Условная маршрутизация обеспечивается точками маршрута двух видов:

• условный переход;
• выбор варианта.

Условный переход предоставляет возможность выбора одного из двух возможных вариантов дальнейшего маршрута (да/нет, больше/меньше, запрещено/разрешено и т. д.):

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

Использование в прикладных решениях

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

Автоматизация бизнес процессов в CRM. Сравнение подходов +10

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

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

И сейчас я хочу рассказать о двух разных подходах решения этих вопросах, которые в той или иной степени реализованы во всех популярных CRM.

1. Программирование бизнес-процессов.
2. «Рисование» бизнес-процессов.

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

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

Этот метод применяется в таких популярных системах, как ZOHO CRM или Saleforce CRM, и заключается в реализации бизнес-процесса по технологии Step by Step, т.е. «шаг за шагом».

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

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

Приведем пример из ZOHO CRM. Здесь имеются два основных вида объектов:

• Workflow позволяет задать то или иное действие в зависимости от различных полей.
• Approval process задает те или иные процессы согласования. Мы можем добавить несколько таких процессов, и они будут работать следующим образом. Для каждого процесса мы можем указать, когда он работает, кто его одобряет. И, соответственно, система будет контролировать работу процессов.

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

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

Об этом подходе можно сказать, что описание алгоритма реализуется текстовым способом. Например, если мы возьмем в ZOHO CRM определенный Provel process, то для него нужно будет указать:

1. Критерий, когда он работает.
2. Кто должен его одобрить.
3. Какое действие нужно выполнить после одобрения, например, создать задачу или отправить оповещение внутри системы, отправить sms и пр.
4. Что должно происходить, если процесс не был одобрен, например, ничего не предпринимать, вернуть задачу исполнителю на доработку с комментариями и т.д.

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

Рисование бизнес-процессов

Такой подход реализован, например, в Bitrix24 CRM и в 1С CRM. Здесь все бизнес-процессы нужно рисовать в определенном внутреннем формате этих систем. Так, в Bitrix24 есть собственное понятие «Бизнес-процессы», а внутри этого раздела имеется нотация, в которой нужно рисовать бизнес-процессы.

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

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

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

Плюсы и минусы подходов

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

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

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

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

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

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

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

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

С уважением, Кинзябулатов Рамиль.

Что такое бизнес-процессы в 1С

Безотносительно 1С бизнес-процесс – это совокупность взаимосвязанных действий, направленных на создание продукта или услуги для потребителей.

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

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

Объект «Бизнес-процесс» имеет графическое отображение, называемое картой маршрута. Это не что иное, как блок-схема, составленная из «кирпичиков»:

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

Вот пример бизнес-процесса «Закрытие месяца» из 1С:УПП, где встречаются практически все возможные элементы:

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

Использование объектов «Бизнес-процесс» для пользователя похоже на работу с документами:

• Разные бизнес-процессы соответствуют различным действиям в системе (продажа товара, закрытие месяца, согласование заказа, …). То есть объект «Бизнес-процесс» в конфигурации определяет вид операции.
• При старте пользователем нового бизнес-процесса создается несколько экземпляров, например – продажа вентиляторов контрагенту А, продажа холодильников контрагенту Б и так далее. То есть пользователь создает любое количество объектов информационной базы для каждого бизнес-процесса.

Практический пример

Рассмотрим практический пример. Необходимо автоматизировать процесс приема сотрудника на работу из 3 последовательных этапов:

1. Младший кадровик заполняет личные данные сотрудника.
2. Старший кадровик оформляет приказ о приеме сотрудника в статусе «Проект».
3. Расчетчик проводит приказ о приеме в статусе «Утвержден».

Каждый этап бизнес-процесса выполняет отдельный пользователь с нужными правами доступа.

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

В реальных задачах также нужно учитывать права доступа. Так, в описанной задаче за утверждение документов «Прием на работу» отвечает расчетчик. А при проведении документа в статусе «Утвержден» формируются движения по регистру сведений «Плановые начисления». То есть расчетчик должен иметь право записи в этот регистр.

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

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

Начнем с создания нового бизнес-процесса:

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

Изобразим карту маршрута бизнес-процесса для поставленной задачи:

Привязку к исполнителям мы настроим позднее.

В точке условия нужно определить, работал ли принимаемый сотрудник в нашей организации ранее. Если это так, то в базе уже заведен нужный элемент справочника «Физические лица» и заполнены личные данные. Добавим в бизнес-процесс реквизит (тип Булево), который позже обработаем в точке условия (то есть считаем, что пользователь сам определяет при приеме – новый это сотрудник или нет):

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

Объект конфигурации «Задача»

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

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

Для наглядности рассмотрим, как выглядит список задач в демонстрационной базе конфигурации «Документооборот 8 ПРОФ, редакция 2.1». При запуске программы от имени пользователя Федоров О.П. (директор) на начальной странице открывается список всех невыполненных задач пользователя:

Вернемся к нашей конфигурации, создадим новый объект:

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

Свяжем бизнес-процесс с задачей:

Обратите внимание! Несмотря на то, что в разных точках бизнес-процесса могут создаваться и редактироваться различные объекты системы, тип создаваемых задач на каждом из этапов будет одинаковым. Например, для решаемой задачи будут создаваться элементы справочников “Физические лица” и “Сотрудники”, а также документы “Прием на работу”. При этом в каждой точке бизнес-процесса будут создаваться задачи “Задача исполнителя”.

Более того, в типовых решениях 1С («Документооборот», «Управление торговлей, ред. 11») в разных бизнес-процессах используется один и тот же тип задач, чаще всего он называется «Задача исполнителя». Это делается для того, чтобы пользователь мог видеть общий список своих задач, относящихся к разным видам бизнес-процессов, как в примере выше из «Документооборота».

Адресация задач

Объект «Задача» предоставляет возможность использования вспомогательного регистра сведений, который обеспечивает распределение задач по исполнителям. Этот регистр называется регистром адресации.

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

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

Поэтому для нашего примера создадим в регистре адресации 2 измерения:

Здесь используется справочник «Роли исполнителей», который имеет следующие предопределенные элементы:

Создадим у задачи реквизиты адресации тех же типов, что и измерения регистра сведений:

Укажем для задачи регистр адресации. Для реквизитов адресации задачи настроим соответствие измерениям выбранного регистра сведений:

Теперь в карте маршрута бизнес-процесса доступна настройка адресации. Укажем для каждой точки действия нужную роль исполнителя:

Чтобы обеспечить ветвление в точке условия, требуется обработчик проверки условия – функция в модуле объекта бизнес-процесса, которая возвращает значение Ложь или Истина. Создадим такой обработчик для точки маршрута ПовторныйПрием:

Процедура ПовторныйПриемПроверкаУсловия(ТочкаМаршрутаБизнесПроцесса, Результат)
  	Результат = Не ЭтоПервичныйПрием;
КонецПроцедуры

Чтобы знать, от имени какого пользователя запущен текущий сеанс, нам потребуется параметр сеанса. Создадим его:

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

Сделаем так, чтобы при запуске «1С:Предприятия» в параметр сеанса ТекущийПользователь подбиралось нужное значение из справочника «Пользователи». Соответствие будем устанавливать по имени, и если элемент справочника «Пользователи» с нужным именем не найден, то создадим его. Код функции УстановкаПараметровСеанса() в модуле сеанса:

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
  	ИмяПольз = ИмяПользователя();
  	ТекПользователь = Справочники.Пользователи.НайтиПоНаименованию(ИмяПольз, Истина);
  	Если Не ЗначениеЗаполнено(ТекПользователь) Тогда
        	НовыйПользователь = Справочники.Пользователи.СоздатьЭлемент();
        	НовыйПользователь.Наименование = ИмяПольз;
        	НовыйПользователь.Код = ИмяПольз;
        	НовыйПользователь.Записать();
        	ТекПользователь = НовыйПользователь.Ссылка;
  	КонецЕсли;                                       	
  	ПараметрыСеанса.ТекущийПользователь = ТекПользователь;
КонецПроцедуры

После того, как все нужные элементы справочника «Пользователи» будут созданы, заполним регистр адресации в режиме «1С:Предприятие»:

Обратите внимание! Настройка адресации бизнес-процесса с использованием справочника (в нашем случае это справочник «Роли исполнителей») подразумевает использование предопределенных элементов этого справочника, только они доступны для выбора в точке действия бизнес-процесса.

Отображение задач по исполнителям

Теперь поработаем над формой списка задач. Конечно, пользователю хотелось бы, чтобы по умолчанию в списке задач отображались только его задачи. Для этого создадим форму списка задачи «Задача исполнителя» и в настройках основного реквизита Список поменяем основную таблицу на Задача.ЗадачаИсполнителя.ЗадачиПоИсполнителю:

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

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

После этого у пользователя Петрова В.П. в списке задач (Кадровый учет → Задача исполнителя) появится новая задача:

Визуализация хода бизнес-процесса

Пока функциональность нашей разработки почти на нуле – только формируются задачи и пользователи вручную отмечают их исполнение.

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

Затем в модуле формы бизнес-процесса создадим процедуру ОбновитьКартуМаршрута:

&НаСервере
Процедура ОбновитьКартуМаршрута()
    ОбъектБП = РеквизитФормыВЗначение("Объект");
    КартаБП = ОбъектБП.ПолучитьКартуМаршрута();    
КонецПроцедуры

Вызовем эту процедуру в обработчике события ПриЧтенииНаСервере формы бизнес-процесса:

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
   ОбновитьКартуМаршрута();
КонецПроцедуры

После этого при открытии формы бизнес-процесса на карте маршрута будет отмечаться текущее положение:

Сделаем так, чтобы при нажатии кнопки «Старт» на форме бизнес-процесса карта маршрута обновлялась. Для этого вызовем ту же процедуру ОбновитьКартуМаршрута в обработчике ПослеЗаписиНаСервере:

&НаСервере
Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
    ОбновитьКартуМаршрута();
КонецПроцедуры

В таком виде задача может считаться решенной в рамках подготовки к экзамену «1С:Специалист» по платформе. Но мы пойдем немного дальше.

События задач и точек действия бизнес-процессов

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

Итак, добавим в модуль объекта ЗадачаИсполнителя стандартный обработчик ПередВыполнением со следующим кодом:

Процедура ПередВыполнением(Отказ)
  	Исполнитель = ПараметрыСеанса.ТекущийПользователь;
КонецПроцедуры

Теперь добавим в бизнес-процесс реквизиты, которые позволят хранить информацию о выполняемых действиях:

Поработаем и с задачей. Выведем на форму задачи ссылку на родительский бизнес-процесс и его реквизиты:

В наименовании задачи было бы неплохо видеть не только название точки маршрута, но и ФИО человека, которого требуется принять на работу. Для этого в модуле объекта бизнес-процесса определим процедуру УстановитьНаименованиеЗадачи, и будем вызывать ее при создании задач:

Процедура УстановитьНаименованиеЗадачи(ТочкаМаршрутаБизнесПроцесса, Задача)
Задача.Наименование = ТочкаМаршрутаБизнесПроцесса.НаименованиеЗадачи + " " + СокрЛП(ФизЛицо.Наименование);
КонецПроцедуры
 
Процедура ОбщаяПриСозданииЗадач(ТочкаМаршрутаБизнесПроцесса, ФормируемыеЗадачи, Отказ)
  	Для каждого НоваяЗадача Из ФормируемыеЗадачи Цикл
        	УстановитьНаименованиеЗадачи(ТочкаМаршрутаБизнесПроцесса, НоваяЗадача);
  	КонецЦикла;
КонецПроцедуры

Процедуру ОбщаяПриСозданииЗадач привяжем к каждой точке маршрута бизнес-процесса. Это можно сделать через карту маршрута:

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

Функция ПроверитьВыполнениеЗадачи(ТочкаМаршрутаБизнесПроцесса, Задача)
    
    БП = Задача.БизнесПроцесс;
    Результат = Ложь;
Если ТочкаМаршрутаБизнесПроцесса = БизнесПроцессы.ПриемНовогоСотрудника.ТочкиМаршрута.ВводПервичныхДанныхФизлица Тогда
   	 Если ЗначениеЗаполнено(БП.ФизЛицо) И ЗначениеЗаполнено(БП.Сотрудник) Тогда
   		 Результат = ЗначениеЗаполнено(БП.ФизЛицо.ДатаРождения) И ЗначениеЗаполнено(БП.ФизЛицо.Пол);
   	 КонецЕсли;
    ИначеЕсли ТочкаМаршрутаБизнесПроцесса = БизнесПроцессы.ПриемНовогоСотрудника.ТочкиМаршрута.ВводПриемаНаРаботу Тогда
   	 Результат = ЗначениеЗаполнено(БП.ПриемНаРаботу);
    ИначеЕсли ТочкаМаршрутаБизнесПроцесса = БизнесПроцессы.ПриемНовогоСотрудника.ТочкиМаршрута.УтверждениеПриемаНаРаботу Тогда
   	 ДокПрием = БП.ПриемНаРаботу;
   	 Результат = ЗначениеЗаполнено(ДокПрием.Оклад) И ДокПрием.Статус = Перечисления.СтатусыДокументов.Утвержден;
    КонецЕсли;
    
    Возврат Результат;
    
КонецФункции

Процедура ОбщаяПередВыполнением(ТочкаМаршрутаБизнесПроцесса, Задача, Отказ)
    Если Не ПроверитьВыполнениеЗадачи(ТочкаМаршрутаБизнесПроцесса, Задача) Тогда
   	 Сообщить("Не выполнены действия, необходимые для выполнения задачи!", СтатусСообщения.Важное);
   	 Отказ = Истина;
    КонецЕсли;
КонецПроцедуры

Готово, можно тестировать!

Подведем итоги

Мы описали только базовые приемы работы с бизнес-процессами и задачами в 1С:Предприятии 8.3. Как минимум, требуется добавить еще множество проверок введенных данных и «красивостей» на уровне форм.

Но цель статьи – показать, как можно использовать объекты системы при автоматизации бизнес-процессов.

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

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

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

Об авторе

Выгрузки ИБ и PDF-версия статьи для участников группы ВКонтакте

Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.

Если Вы еще не вступили в нее – сделайте это сейчас, и в блоке ниже (на этой странице) появятся ссылки на скачивание материалов.