Сколько нужно разработчиков, чтобы создать бизнес-процесс?
Недавно я столкнулась с ситуацией: есть задача, нет подходящего инструмента, разработчики заняты, бюджет ограничен, а время поджимает. Мне нужно было выстроить процесс оценки уровня удовлетворенности пользователей. В бизнесе много похожих небольших задач, которым часто присваивают низкий приоритет, поэтому они долго остаются в очереди на разработку. Хотя их решение значительно упрощает работу отдельных сотрудников и даже целых отделов.
Поскольку мы разрабатываем собственную Low‑Code BPM платформу и рассказываем клиентам, что около 70% бизнес‑задач решается No‑Code инструментами, 20–25% — Low‑Code, и лишь 5–10% требуют написания кода, то я решила попробовать самостоятельно собрать «Оценку качества» на нашей же платформе, не прибегая к помощи разработчиков. Меня зовут Ирина Головина, я руководитель группы технической поддержки Citeck. Сегодня расскажу, как я это делала, что у меня получилось и не получилось. Материал будет полезен всем, кто интересуется возможностями No‑Code платформ или ищет способ автоматизировать свои процессы.
Предыстория
В 2023 году после ухода Jira, которую мы активно использовали, пришлось срочно искать замену Service Desk. По ряду причин мы так и не выбрали готовый продукт, поэтому сделали свой модуль. С нашей стороны все получилось отлично: мы принимали обращения, распределяли их внутри команды, следили за статусами на канбан‑доске, контролировали SLA и так далее. Со стороны клиентов удобства было меньше: так как они отправляли заявки на почту техподдержки, то не могли быстро отслеживать статусы обращений и видеть их общее количество. Мы это исправили — теперь клиенты могут к нам обращаться через внешний безопасный портал и видеть все нужные данные (предвосхищая вопросы — это копия основного экземпляра, которая содержит минимальные данные: только те, что нужны для коммуникации).
Специфика работы группы техподдержки — это постоянная многозадачность. Мы и психологи, и менеджеры, и тестировщики, и аналитики, и вообще восьмирукие семиноги. Нам приходится непрерывно оптимизировать и улучшать процессы, искать способы ускорения обработки инцидентов и повышать качество услуг.
И вот, в очередной раз анализируя нашу работу, я поняла: у нас есть серьезный пробел — отсутствие структурированной обратной связи. Она была разбросана по разным каналам в виде отдельных сообщений и обрывков коммуникаций. Такое информационное месиво невозможно проанализировать. Вывод напрашивался сам собой — нужен процесс, который соберет все данные в единую систему. Тогда мы сможем четко понимать, что исправить, что оставить, что убрать и что развивать.
На тот момент у команды разработки не было ресурсов, чтобы взяться за мою задачу. Поэтому я решила попробовать создать процесс самостоятельно, используя нашу платформу и ее No‑Code возможности. Если вы захотите повторить мои действия или попробовать создать собственный процесс, то скачайте бесплатную Community‑версию. У Citeck открытый исходный код, с которым вы можете ознакомиться, и полная документация, поэтому вы можете гибко использовать платформу для своих задач. Также существует Enterprise‑версия Citeck для крупного бизнеса — в ней реализованы дополнительные возможности для такого типа заказчиков.
Подготовительный этап
Подготовительный этап вас не удивит — сбор требований, аналитика, формирование BRD. Поскольку я сама себе заказчик и аналитик, то никакого недопонимания не возникло))) BRD набросала быстро, документ включал такие пункты, как цели, методы, роли, этапы процесса и требования к журналу.
Дальше нужно было решить, где все это создавать и тестировать. Варианта два — взять готовый тестовый стенд или развернуть новый. Мне было проще взять готовый тестовый стенд, так как там уже внесены данные и заведены пользователи. Если вы будете повторять мой путь, то понадобится развернуть локальный стенд (как это сделать — см. документацию).
Первые шаги
Открываем раздел администратора, заходим в журнал «Типы данных», открываем форму создания нового типа.
Чтобы создать процесс, нам нужно:
Создать тип данных (не забываем про атрибуты, статусы и роли).
Создать форму (можно оставить по умолчанию или сделать свою) — внешний вид и наполнение будущей заявки. Забегая вперед — потом мы создадим еще ряд форм, соответствующих стадиям процесса.
Создать журнал (можно оставить по умолчанию или сделать свой) — тут будет отображаться вся история работ по оценке качества услуг, то есть все заявки с их статусами.
Создать процесс (построить схему в визуальном BPMN-редакторе).
Здесь все интуитивно понятно, но если что — всегда можно почитать документацию и найти ответ на свой вопрос.
Журнал и форму мы можем оставить по умолчанию — они сгенерируются автоматически, будут содержать только необходимую информацию и стандартное расположение элементов. Такой журнал мне подойдет, а вот форму нужно изменить, поэтому я создаю новую в No‑Code редакторе. Атрибуты, статусы, роли и стадии заполняем согласно нашему BRD. Остальные вкладки оставляем без изменений. Нажимаем «Сохранить» и получаем:
новый тип данных с прописанными атрибутами, роли, плюс статусы, по которым будет перемещаться заявка,
автоматически сгенерированный журнал,
кастомизированную форму заявки.
3 из 4 пунктов! Отлично! Все в одном окне и самостоятельно, без помощи разработчика.
Итак, можно посмотреть что у нас получилось. Переходим в созданный журнал, нажимаем кнопку «Создать» (обозначена символом +), далее открывается форма создания заявки.
На данном этапе в разделе «Инструменты администратора» мы можем создать формы для каждого статуса процесса — пока у нас заведена только одна, стартовая. Есть возможность создать и редактировать формы позже, на этапе работы в BPMN‑редакторе.
Создание схемы бизнес-процесса
Для этого вновь заходим в раздел администратора, далее в журнал модели BPMN, затем открываем форму создания процесса. Заполняем поля, сохраняем и приступаем к описанию схемы. Я не буду подробно останавливаться на этом пункте, скажу только, что Citeck обладает собственной BPM‑системой, она основана на библиотеке редактора bpmn‑js и движка Camunda, но адаптирована под No‑Code/Low‑Code возможности платформы.
Пожалуй, это была самая интересная часть работы: я прописала поэтапно все условия переходов со статуса на статус, добавила отправку уведомлений, описала движение заявки в зависимости от выбора того или иного вердикта. Здесь же указываются исполнители, сроки выполнения задачи и прочее.
Первый запуск и выявление недочетов
Публикуем процесс и смотрим, что у нас получилось. Для этого создаем заявку, прогоняем по процессу и видим первые ошибки.
В некоторых случаях обязательные поля таковыми не являются, что тоже нужно учесть на схеме бизнес-процесса:
Действия я добавила самостоятельно, читая документацию. Проблему с обязательностью заполнения поля в зависимости от выбранного вердикта решить у меня не вышло. Здесь все‑таки пришлось просить коллегу из разработки мне помочь. Справедливости ради отмечу, что это не было обязательным, по сути процесс уже является рабочим. Но мне хотелось сделать его максимально удобным, поэтому я повысила требования.
Тестирование
Здесь пробежалась по верхам (напомню, я не тестировщик) — проверила на соответствие своим же требованиям: заполнение форм, статусную и ролевую модели. Пришлось подключить немного творчества и фантазии, чтобы придумать, как может действовать пользователь, который впервые видит процесс. Для меня это оказалось непросто, поскольку я слишком хорошо представляла, как должно быть. В этом случае можно попросить коллегу пробежаться свежим взглядом.
Итоги
За короткое время (около полутора‑двух рабочих дней) мне удалось создать простой рабочий процесс на No‑Code. Самостоятельно получилось не все: поскольку я хотела получить более сложный процесс, чем был предусмотрен в No‑Code, я привлекала коллегу‑разработчика, который использовал Low‑Code.
В процессе работы мои требования несколько раз менялись и дополнялись, в основном, после первых тестов. Что‑то оказалось неудобным, чего‑то не хватало, где‑то всплывали ошибки. Именно тогда я оценила возможность быстро вносить изменения: исправлять недочеты, убирать лишнее и добавлять недостающие элементы буквально на ходу.
Вердикт: простые задачи можно реализовать быстро и без привлечения большой команды.
Спасибо за внимание, готова отвечать на ваши вопросы в комментариях. Буду рада, если кто‑то из читателей сможет с пользой применять Community‑версию платформы Citeck в своих целях, а если возникнут трудности — ждем вас в Телеграм‑канале, где наша команда помогает разобраться со сложными нюансами при использовании платформы.
