Кроме шуток, речь пойдет о том, как автоматизировать бизнес-процессы минимальным набором инструментов. Будет интересно тем, кто сталкивался с автоматизацией, внедрял ее в своей компании или знаком с темой со стороны разработчиков. А нам будет полезна ваша критика, потому что как раз сейчас мы в поиске оптимального способа реализовать эту концепцию. Также ищем веб и мобайл разработчиков, об этом подробнее в конце.
Самый популярный способ автоматизировать бизнес-процессы
Обычно бизнес-процессы представляют вот такими схемами в стиле BPMN:
BPMN схема из ВикипедииБольшинство процессов состоят из одних и тех же действий:
-
загрузка документа (или заполнение по готовой форме)
-
проход документа по цепочке сотрудников (которые либо вносят в него какую-то информацию, либо согласуют, либо просто уведомляются)
-
условия (определяют дальнейший ход процесса)
и т. д.
Поэтому, сделав несколько проектов по автоматизации, у разработчиков появляется желание автоматизировать саму работу по автоматизации - создать конструктор бизнес-процессов, в котором заказчик сам сможет нарисовать схему своего бизнес процесса и получить готовую программу, в которой этот процесс можно организовать. И так как большинство задач формулируется на языке BPMN, часто создание конструктора начинается с редактора BPMN схем. Для этого уже есть готовые движки, позволяющие не только рисовать схемы, но и конвертировать их в код и запускать его, вызывая нужные процедуры в порядке,описанном в схеме.
Редакторы BPMN (и похожих на BPMN) схем реализованы во многих продуктах. Например: Тезис, ELMA, Bitrix. И это неплохой подход, который не хочется даже критиковать, но раз уж будем рассматривать альтернативы, нужно обозначить его недостатки:
-
Рисовать схемы надо уметь. Просто рисовать схемы для людей и рисовать схемы, которые автоматом превращаются в ПО - не одно и то же. Заказчику для этого нужен компетентный специалист.
-
Схема описывает логику работы, но не описывает интерфейсы. Как это будет выглядеть глазами пользователя? Обычно для этого используют заранее подготовленные интерфейсы для разных видов задач (один - для загрузки документов, другой - для согласования, третий - для уведомления пользователей).
-
Схема описывает процесс, но не описывает содержимое документов. Для них нужен еще один редактор - конструктор форм. Причем само содержимое документов может влиять и на ход процесса (например, документ Заявка на оплату содержит поле Сумма, заявки с маленькой суммой согласует менеджер, а большие обязательно проходят через финдиректора).
В итоге, порог вхождения оказывается настолько высоким, что многие процессы проще организовать пересылкой документов по электронной почте. Ну и ведя реестр в экселе для порядку. Это не критика самой BPMN нотации. Часто без нее просто не обойтись. Вопрос вообще не в нотации, а в предлагаемом заказчику продукте. Кажется, для многих задач можно обойтись более простыми инструментами.
Альтернативный подход
Проблематика понятна, что же мы предлагаем?
Идея звучит так: почти любой бизнес-процесс можно организовать с помощью пары настраиваемых интерфейсов: таблицы и формы документа.
А выглядит так:
Рассмотрим на примере простого процесса согласования:
-
менеджер проекта может подать заявку на расходы (надо ему купить что-то для проекта)
-
заявку должен согласовать начальник отдела
-
затем одобрить финансовый директор
-
затем бухгалтер отправляет оплату в банк
-
и после того, как контрагент подтверждает оплату, менеджер закрывает вопрос
Таких заявок может быть много. И вот заказчик кое-как описал бизнес-процесс и попросил нас автоматизировать работу. Что ж, приступим. Начнем с формы документа, которую можно наполнять компонентами (которые, в свою очередь, тоже имеют возможность настройки).
Заказчик нам говорит, что заявка на оплату это такая штука, у которой есть название, описание и сумма. С его слов будем наполнять нашу форму компонентами:
Основной компонент для организации работы здесь - Статусы. По сути это выпадающий список, с настройками кто из какого и в какой статус может перевести. Смотря на бизнес процесс, понимаем, что заявка проходит несколько этапов:
-
открыто
-
согласовано начальником отдела
-
согласовано финдиректором
-
оплачено
-
закрыто
Причем каждый сотрудник может перевести заявку только в определенные статусы, это указано в настройках правил Статусов.
В каком то смысле, в компоненте статусы мы описали бизнес-процесс. После формы создания заявки столбцы таблицы подстраивается под тот же набор компонентов, и можно начинать работать. То есть, создавая заявку, мы описали и таблицу. Теперь по настроенной форме можем создавать заявки и заполнять значениями.
Итак, менеджер создал заявку, и она попала в таблицу, которую пока все видят одинаково. Начальник отдела видит заявку в статусе Открыто, открывает ее, при необходимости может написать что-то в комментариях и переводит в статус Согласовано начальником отдела. На заявки с таким статусом обращает внимание Финдиректор, открывает и переводит в статус Согласовано финдиректором. Ну и аналогично бухгалтер переводит в статус Оплачено, и в конце концов менеджер в Закрыто. Все изменения и комментарии сохраняются в истории. Вот так это выглядит на разных этапах работы:
Когда заявок станет слишком много, простота обернется хаосом. Тут-то и понадобятся возможности настройки таблицы под каждого участника. Для этого можно использовать стандартные возможности фильтрации, сортировки и группировки. И если фильтрация и сортировка всем и так знакома хотя бы по икселю, то автоматическую группировку можно описать так: она объединяет строки с одинаковыми значениями по определенному столбцу и может быть многоуровневой. Ниже на картинках варианты настройки для разных участников.
Менеджеру проекта интересно видеть только свои заявки - фильтруем по столбцу Инициатор и группируем по Статусу. Тогда создаваемые им заявки будут попадать в группу Открыто, и в процессе работы он будет наблюдать, как они перемещаются в группу Согласовано начальником отдела, затем в Согласовано финдиректором и так далее:
Директору интересна общая картина, какие заявки в каком статусе и в каком отделе - делаем двухуровневую группировку по Начальнику отдела и Статусу:
Бухгалтеру вообще ничего не интересно, он просто хочет видеть какие заявки надо оплатить. Фильтруем только статус Согласовано финдиректором:
Так выглядит общая логика организации согласований. Дальнейшее развитие во многом будет заключаться в создании компонентов. Например, только что мы сделали статусы с помощью выпадающего списка, потому что у нас был известен последовательный порядок перевода статусов. Для параллельного согласования можно сделать чекбоксы, а интерфейс бухгалтера настроить фильтрами так, чтобы в него попадали только заявки с двумя отмеченными чекбоксами.
Если понадобится создать бумажный эквивалент заявки, можем сделать компонент, заполняющий вордовский шаблон. Например, вот так: у нас в карточке уже есть названия полей, можем указать их в шаблоне, так чтобы, когда пользователь нажмет кнопку, скрипт сделает автозамену по каждому полю и сформированная версия документа прикрепится к карточке.
В общем, если бы Ален Карр знал об этом методе, то написал бы о нем книгу, которая, наверняка, стала бы бестселлером)
Осталось еще рассказать про ссылки пару моментов. Первое - у каждого документа в таблице есть свой URL, который можно отправить коллегам, например, в мессенджер или мейл. Кроме того, в карточке одни документы могут содержать ссылки на другие, обеспечивая связи между ними. Связанные документы тоже можно выводить в отдельный столбец таблицы и использовать их для организации работы, но не буду углубляться в примеры, чтобы пока не отвлекаться от основной идеи.
Лирическое отступление. Когда не было икселя и компьютеров, чтобы организовать согласование, придумывали форму документа (акта, обходного листа), в котором содержалась логика процесса (инициатор, сроки, список и порядок согласующих, текущее состояние, визы и комментарии). Это очень простой способ, который можно улучшить современными технологиями.
Что дальше
Конечно, в процессе работы изначальная простота обрастет справочниками, отчетами, ролями, но все это должно уложиться в общую логику. Возможности работы с информацией в таблицах знакомы многим пользователям, а группировка может также заменить раскладывание документов по папкам, давая, при этом, возможность более гибко настроить структуру.
И да, все эти решения не новы, наверняка многие увидели знакомые приемы из CRMок и таск-трекеров (Jira, Redmine), чем-то это похоже и на Airtable, Notion, Planfix, и даже на Unity 3D (там тоже каждый игровой объект является набором компонентов, которые определяют его поведение). Но в приложениях, автоматизирующих процессы промышленных компаний, примеров не много.
Сейчас у нас в разработке несколько IT-продуктов (стек: Java, MongoDB, React) и мы в поиске разработчиков. Если вы знаете таких спецов, поделитесь с ними ссылкой. Если есть идеи, как это лучше реализовать, поделитесь мыслями. Если же видите слабые места этого подхода, я (тот, кто продвигает идею в нашей компании) открыт к критике и обсуждениям. Для связи - комменты и телега @planer484.