Легкий способ автоматизировать бизнес-процессы, о котором не знает Аллен Карр

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

    Самый популярный способ автоматизировать бизнес-процессы

    Обычно бизнес-процессы представляют вот такими схемами в стиле BPMN:

    BPMN схема из Википедии
    BPMN схема из Википедии

    Большинство процессов состоят из одних и тех же действий: 

    • загрузка документа (или заполнение по готовой форме)

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

    • условия (определяют дальнейший ход процесса)
      и т. д.

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

    Редакторы BPMN (и похожих на BPMN) схем реализованы во многих продуктах. Например: Тезис, ELMA, Bitrix. И это неплохой подход, который не хочется даже критиковать, но раз уж будем рассматривать альтернативы, нужно обозначить его недостатки: 

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

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

    3. Схема описывает процесс, но не описывает содержимое документов. Для них нужен еще один редактор - конструктор форм. Причем само содержимое документов может влиять и на ход процесса (например, документ “Заявка на оплату” содержит поле “Сумма”, заявки с маленькой суммой согласует менеджер, а большие обязательно проходят через финдиректора).

    В итоге, порог вхождения оказывается настолько высоким, что многие процессы проще организовать пересылкой документов по электронной почте. Ну и ведя реестр в экселе “для порядку”. Это не критика самой BPMN нотации. Часто без нее просто не обойтись. Вопрос вообще не в нотации, а в предлагаемом заказчику продукте. Кажется, для многих задач можно обойтись более простыми инструментами. 

    Альтернативный подход

    Проблематика понятна, что же мы предлагаем? 

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

    А выглядит так:

    Рассмотрим на примере простого процесса согласования: 

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

    2. заявку должен согласовать начальник отдела

    3. затем одобрить финансовый директор

    4. затем бухгалтер отправляет оплату в банк

    5. и после того, как контрагент подтверждает оплату, менеджер закрывает вопрос

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

    Заказчик нам говорит, что заявка на оплату это такая штука, у которой есть название, описание и сумма. С его слов будем наполнять нашу форму компонентами:

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

    • открыто

    • согласовано начальником отдела

    • согласовано финдиректором

    • оплачено

    • закрыто

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

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

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

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

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

    Директору интересна общая картина, какие заявки в каком статусе и в каком отделе - делаем двухуровневую группировку по Начальнику отдела и Статусу:

    Бухгалтеру вообще ничего не интересно, он просто хочет видеть какие заявки надо оплатить. Фильтруем только статус “Согласовано финдиректором”:

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

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

    В общем, если бы Ален Карр знал об этом методе, то написал бы о нем книгу, которая, наверняка, стала бы бестселлером)

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

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

    Что дальше

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

    И да, все эти решения не новы, наверняка многие увидели знакомые приемы из CRMок и таск-трекеров (Jira, Redmine), чем-то это похоже и на Airtable, Notion, Planfix, и даже на Unity 3D (там тоже каждый игровой объект является набором компонентов, которые определяют его поведение). Но в приложениях, автоматизирующих процессы промышленных компаний, примеров не много. 

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

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 24

      0
      Комментарий для затравки)
        0

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


        PS: Кстати как это получается https://habr.com/ru/company/lanit/blog/549108/ — неделя электронного документооборота на Хабре?

          0
          Частично ответил в этом комментарии: habr.com/ru/post/548544/#comment_22891150

          Excel действительно многое позволяет реализовать, не раз видел, как заказчику, не умеющему (или не желающему) в нем работать продают почти то же самое за гораздо большие деньги. И если посмотреть, как автоматизируют свою работу IT компании и производственные, то первый часто пользуются какими-то конструкторами, nocode решениями, гугл таблицами, эйртейбл, а вторые готовы отдать много денег за создание какого-нибудь реестра в облаке. У всех своя специализация и все по своему правы.

          Статью почитаю, спасибо!
            0

            Под системами электронного докуменооборота я имел в виду не Excel, а сосбтвенно системы электронного документооборота. Пока не понял чем Ваше предложения отличается от типовой системы электронного документоборота.

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

        Отличная инструкция к MS Sharepoint Lists :)

          0
          Да, реализовать можно хоть на 1С )
          +1

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


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

            0
            > Я не вижу ничего автоматизированного в этом документе
            Согласен) Если разбить процесс цифровизации на этапы, то сначала нужно дать пользователям систему, в которой каждому виду информации будет свое место (пусть даже заносить ее вручную). На этом этапе можно обкатать структуру БД и логику процессов. А затем уже автоматизировать работу. Если сразу накрутить автоматизацию, то юзерам, еще не понявшим общую структуру и типы сущностей, работа системы кажется непредсказуемой (они даже не могут толком понять, что не так и что вообще происходит)

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


            Тут вы, конечно, прям сильно обобщили. Вы говорите о каком-то одном направлении деятельности компании и только.
              0
              Конечно, не все. Но и не так мало, как может сначала показаться. Тут мне очень нравится подход вот этой команды: planfix.ru/ideologiya
              Наблюдал за ними еще на старте, 10 лет назад и с тех пор все еще не разочаровался
              –1
              BPMN подход ужасен и его хорошо можно увидеть в битриксе. У меня у одного из клиентов есть в битрикс24 бизнес-процесс — так вот он эдак экранов 10 в высоту и экранов 5 в ширину.
              Отсюда первый недостаток схем — ужасная навигация. В мире кода это давно решено разбиением простыни на функции, а вот в мире схем пока с этим проблема (и сворачивание-разворачивание блоков не сильно помогает).
              Второй недостаток: отладка. Тоже давно решенный в мире кода (логи, отладчик, профилирование), но отсутствующий в битрикс (думаю и в остальных системах также). Вот в битрикс максимум что придумали — это логи. Которые в невероятных объемах при таком подходе появляются и поэтому о них нужно отдельно заботиться (очистка, период хранения).

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

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

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

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

                  Да кажется наоборот, nocode платформы неплохо растут. Да и те же Excel и Гугл таблицы очень много пользы приносят, просто все как то привыкли и не замечают уже.

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


                    Если попытаться найти что-нибудь серьезное для Excel — то это будет либо макрос (visual basic), либо надстройка (он же), либо activeX (любой полноценный язык программирования). Тоже самое для гугл-таблиц — будет кусок js кода.
                      0

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

                  0
                  Я в вашей схеме согласования не увидел механику действий, в случае когда запрос не согласован кем-то из аппруверов: на какой этап откатывается заявка? Кто над ней работает в таком случае?
                    0
                    Конкретно в описанном бизнес-процессе этот момент не прописан, чтобы не усложнять. А вообще можно дать каждому согласующему перевести не только в статус Согласовано, но и обратно в Открыто. Там многое зависит от конкретного процесса: одним при несогласовании нужно откатить на один шаг назад, другим в самое начало цепочки и т.д.
                    +2

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


                    • очевидная реляционная логика, которая кажется естественной аналитику, очень трудно доходит до заказчика, поэтому если ваша доменная область состоит из нескольких сущностей рекомендую дополнительно любым способом визуализировать связи между ними или обеспечить визард, который проведет заказчика по трудному пути выбора характера и направления связи.
                    • табличная форма интерфейсов рано или поздно наталкивается на проблемы отображения: необходимо заводить возможности контекстного сокрытия полей в зависимости от роли, статуса, и т.д. либо, что гораздо проще, позволить заказчику тиражировать представления с произвольным набором полей и давать доступ целиком к представлению по роли и статусу. Вторая проблема представления: это проблема избытка полей и взаимосвязанная с ней проблема дизайна. Заказчик не дизайнер и для него нужны шаблоны форм. Кода дает такую возможность, но к сожалению не даёт возможности самостоятельной настройки шаблонов.
                    • настройка пути по статусам превосходно сделана в Jira и вполне возможно заимствовать их опыт, то же касается настройки ролей. Но имхо этот пункт уже уходит за пределы быстрого прототипирования. Однако вы еще можете приглядеться к СЭД где эту проблему решают давно.
                      В целом однако все равно остаётся проблема реинжиниринга бизнес-процессов и выявления узких мест, которую можно попытаться наглядно решить только имитацией потока элементов, операций бизнес-процесса и такие примеры тоже есть и реализованы как раз для BPMN, но никто не мешает вам загрузить подобным же образом Workflow движок, главное обозначить граничные условия процессов.
                      А в целом очень интересное начинание.
                      0
                      Вот это полезный комментарий! И похоже, за ним опыт не пары проектов автоматизации на досуге) Спасибо
                      0

                      В статье автор почему-то выдрал из процессного приложения 1 элемент – схему бизнес-процесса – и сетует, что этот элемент не закрывает все аспекты автоматизации процесса. Не удивительно, что не доволен.
                      Итого начал изобретать велосипед. Его "велосипед" для автоматизации "почти любого процесса", состоит из таблицы и формы документа. Похоже, он собрался даже не BPMS с нуля собирать, а вообще СЭД. ИМХО не стоит изобретать велосипед и откатываться назад к СЭД, где всё крутится вокруг документа. BPMS на волне цифровой трансформации хорошо поднялись и сейчас уже не только СЭД отлично заменяют, но и CRM. Здесь хорошо на пальцах пояснили — https://www.comindware.com/ru/blog-%d0%bd%d0%be%d0%b2%d1%8b%d0%b5-%d1%82%d0%b5%d0%bd%d0%b4%d0%b5%d0%bd%d1%86%d0%b8%d0%b8-%d0%b2-bpm/

                        0
                        Спасибо, полезное видео. Главная мысль спикера — перестать сохранять информацию в файлах, пересылая их разными способами (CRM, СЭД, почта ...) и начать уже хранить данные в базах данных, где к ним есть доступ из процессов. Полностью с ним согласен и мы делаем то же самое. Тут отличия только в терминах: он «документом» называет файл, а «карточкой документа» — набор полей, с инфой из БД. Я документом называю как раз карточку документа (набор полей, то что в сайдбаре), а файл я называю файлом. У нас все крутится не вокруг файла, а как раз вокруг процесса, который мы описываем в сайдбаре (то, что называем формой документа). Просто у нас метод описания процесса отличается от BPM нотации

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

                      Самое читаемое