Антон Меркулов проделал отличную работу модулируя свой отдел используя основные понятия (мета мета модель) из системного мышления и менеджмента, тем самым задав мета модель для описания модели работы своего отдела.
Текстовая форма интересна тем, что позволяет использовать полнотекстовый поиск, быстро находить и исправлять коллизии. Управление конфигурацией ведется в системе контроля версий, те все изменения можно отследить и откатить модель до приемлемой версии. То, что вся модель помещается на 3-4 экрана, те является удивительно компактной, это конечно большое преимущество перед любыми визуальными моделями. Сама метамодель содержит очень ограниченное число объектов - около 7-8, что позволяет очень компактно, а главное быстро (2 часа в неделю) работать над архитектурой отдела.
Если переложить идеи Антона на мое предприятие, то мне кажется, что эту модель нужно сделать actionable, т.к. как на текущий момент она используется только для описания архитектуры и как инструмент для согласования изменений между сотрудниками отдела. Однако, сами работы ведутся в других системах и , например, чеклисты, описанные в модели, представлены в других системах как то по-другому, возможно более детально, возможно в другом виде. Я бы хотел, чтобы мои модели были описаны прямо в системах, где проводятся работы. Те вместо какого то кейса, описанного в архитектурной документации, я бы хотел, чтобы этот кейс прямо присутствовал, например в Jira, вместе с описанием как с этим кейсом работать, и всеми чеклистами, которые можно было бы обновлять по мере необходимости.
Роли бы автоматически задавились поддерживаемыми системами, например, сам кейс назначается на роль автоматически, после наступления какого то события, что позволяет уведомлять эту роль о том, что предстоит сделать. Тут же можно проводить контроль исполнения, задавая роль проверяющего, через эти же корпоративные системы. И вот этот кейс как модель, тут же бы копировался/клонировался как экземпляр для выполнения каких то конкретных работ по этому кейсу. Таким образом можно избавиться от проблемы навязывания / обучения процессам сотрудников (до какой то степени) и внося правки прямо в модель, если получена какая то обратная связь по экземпляру процесса / кейса.
В качестве примера, прямо сейчас я создаю кейс/процесс передачи дел, когда сотрудник идет в отпуск или увольняется. Метамодель я описываю прямо в issue tracker как отдельный проект “Handover”. В этом проекте была создана модель кейса handover как сущность task со своими подкейсами/подтасками. Каждый подкейс имеет свой чекист. Кейс handover имеет свой workflow (жизненным цикл). Когда сотрудник отправляет заявку на отпуск или по какому то другому триггеру, эта модель кейса копируется, на нее назначается сотрудник, идущий в отпуск и его менеджер как watcher. Те создается экземпляр кейса с которым ведутся работы.
Наверное это очень похоже на то, что сделал Ильшат в докладе про Архитектуру Aisystant, только он использовал таблицы и проверке прямо в таблицах, а я использую issue tracker и работы ведутся прямо в issue tracker. Понятно, это эту архитектуру все равно нужно будет где то описать но как минимум, большую часть описания можно заменить ссылкой на модель кейса в системе, которая этот кейс поддерживает и прямо договариваться используя/показывая, как работает экземпляр этой модели.