?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Пределы детализации модели
serge_gorshkov
В ответ на интересный, хотя и небесспорный пост maxstroy на Хабре о моделировании событий (вообще, всем интересующимся моделированием рекомендую прочитать его цепочку постов), у меня родился связный текст о критериях "правильности" моделей, и о том, как найти нужный уровень детальности модели. Воспроизвожу его здесь.

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

Говоря о моделировании деятельности предприятия, надо тоже сразу думать о том, как мы будем применять эту модель. Если ее прагматика в том, чтобы распечатать процессы на больших красивых плакатах, повесить в переговорке, и положить в отчет для инвесторов, то подойдет и Aris, и BPMN, все что угодно — никаких проблем.
Если прагматика в том, чтобы на основании модели написать ТЗ на внедрение типовой программной системы, и должностные инструкции для сотрудников — то, скорее всего, тоже указанных нотаций хватит. Более того, применение более совершенных («правильных») методик моделирования будет вредным, так как редкий исполнитель сможет ими воспользоваться.

Если же задача, например, в том, чтобы возложить управление процессом на информационную систему, причем не путем выполнения каких-то заранее запрограммированных или сконфигурированных последовательностей действий, а путем симуляции принятия решений с оценкой их последствий, поиска оптимальных решений в неизвестной заранее ситуации — тогда да, нужна куда более совершенная модель, причем не только самого процесса, но и окружения, в котором он происходит.

Здесь важно не увлечься с широтой и глубиной охвата, в погоне за «правильностью». Рациональный уровень детализации и сложности модели можно посчитать, исходя из ожидаемого экономического эффекта от ее применения, и стоимости создания/поддержки модели. Это и есть критерий приемлемости тех допущений и пренебрежений, которые мы делаем при моделировании.

Сформулирую общий критерий проверки правильности модели процесса с прагматической точки зрения. Фрагмент реальности и его модель связаны отношениями подобия, через которые выражаются те правила, которые заложены в выбранной методике моделирования. Методику мы выбрали исходя из приемлемого для наших задач уровня абстракции, по описанному выше принципу.
У моделируемого процесса есть исходное и конечное состояния. При помощи отношений подобия мы можем «отразить» их в модель. Так вот, если результат протекания процесса в реальном мире, отраженный в модель, и результат протекания модели процесса в самой модели, будут отличаться не более, чем на устраивающую нас величину погрешности — значит, модель пригодна. На диаграмме это можно показать так:
Критерий правильности модели

Из этого легко видеть, что модель может быть сколь угодно простой и примитивной. Это нормально, пока она позволяет достигать результата.

  • 1
Разные временные горизонты симуляции/эксперимента приносят разные отклонения реального процесса и модели. Хорошо бы к критериям качества отнести: размер интегральной погрешности (не в моменте) и устойчивость при значительных внешних воздействиях. Чем больше модель отрабатывает крайних случаев, тем интереснее она.

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

Роль "модели" в управлении думаю еще предстоит раскрывать. При всей очевидности и уже большом опыте моделе-использования - интегральное/комплексное моделирование - есть огромной дыры тема.

Отталкиваться от прагматики хорошо, но тогда можно попрекнуть подход. Типа на этом интервале (в определенном измерении) моделе-ориентированность используем, а тут включаем ручное управление. Тут станет неочевидна экономическая целесообразность.

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

Интересно, для решения какого круга задач предназначено моделирование в нотации ИСО 15926? Я для себя сделал вывод, что для интеграции САПР-ов между собой, а также для интеграции данных производителей-поставщиков и покупателей-эксплуатационщиков оборудования. Что-то ещё?

Edited at 2015-01-02 11:02 am (UTC)

Да, это соответствует первоначальной, титульной задаче этого стандарта. Попытки расширить его применение на другие задачи оказывается не слишком убедительными. К тому же, если успешные кейсы и демонстрируются - не очевидно, что заслуга в успехе принадлежит именно самому стандарту. Таких же преимуществ можно достичь и с применением других технологий.
В общем, главное, на мой взгляд - не стандарт как таковой, а методология моделирования, подходящая решаемой задаче.

Согласен.
Единственное исключение из правила - это применение более детальной, но уже имеющейся модели (из решения смежной задачи), чем нужно для решения новой задачи. Примером могла бы быть модель архитектуры предприятия в нотации ИСО 15926, для решения обозначенных мною задач (САПР-ы + поставка оборудования), но используемая в том числе, для интеграции данных в максимуме других задач автоматизации предприятия.

  • 1