Доложился сегодня на конференции «Актуальные проблемы системной и программной инженерии» (АПСПИ-2013) --
http://www.mesi.ru/our/events/detail/121699/ по теме моделеориентированной инженерии предприятий. Вот тезисы:
Моделеориентированная инженерия предприятий (MDEE, model-driven enterprise engineering) является разделом системной инженерии, занимающейся инженерией весьма специфического объекта - предприятия. Мы предпочитаем говорить не об organizational engineering, но об enterprise engineering - несмотря на похожесть этих терминов, в organizational engineering идёт акцент на академическую дисциплину, ограничивающуюся только инженерией «человеческой» части предприятия. В enterprise engineering это практическая инженерная дисциплина, всё организационное дополняется в ней вниманием к технологической инфраструктуре, включая IT-инфраструктуру. Ещё более широкий термин - это business engineering, поскольку в него включается и стратегирование по выходу на какие-то рынки, т.е. предпринимательская деятельность, и это уже не столько инженерная, сколько менеджерская дисциплина.
Мы склоняемся к принятию термина «предпринятие» (от «что-то предпринять») как означающего организованность какой-то группы людей, т.е. действующие договоренности о разделении ресурсов и труда - договоренности о полномочиях по распоряжению какими-то видами ресуров и об ответственностях за какие-то виды работ. Слово «предпринятие» позволяет унифицированно говорить не только о предприятиях-юрлицах, но и об организованностях меньшего размера (подразделениях предприятий, рабочих группах, проектных командах), а также бОльшего размера (например, «расширенных предприятиях»). Тем самым мы предпочли бы говорить о моделе-ориентированной инженерии предпринятий, что явно шире моделеориентированной инженерии юридических лиц-предприятий.
Также мы считаем, что «моделеориентированная» в нашем случае - это не model-oriented, а model-driven. Model-oriented инженерные практики подразумевают активное использование формальных (моделей на формальных языках, имеющих строго определённую семантику) моделей для получения ответов на различные вопросы, возникающие при разработке основных рабочих продуктов инженерной деятельности. Model-driven инженерные практики подразумевают использование формальных моделей в качестве основных рабочих продуктов инженерной деятельности, а также построение цепочек трансформаций этих моделей друг в друга, порождающий подход (generative approach) как в части проектирования (generative design), так и в части воплощения (generative manufacturing в случае производства, generative execution в случае организации).
В современном крупном предпринятии используется огромное количество моделей - можно указать «бизнес-модели» (наиболее продвинута попытка формализации их в проекте стандарта OMG VDML - value delivery modeling language), модели для выражения архитектуры предприятия (например, OpenGroup ArchiMate-модели), модели-планы в ERP-системах и системах проектного управления, модели процессов в моделях проектного управления, модели методов работы людей. Все эти модели представляют собой описания совместной деятельности людей (зачастую включая описания взаимодействия людей с информационными системами и производственным оборудованием и инструментами, а также описания работы информационных систем и производственного оборудования и инструментов), адресующими разные интересы разных заинтересованных сторон (stakeholders) предпринятия путём задействования разных тематических методов описания (viewpoints) для создания разных тематических групп описаний (views), включающих в себя отдельные модели.
Так, модели деятельности (например, какой-нибудь «утренней продувки трубопровода низкого давления») можно обнаружить в крупном предприятии отмоделированным минимум четырежды:
-- в архитектуре предприятия, чтобы понимать, какие информационные системы её поддерживают (при этом часто эта модель будет разбита на два отдельно моделируемых куска: «бизнес-процессы» и регламенты работы будут отмоделированы в "службе обеспечения качества", а архитектура информационных систем и аппаратного комплекса в «IT-службе»).
-- в описании метода работы (менеджеры среднего звена нуждаются для работы с людьми совсем в другого типа описаниях, нежели могут быть сделаны в соответствии со стандартами процессных описаний BPMN или архитектурных описаний ArchiMate, а документы "службы качества" часто хороши только для отчётности о взятых у работников интервью сотрудниками этой службы) с задействованием стандартов ситуационной инженерии методов (OMG Essence, OMG SPEM 2.0, ISO 24744).
-- в обучающих пакетах (чаще всего в соответствии со стандартом SCORM) дистантного образования, поддерживаемых HR-службой.
-- в системе документооборота, или системе процессного управления (BPM), или трекере выполнения поручений (issue tracker, система adaptive case management), или системе проектного управления - для целей планирования работ и контроля их выполнения.
Тем самым по факту современное крупное предпринятие использует мультимоделирование деятельности, решая неизбежные при этом задачи управления конфигурацией моделей: самые разные модели должны отражать одну и ту же планируемую и актуальную деятельность, версии разных моделей должны соответствовать друг другу.
Но управление конфигурацией моделей и федерирование информационных систем моделирования деятельности предпринятия - это не самая главная задача моделеориентированной инженерии предпринятия. Главная задача - это автоматизация как моделирования (в том числе порождения из моделей требований архитектурных моделей, из архитектурных моделей детальных моделей, из детальных моделей - оргструктур и планов работ), так и выполнения планов работ.
Эта автоматизация по факту происходит сразу многими путями:
-- Улучшение качества моделирования как отражения деятельностной действительности: разработка формальных представлений моделей деятельности, в том числе системных (system thinking) и онтологических представлений о деятельности (например, ISO 15926 и OMG SBVR) и в целях федерирования отдельных тематических групп описаний деятельности.
-- Автоматическое построение моделей деятельности (например, process mining и использование Big Data для открытия закономерностей в деятельности).
-- Использование современного автоматизированного оборудования с компьютерным интерфейсом, позволяющим запускать и выполнять какие-то работы без участия людей (ход на полностью автоматизированное предприятие).
-- Использование информационных систем, работающих с неструктурированной (текстовой, графической, аудио, видео) информацией на естественных языках в качества интерфейса между людьми и компьютерами - тут можно указать на информационные интерфейсы типа Apple Siri и системы поддержки диалогов в call-центрах. Эпоха экранных форм с сотнями полей в десятках окошек и запросов с труднопонимаемым непрограммистами синтаксисом начинает уходить.
-- Использование компьютерных систем принятия решений (экспертных систем нового поколения, «электронных помощников») как для целей моделирования деятельности (тут прежде всего можно указать на опыт использования IBM Watson в медицине), так и для целей выполнения уже отмоделированной деятельности (системы управления поручениями с «автоматической росписью поручений»).
Приход «слабого искусственного интеллекта» (weak AI) в моделеориентированную инженерию предприятий ведет к драматическим изменениям в самом предмете: если сегодня «деятелями» выступают только принимающие решения люди, то уже буквально завтра в число «деятелей» придётся включать интеллектуальные системы. В силу невозможности централизации всех интеллектуальных систем в одной неизбежно будет использован агентский подход, что приведёт к необходимости обобщения всех моделей предпринятия на случай занятия деятельностных позиций как людьми, так и компьютерными агентами. Выход интеллектуальных систем в физическую реальность (робототехника) только добавит сложности используемым моделям.
Отдельная сложность - это необходимость «загрузки в голову» моделей предпринятия, ибо полного исключения людей из деятельности не предвидится, и их нужно будет непрерывно учить занимать свои деятельностные роли согласно непрерывно меняющимся моделям предпринятия (эти модели ведь носят нормативный , а также кооперироваться так, чтобы автоматизированная часть предпринятия не выпадала бы из этой кооперации. Люди и «нежить» должны будут научиться договариваться, а это ещё более трудно, чем научить договариваться между собой людей. Лидерство (leadership) тем самым должно быть демистифицировано и отмоделировано тоже: человеческие системы нельзя получить инженерными методами, для работы с ними должны быть использованы другие дисциплины: праксеология, конфликтология, аксеология, политология, социология, экономика, юриспруденция и т.д..
Отдельной проблемой является стыковка технологических (инженерных, выражающих структуру и свойства выпускаемой продукции и технические аспекты функционирования оборудования) и организационных (выражающих людей и выполняемые ими операции) моделей предприятия. Так, инженерные модели обычно создаются и хранятся в САПР, а вот деятельность отражается в трекерах и системах проектного управления. Первые попытки выразить связи между этими моделями («инженер X=Сидоров выполнит работу Y=согласование систем Z=P&ID АЭС и Q=3D модель АЭС») начинают появляться в PLM-системах, но это только первые шаги. Стык менеджерской/логистической и инженерной/технологической действительностей труден в моделировании в том числе и потому, что нет общепринятого решения по налаживанию совместной деятельности людей-операционных менеджеров и инженеров.