Комментарии 24
Хорошо. Не даром в свое время все мои идеи об автоматизации бизнес-процессов разбивались о невозмутимые сентенции продвинутых мальчиков из заводоуправления: так ведь то же самое можно сделать и в Excel.
Вот Вы позиционируете свою идею в сопоставлении с системами основанные на всяческих бизнес-правилах и т.п. Но с первого прочтения Ваше предложение очень похоже на типовую систему электронного документооборота. Или есть какие-то принципиальные отличия?
PS: Кстати как это получается https://habr.com/ru/company/lanit/blog/549108/ — неделя электронного документооборота на Хабре?
Excel действительно многое позволяет реализовать, не раз видел, как заказчику, не умеющему (или не желающему) в нем работать продают почти то же самое за гораздо большие деньги. И если посмотреть, как автоматизируют свою работу IT компании и производственные, то первый часто пользуются какими-то конструкторами, nocode решениями, гугл таблицами, эйртейбл, а вторые готовы отдать много денег за создание какого-нибудь реестра в облаке. У всех своя специализация и все по своему правы.
Статью почитаю, спасибо!
Под системами электронного докуменооборота я имел в виду не Excel, а сосбтвенно системы электронного документооборота. Пока не понял чем Ваше предложения отличается от типовой системы электронного документоборота.
Отличная инструкция к MS Sharepoint Lists :)
Мне кажется, вы изобрели тикетную систему. Посмотрите на любой нормальный issue tracker — там и разные типы тикетов, и настройка полей в них, и автоматизация различного рода (валидация, cron-задачи, шаблоны и т.д.) и гораздо более широкие возможности по интеграции с чем-либо.
Я не вижу ничего автоматизированного в этом документе — вся настройка, весь процесс документирования — ручной. Поправьте меня, если я не уловил мысль.
Согласен) Если разбить процесс цифровизации на этапы, то сначала нужно дать пользователям систему, в которой каждому виду информации будет свое место (пусть даже заносить ее вручную). На этом этапе можно обкатать структуру БД и логику процессов. А затем уже автоматизировать работу. Если сразу накрутить автоматизацию, то юзерам, еще не понявшим общую структуру и типы сущностей, работа системы кажется непредсказуемой (они даже не могут толком понять, что не так и что вообще происходит)
Это личное мнение и многое зависит от сферы деятельности и компании. Например в маркетинге или банковом секторе информационные потоки уже оцифрованы, а вот в строительных компаниях (наши заказчики) первый этап еще не пройден.
Большинство процессов состоят из одних и тех же действий
Тут вы, конечно, прям сильно обобщили. Вы говорите о каком-то одном направлении деятельности компании и только.
Наблюдал за ними еще на старте, 10 лет назад и с тех пор все еще не разочаровался
Отсюда первый недостаток схем — ужасная навигация. В мире кода это давно решено разбиением простыни на функции, а вот в мире схем пока с этим проблема (и сворачивание-разворачивание блоков не сильно помогает).
Второй недостаток: отладка. Тоже давно решенный в мире кода (логи, отладчик, профилирование), но отсутствующий в битрикс (думаю и в остальных системах также). Вот в битрикс максимум что придумали — это логи. Которые в невероятных объемах при таком подходе появляются и поэтому о них нужно отдельно заботиться (очистка, период хранения).
Отсюда выходят простые свойства при эксплуатации: когда бизнес-процессы маленькие — это красиво. Но сложность растет крайне быстро при усложнее БП — я бы оценивал рост сложности как степенной относительно роста сложности БП. Поэтому система довольно быстро проходит точку, где каждый разработчик, смотря на монструозный БП — думает «в нормальном коде это было бы проще, лучше поддерживалось бы».
И совсем не видна в статье настройка процесса перехода статусов — а в них обычно и есть вся сложность. При каком-то переходе должно проверяться это, при каком-то это. Где-то должны переход делать программные модули (например при получении почты, платежа, заявки или еще чего), где-то люди.
Все попытки на моей памяти «сделать программирование для непрограммистов» — провалились.
Да кажется наоборот, 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/
Легкий способ автоматизировать бизнес-процессы, о котором не знает Аллен Карр