Открыть список
Как стать автором
Обновить

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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


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

В статье автор почему-то выдрал из процессного приложения 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/

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