Производственная деятельность предприятия связана с работой ответственных должностных лиц над одним или несколькими документами. Порядок прохождения документов определён нормативными актами. Каждое должностное лицо заполняет ту или иную часть документа, согласовывает, утверждает документ, возвращает его на доработку, участвует в выполнении работ по документу. Бизнес процессы, описывающие производственную деятельность принято представлять в формате BPMN, а системы, автоматизирующие бизнес-процессы, часто создают с использованием ИТ-платформ типа Camunda. Camunda выступает в роли BPMN-движка. Camunda довольно специфический продукт, требующий  привлечения специалистов соответствующей квалификации. Можно предложить подход  к автоматизации бизнес-процессов, не требующий специальной подготовки  аналитиков и разработчиков. Если предметная область имеет  детерминированный характер, то можно применять парадигму автоматного программирование, в рамках которой автоматизируемая производственная деятельность рассматривается с точки зрения теории конечных автоматов (Finite state machines).  Прохождение документа по своему жизненному циклу можно представить в виде конечного автомата: этапы прохождения документа определяют состояния автомата, а действия должностных лиц над документом определяют переходы между состояниями. Конечный автомат характеризуются набором состояний и правилами переходов между этими состояниями.  Детерминированный конечный автомат в результате входного воздействия может перейти из одного состояния в строго одно следующее состояний. Это состояние зависит от входного воздействия. На практике документ после рассмотрения должностным лицом может быть дальше передан на рассмотрение более чем одному должностному лицу. Соответствующий автомат будет иметь несколько активных состояний и будет являться  недетерминированным конечным автоматом. Добавим в недетерминированный конечный автомат особый тип состояния «Точка сборки»: переход автомата из точки сборки в следующие состояния происходит не по команде, а автоматически, когда осуществлён переход в точку сборки изо всех состояний, имеющих выход в эту точку сборки. Здесь просматривается аналогия логики работы точки сборки с логикой работы перехода в сетях Петри. Назовём такой автомат структурным автоматом.  Автоматизация бизнес-процесса, связанного с работой должностных лиц над документами осуществляется в веб-приложении. Документу соответствует веб-страница. Веб-страница документа содержит набор элементов управления, включая дата-гриды, диаграммы, командные кнопки  или ссылки  и т.д. Каждое состояние документа может иметь свой набор элементов управления на веб-странице.  Логикой прохождения документа по своему жизненному циклу управляет движок веб-приложения, реализующий структурный автомат. Логика приложения зашита в таблицу переходов автомата и отделена от кодового каркаса движка веб-приложения. Разработка логики автоматизируемых бизнес-процессов, создание диаграмм переходов автоматов является конфигурированием системы, осуществляется аналитиками и не требует программирования.  Использование конечных (не структурных) автоматов для автоматизации бизнес-процессов представлено в свидетельствах о государственной регистрации программы для ЭВМ №№ 2016661880, 2017661726, 2019619743. Я не автор этих разработок. Там же предлагается  каждое состоянием документа связать с определённой ролью или ролями пользователя. Будем следовать этому подходу.  Потребуем:  если из состояния есть переход в несколько состояний, то этим состояниям соответствуют разные роли; к точкам сборки и финальному состоянию роли не привязываются. Если документ находится в определённом состоянии, то внести изменения в документ и перевести его в другие состояния может только роль, связанная с этим состоянием. Для перевода документа в другие состояния служат командные кнопки или ссылки на веб-странице. Для каждого состояния документа для роли, связанной с этим состоянием, имеется определённый набор действий, который роль должна выполнить над элементами управления веб-страницы документа. Только после выполнения всего набора действий на веб-странице активируются командные кнопки или ссылки для перевода документа в другие состояния. Если роль открыла документ с неактивным состоянием, привязанным к этой роли, то роль имеет к элементам управления документа доступ только на чтение или вообще не может открыть документ. Если роль открыла документ с состоянием, не привязанным к этой роли, то роль имеет к элементам управления документа доступ только на чтение или вообще их не может открыть документ. Документ может иметь несколько экземпляров. Каждый экземпляр документа находится в своих определённых активных состояниях. Переход электронного документа в новое состояние подтверждается простой электронной подписью. В качестве простой электронной подписи рассматривается имя и пароль учётной записи пользователя, используемые для входа в веб-приложение. Между пользователями и администрацией составляется соглашение, устанавливающее признание электронного документа, подписанного простой электронной подписью, равнозначным документу на бумажном носителе, подписанным собственноручной подписью.  Рассматривается реализация движка структурного автомата  для одного экземпляра документа. Веб-версия движка реализована на Python и PHP. Логика реализована с помощью SQL-запросов. Исходные коды, примеры структурных автоматов в виде файлов SQLite-баз и руководство по установке движка можно посмотреть на github. Скрипт - движок структурного автомата. Версия на PHЗ. Эмуляция входа роли в веб-приложение. Показано, что вошедшая в приложение роль может открыть страницу только активного и привязанного к этой роли ней состояния. fsmxS.php   SQLite-база fsmx.db содержит три таблицы: fsmx — таблица переходов структурного автомата с колонками state (номер состояния), command (номер команды) и nextState (номер следующего состояния); roleStates — таблица связки ролей с состояниями с колонками state (номер состояния) и role (номер роли);  activeState — таблица с колонкой, содержащая перечень номеров активных состояний структурного автомата. В базу добавлены sql-представления: 1.      Число входов у точки сборки. Признак точки сборки: command = -1.   2.      Число повторяющихся активных состояний. Используется для активации точки сборки, когда число переходов в точку сборки равно числу её входов. Скрипт для задание номера начального активного состояния, например 20, для  примера 2 выше. PHP:  Технический писатель. Аналитик