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