Оригинал:
Model Strategy: Preserving vs. Transforming,
Model Strategy & Analytics,
Model Strategy, Round-Trip & Agile Development,
Model Strategy & Performance,
Model Strategy & Simulation (2009)
Автор: Кит Свенсон (Keith Swenson)
Все началось с непринужденной беседа в конце дня под выпивку на октябрьской выставке BPM Tech Show в Вашингтоне, после завершения учебы и презентаций. Мы задались вопросом — почему BPM-системы столь различны? На следующее утро за завтраком мы продолжили, перейдя к теме преимуществ и недостатков сохранения и трансформации BPM-модели. Мы обнаружили, что большинство существующих систем и связанные с ними методологии следуют одной из двух стратегий: стратегии преобразования модели или стратегии сохранения модели.
Примечательно, насколько увлеченно люди отстаивали свои позиции. Одни настаивали на том, что сохранение модели в течении всего жизненного цикла является обязательной составляющей аджайла. Другие заявляли, что преобразование модели из одного формата в другой — это правильный и наиболее эффективный способ реализации процесса в информационной системе. После завершения мероприятия состоялась серия групповых телефонных обсуждений, в ходе которых мы постарались до конца понять различия между двумя стратегиями, а главное — выяснить, когда лучше использовать ту или другую. Результаты наших обсуждений двух стратегий суммируются ниже.
Общий фундамент
Обе стратегии исходят из схожего представления о процессе создания процесса. Будем называть поток работ по созданию потока работ «жизненным циклом бизнес-процесса». В мире BPM нет ничего статичного. Следует различать как минимум три составляющих динамики:
- Исполнение бизнес-процесса: бизнес-процессу присуща динамика — он проходит от начала до конца обработки каждого экземпляра. Шаблон процесса обычно при этом не меняется, меняется только экземпляр и контекст, в котором сохраняется состояние конкретного экземпляра.
- Жизненный цикл бизнес-процесса: это изменения, которые бизнес-процесс претерпевает на пути от первоначальной концепции через моделирование и интеграцию к итоговому развертыванию в среде исполнения.
- Улучшение бизнес-процессов: это изменение бизнес-процесса во времени посредством многократного повторения жизненного цикла бизнес-процесса с анализом того, насколько хорошо работает данная версия бизнес-процесса. Это аспект BPM под названием «непрерывное совершенствование процесса».
Проходя через этапы жизненного цикла, модель процесса попадает к специалистам разного профиля. Первоначально с идеей бизнес-процесса, вероятно, будет иметь дело «владелец процесса». В дальнейшем на пути может встретиться «процессный аналитик», который имеет представление о бизнесе и одновременно обладает навыками моделирования, и «системный инженер», интегрирующий процесс с другими системами. В итоге, в ходе исполнения процесса с ним взаимодействуют системные администраторы пользователи. Встречаются жизненные циклы более сложные, с четырьмя или больше категориями специалистов, но для нашего обсуждения мы ограничимся тремя указанными, которые легко идентифицируются.
Различие между стратегиями сохранения и преобразования модели — это исключительно различие в жизненных циклах разработки. Среда исполнения и совершенствование процессов присутствуют в обоих подходах, но жизненные циклы в них очень разные.
Определение: стратегия преобразования модели
Сторонники стратегии преобразования считают, что на разных этапах жизненного цикла модель процесса должна приобретать разные формы — каждому этапу оптимальная для него форма.
Процессный аналитик разрабатывает модель высокого уровня, ориентированную на людей бизнеса. От людей бизнеса и аналитиков не ожидается, что они будут программистами. Модель высокого уровня преобразуется в нечто подходящее для программиста. «Бизнес-модель» превращается в «системную модель» либо путем добавления элементов, показывающих интеграционные действия, либо путем преобразования исходной диаграммы в совершенно новую диаграмму, показывающую взаимодействие на уровне систем, которое отражает взаимодействие на бизнес-уровне. Системный инженер работает с моделью такого формата в ходе интеграции процесса с другими системами. Затем модель еще раз преобразуется в формат среды исполнения.
Стратегия преобразования модели базируется на давней традиции программирования и разработки систем. В ходе разработки программного обеспечения модель высокого уровня часто изображается на визуальном языке, известном как Unified Modeling Language (UML). Затем такая модель может транслироваться в язык программирования, такой как C++. В результате мы получаем желаемую программу, но формат при этом полностью изменился и уже не имеет отношения к исходному UML. Можно сказать, что UML «уничтожен» и заменен другим форматом. Значимые аспекты оригинала нашли отражение и в новом формате, но совершенно иначе. В ходе преобразование может происходить «потеря качества», когда некоторые аспекты оригинальной модели не находят отражения в результирующей. Возможно, она в них и не нуждается — например, когда C++ преобразуется в машинный код, имена переменных теряются, потому что машинный код не нуждается в именах переменных. В мире разработки программного обеспечения подобные преобразования являются обычным делом.
Возвращаясь к примеру из области BPM: аналитик может включить в бизнес-модель операцию согласования документа. Такая операция может быть преобразована в: действие по отправке уведомления по электронной почте, действие по извлечению документа из хранилища, действие по отправке напоминания, если ответ задерживается и действие ожидания ответа. Программист может дополнить модель, включив в нее обработку исключений и тайм-аутов, которые бизнес-аналитик не предусмотрел. Впоследствии может случиться еще одно преобразование — в исполняемый код.
Можно представить, как разработчики программного обеспечения, привыкшие к такому подходу, смотрят на BPM — как на еще один вариант трансляции высокоуровневой модели в исполняемый код. Здравый смысл им подсказывает, что лучше придерживаться метода, уже доказавшего свою работоспособность. К этому же усиленно подталкивают поставщики инструментов, основанных на стратегии преобразования модели.
Определение: стратегия сохранения модели
Существует альтернативная стратегия, в которой форма модели сохраняется на протяжении всего жизненного цикла процесса. Эта стратегия весьма распространена среди BPM-систем, ориентированных на координацию действий людей.
Жизненный цикл по сути тот же самый: сначала представитель бизнеса составляет высокоуровневую модель процесса, которая отражает взгляд бизнеса на ход процесса. Все основные действия показаны в этой модели понятным для людей в организации образом.
На втором этапе модель попадает к программисту, который реализует интеграцию процесса с информационной системой. Разница с предыдущей стратегией в том, что это делается без изменения формы исходной модели. Вместо преобразования модели, в ходе которого элементы, ориентированные на понимание человеком, заменяются элементами, понятными системе, здесь исходные визуальные элементы остаются неизменными и лишь дополняются необходимыми для интеграции настройками. Элементы модели обогащаются, но формат модели не меняется.
На третьем шаге модель инсталлируется в процессный движок также без каких-либо преобразований. Число шагов процесса, выполняемых движком, в точности равняется числу элементов, которые изобразил на диаграмме представитель бизнеса. Связи между ними в точности те же, что и на исходной диаграмме. Так реализуется принцип «как нарисовали, так и работаем» (What You Draw is What You Execute).
Модель проходит сквозь систему в неизменном виде. По крайней мере, жизненный цикл не требует каких-либо преобразований. Может возникнуть ситуация, когда программист увидит возможность улучшить исходную модель, но такое улучшение производится в координации с бизнес-аналитиком, поскольку оба работают с одной моделью и оба видят одну и ту же картинку.
Анализ
Существующие программные продукты BPMS можно классифицировать по принадлежности к одной из двух стратегий. Какая из них лучше? Ответ зависит от ваших потребностей — от того, какого типа бизнес-процессы вы реализуете.
Мы можем сравнить и сопоставить две стратегии по следующим критериям:
- Поддержка замкнутого цикла разработки
- Обработка ошибок исполнения
- Возможности анализа
- Возможности имитационного моделирования и оптимизации
- Простота для программиста
- Аджайл и итерационная разработка
- Наглядность текущего статуса выполнения
Исходя из этого мы сделаем вывод о том, в каких ситуация предпочтительна та или другая стратегия. Сравнение и противопоставление двух стратегий следует ниже.
Стратегии моделирования и аналитика
Побочным результатом автоматизации работы является журнал, в котором фиксируется, когда запускается и завершается каждая задача. Ценность аналитики о том, как работает ваша организация, может даже превышать экономию от автоматизации. Такой анализ может многое дать для совершенствования вашей организации. Некоторые утверждают, что это принципиальное преимущество BPM.
Как отражается на аналитике стратегия моделирования? Исходные данные для анализа — записи об изменения статуса действий (задач), составляющих процесс. Например, одна запись делается в момент начала действия, другая — в момент завершения. Также могут делаться дополнительные записи, если действия проходят через промежуточные состояния. Бизнес-менеджеры хотят знать, сколько времени обычно занимает действие — оно рассчитывается как разница между временем начала и временем окончания.
Стратегия преобразования модели
В ходе преобразования модели действия из одного представления заменяются действиями, более подходящими для другого. Например, в бизнес-представлении для нас может представлять интерес согласование документа. Это единичное с точки зрения бизнеса действие в системном представлении превращается в несколько: извлечение документа, отправка уведомляющего сообщения, напоминание о просрочке, ожидание ответа.
Преобразование не является тривиальным, поскольку каждому представлению присущи логические ограничения, которые могут быть несовместимы с другими. Например, бизнес-представление может допускать неограниченные циклы, в то время как системное представление требовать строгой вложенности. Логические шаблоны, разрешенные в одном представлении, могут быть недопустимы в другом.
Процессный движок собирает для целей анализа информацию о том, когда действие началось, когда закончилось, сколько времени заняло, как часто выбрана та или другая ветвь маршрута. Но польза от такой информации для бизнес-аналитика невелика, так как она не корреспондирует с моделью, с которой имеет дело бизнес-аналитик. Он получит статистику по действиям, которые бизнес в глаза не видел, а информация по действиям, определенным в бизнес-модели, будет полностью отсутствовать.
Стратегия сохранения модели
В этой стратегии бизнес-модель остается неизменной и в системном представлении, и в среде исполнения. Данные о начале, завершении и продолжительности действий можно использовать в обсуждении с людьми бизнеса, так как они соответствуют бизнес-представлению процесса. Человек бизнеса может указать на конкретное действие модели и извлечь из системы относящиеся к ней записи временных отметок. Данные имеют смысл с точки зрения бизнес-аналитика, а также пользователей и системных интеграторов.
Выводы
Стратегия преобразования модели с большим успехом использовалась в разработке разнообразного программного обеспечения. Но огромная разница между компьютерной программой и поддержкой исполнения бизнес-процесса заключается в том, что обычно пользователю нет дело до внутреннего состояния программы. Например, пользователю все равно, сколько раз внутри текстового процессора исполнялась конкретная развилка. Пользователи программы также не вовлечены в непрерывное ее совершенствование.
В то время как компьютерная программа для пользователя может представлять собой «черный ящик», управление бизнес-процессом подразумевает определенную прозрачность исполнения процесса, которая делает возможным цикл непрерывного совершенствования. Стратегия сохранения модели позволяет организации собирать более полезные с точки зрения людей бизнеса аналитические данные и более эффективно измерять показатели эффективности бизнеса.
Стратегия моделирования, замкнутый цикл разработки и аджайл
Мы часто упоминаем замкнутый цикл («round trip»). Жизненный цикл процесса неотъемлемо связан с перемещением процесса между людьми с различной специализацией. Бизнес-аналитик рисует модель высокого уровня, системный интегратор добавляет информацию о подключении систем. Еще одно измерение динамики процессов — непрерывное совершенствование: вы оцениваете насколько эффективен существующий процесс, вносите изменение в модели высокого уровня и проводите это изменение через все стадии жизненного цикла.
Вы не хотите, чтобы программисту приходилось с нуля разрабатывать интеграцию из-за небольших изменений модели высокого уровня. Идея замкнутого цикла заключается в том, что все дополнения, вносимые программистом в ходе интеграции, каким-то образом попадают обратно в модель. Если это реализовано, то небольшие изменения, вносимые бизнес-аналитиком, со стороны программиста также потребуют лишь небольших правок.
Замкнутый цикл и преобразование модели
В стратегии преобразования модели замыкание цикла разработки представляет собой серьезную проблему. Когда бизнес-представление преобразуется в системное, некоторые аспекты модели, несущественные с точки зрения интеграции и исполнения, обычно отбрасываются. Затем системный инженер начинает дорабатывать получившуюся модель. В конце бывает не вполне понятно, как доработанный результат соответствует элементам исходной модели.
Элементы, интересные только для бизнеса, не обязательно должны отбрасываться в ходе преобразования. Некоторые системы кодируют такие элементы в системном представлении в виде пассивных элементов. Этот подход работает, когда две модели различаются не сильно, но зачастую преобразование приводит к существенным различиям. В отсутствии взаимно-однозначного соответствия между элементами двух представлений, в системной модели просто не находится места для хранения всей информации из бизнес-модели.
Второй подход к решению проблемы замкнутого цикла — сохранять в элементах системной модели идентификаторы элементов исходной бизнес-модели, из которой они были сгенерированы. Бизнес-модель остается под контролем бизнес-аналитика. Модифицированная системная модель может быть импортирована обратно в бизнес-модель. Если в ходе импорта идентификаторы совпадают, то информация об интеграции из системной модели связывается с исходным элементом бизнес-модели таким образом, чтобы ее можно было использовать при следующем экспорте.
Реализовать замкнутый цикл в рамках стратегии преобразования модели возможно, хотя это и не простая задача.
Замкнутый цикл и сохранение модели
С точки зрения реализации замкнутого цикла стратегия сохранение модели обладает очевидным преимуществом. Практически ничего делать не надо. Поскольку вид модели не меняется, нужно только позаботиться, чтобы бизнес-аналитик работал с последней версией, в которую внесены все интеграционные дополнения.
Бизнес-аналитик и системный интегратор имеют возможность работать над моделью параллельно. Параллельно не в смысле одновременного нажатия на клавиши, а в том смысле, что сначала один открывает, вносит исправления, сохраняет, и следом другой открывает, изменяет, сохраняет. Конфликты редактирования предотвращаются стандартным механизмом checkin-checkout. Возможность совместно работать над моделью в одно и то же время означает, что вам не надо специально согласовывать интервалы времени, в который каждая из сторон делает свою часть работы. Это обеспечивает очень быстрый цикл разработки.
Аджайл подразумевает замкнутый цикл разработки
Аджайл — это не просто быстрая разработка, это разработка итерационная. Суть аджайла в том, чтобы реализовать часть решения, попробовать, возможно, измерить насколько хорошо решение работает, реализовать еще кусочек, попробовать и т.д. Происходит множество мелких изменений, каждое из которых реализуется и внедряется в очень короткий срок. Каждая итерация отталкивается от результата предыдущей. Таким образом удается избежать повторного выполнения работы на каждой итерации.
Возможность реализовать аджайл прямо пропорциональна поддержке замкнутого цикла разработки. Любые ограничения на перенос правок для нужд системной интеграции обратно в бизнес-модель означают существенные трудозатраты на каждом цикле, потому что часть работы по интеграции приходится выполнять заново. Чем больше такой работы приходится делать, тем менее эффективны небольшие изменения. Чтобы избежать потерь, в такой ситуации организация увеличивает интервал между итерациями, включая в каждое пакет изменений.
Для тех, кто заинтересован в аджайле, стратегия сохранения модели явно предпочтительна. Поскольку вид модели не меняется, все этапы жизненного цикла могут применяться к одной и той же версии модели (почти) одновременно. Представитель бизнеса может изменить процесс на 5%. Программист может внести 5% правок в эту же копию модели. Модифицированный процесс может быть загружен в среду исполнения без повторного выполнения работы. Стратегия преобразования может приблизиться к такому режиму, но тот факт, что модель подвергается преобразованиям, не позволит людям работать параллельно.
Выводы
Если аджайл и эффективный замкнутый цикл представляют для вас ценность, то стратегия сохранения модели — очевидный победитель. Так как здесь не происходит преобразования между разными представлениями, то нет и барьеров между бизнес-аналитиком и системным интегратором — модель процесса передается между ними сколько угодно раз. Нельзя сказать, что замкнутый цикл в стратегии преобразования модели невозможен, и некоторые существующие системы преуспели в поддержке полноценного замкнутого цикла, но это нужно тщательно проверять. И даже если замкнутый цикл поддерживается, наличие явного преобразования между представлениями является барьером для эффективного взаимодействия между бизнес-аналитиком и системным интегратором.
Стратегия моделирования и производительность
Мы рассмотрели пару ситуаций, в которых стратегия сохранения модели — лучший выбор, но это не всегда так. Рассмотрим ситуации, в которых блестяще себя проявляет стратегия преобразования моделей.
Основное преимущество преобразования модели — повышение производительности.
Преобразование для целей исполнения
Процессы и программы пишут люди, а исполняют вычислительные машины. Эти машины (или среды исполнения) обладают определенными возможностями — определенными ограничениями или ориентацией на определенный класс задач. Преобразование модели позволяет использовать эти возможности или обойти ограничения, дабы ускорить выполнение программы. Представьте себе оптимизирующий компилятор, который преобразует язык программирования третьего поколения в машинный код так, чтобы ускорить программу за счет использования определенных возможностей целевой машины.
Альтернативой компиляции в машинный код является интерпретация исходной программы. Здесь на ум приходят интерпретируемые языки, такие как LISP, PERL, PHP, Ruby и JavaScript. В некоторых случаях используется компиляция, отложенная до запуска программы («just in time») — это делается прозрачно, так что результат компиляции никто и никогда не увидит. Java — это язык, который компилируется в некий промежуточный формат, который затем интерпретируется. Компромисс между компиляцией и интерпретацией — это предмет дискуссий, и вопрос здесь в том, какой уровень производительности вам необходим. Например, ядро сервера базы данных — это компонент, для которого критична высокая производительность, отсюда вытекает требование оптимизированного языка. С другой стороны, многие среды разработки веб-приложений используют интерпретируемый язык, поскольку для этих приложениях производительность не столь критична.
Стратегия преобразования модели делает то же самое с бизнес-процессом — из диаграммы, отражающей взгляд бизнес-аналитика, создает оптимизированный по скорости программный код.
Преобразование модели с точки зрения разработчика
Еще одна причина преобразовывать модель — представить ее в виде, удобном для системного интегратора. Если вы располагаете штатом Java-разработчиков, то проще преобразовать диаграмму BPMN в Java, чем учить программистов обходить ограничения, которые накладывает BPMN.
Не обязательно преобразовывать BPMN в язык программирования. Мой пост «Human Facilitator Process» — о преобразовании из BPMN в BPMN: бизнес-диаграмма BPMN показывает передачу ответственности, а системная диаграмма BPMN показывает поток данных.
Суть в том, что модель преобразуется из вида, наиболее подходящего для аналитика, к виду, оптимального для системного интегратора. Если бизнес-процесс требует большого объема работы по интеграции, то экономия времени разработчика может быть значительной.
Стратегия сохранения модели
Смысл сохранения модели в том, чтобы облегчить сквозную координацию на всем протяжении жизненного цикла процесса — но за счет промежуточных этапов. У системного инженера есть возможность разрабатывать интеграцию, но он должен делать свою работу в той же модели, что и человек бизнеса. Модель остается исполняемой, но она обязана исполняться в том же формате, который использовал человек бизнеса. Это компромиссный вариант.
Что выбрать
Ели в вашем проекте BPM много работы по интеграции информационных систем и относительно мало работы на стороне бизнеса, а вероятность изменения процесса во времени невелика, то стратегия преобразования модели оптимальна с точки зрения эффективности работы системных инженеров. Они смогут продолжать работать, как привыкли, опираясь на имеющиеся у них навыки и инструменты.
Если вы ожидаете высокой интенсивности транзакций, то вам, возможно, придется прибегнуть к стратегии преобразования модели из соображений производительности. Но что значит «высокая интенсивность»? Возьмите число экземпляров процессов в месяц, умножьте на среднее число задач в процессе, поделите на число рабочих часов в месяце, и вы получите примерное число задач в час. Если получится больше миллиона, то надо со всей тщательностью рассмотреть вариант преобразования модели. Если же ожидается в пределах десяти тысяч задач в час, то интерпретация не должна создать проблем даже на среднем по мощности сервере. Конечно это приблизительные числа, и в промежутке между ними надо дополнительно принять во внимание специфику реализации и тип транзакций. Но полезно иметь в виду, что многие важные критически важные для бизнеса процессы требуют выполнения меньше чем десяти тысяч задач в час — в этом случае производительность не является значимой проблемой.
Тем, кто разбирается в вопросах производительности, известно, что большую часть времени программа находится внутри кода, составляющего 5% общего объема. Зачастую оптимизация этих 5% кода дает 99% выигрыша производительности, который дала бы оптимизация всех 100% кода. Это объясняет тот факт, что диаграммы BPM, интерпретируемые на верхнем уровне и вызывающие оптимизированные функции на нижнем, работают практически так же быстро, как компилированные программы. Итоговая производительность связана не столько с тем, компилировался код или нет, сколько с качеством реализации библиотечных функций.
Рост популярности интерпретируемых языков в веб-приложениях — показатель того, что в них производительность процессора больше не является лимитирующим фактором. Опыт показывает, что производительность серверов больше ограничена вводом-выводом, чем процессором. Поэтому, даже потратив процессорное время на интерпретацию, итоговую производительность можно улучшить, если при этом удается уменьшить потребность в обмене данными.
Выводы
Если в проекте большая часть трудозатрат приходится на системную интеграцию или если интенсивность процессов чрезвычайно высока, то стратегия преобразования обеспечивает гибкость, которая позволяет программисту оптимизировать код и удовлетворить специфические требования среды исполнения.
Стратегия моделирования и имитационное моделирование
В большинстве BPM-систем присутствуют те или иные функции имитационного моделирования (simulation) — от элементарной возможности пройти по пути выполнения процесса до изощренных моделей, учитывающих темп поступления экземпляров процесса и темп выполнения задач, и вплоть до поиска оптимального пути достижения цели.
Польза от имитационного моделирования часто становится предметом дискуссий, поэтому имеет смысл разделить людей на два лагеря — оптимистов и пессимистов по отношению к имитационному моделированию.
Оптимист склонен к завышенным ожиданиям. Он ожидает точных количественных показателей того, как будет выполняться работа в процессе. Имитационное моделирование способно предоставить такую информацию, но для этого на входе необходимо задать точные количественные показатели поступления экземпляров процесса, затрат времени на задачу и точные модели выполнения своих обязанностей исполнителями. Это удовлетворительно работает только для огромного числа практически одинаковых экземпляров процесса и для работы, для которой индивидуальные различия в навыках, знаниях и подготовке работников не имеют никакого значения. И даже при этих условиях не факт, что имитационное моделирование окупит затраты на сбор точных данных о продолжительности задач и о распределении экземпляров процесса. Ожидания оптимиста могут быть завышены, но без сомнения, имитационное моделирование способно дать полезную информацию для относительно простых ситуаций, например: «Что будет, если нагрузка вырастет на 20% — в какой момент надо будет нарастить ресурсы?» Или: «Если убрать этот шаг из ветви процесса, в которой риск минимален и по которой проходят 90% экземпляров, то какая получится экономия по сравнению с ожидаемой ценой устранения маловероятной проблемы? »
Пессимисты же не верят, что можно извлечь кролика из шляпы, если предварительно его туда не засунули. Но даже для пессимиста очевидно, что имитационное моделирование раскрывает динамику процесса и благодаря этому позволяет глубже понять модель. Для большинства людей формальная графическая модель — вещь не вполне естественная, и поэтому для облегчения понимания модели все средства хороши. Это своего рода «отладка» , позволяющая бизнес-аналитику выявить основные проблемы до перехода к следующему этапу разработки.
Стратегия преобразования модели
С точки зрения пессимиста имитационное моделирование очень важно, так как дает возможность бизнесу исправить проблему на своем уровне до того, как она станет проблемой в системном представлении модели процесса. Поскольку цена ошибки при переходе на следующий уровень возрастает на порядок, необходимо использовать любые возможности отладки до того как передавать модель на следующий уровень.
Для оптимиста проблема заключается в том, что результаты имитационного моделирования бизнес-модели могут соотноситься с системным представлением и исполняемой моделью, а могут и нет. Огромное количество времени на построение точных моделей исполнителей и нагрузки может быть потрачено впустую, если при переходе к реальному исполнению модель подвергается преобразованию. Уровень ресурсов, определенный как оптимальный исходя из бизнес-модели, для преобразованной модели может оказаться неоптимальным. Имитационное моделирование на системной или исполняемой модели может быть более эффективным с точки зрения оптимизации, но для бизнес-аналитика эти модели не представляют ценности, а обратное преобразования оптимального решения в бизнес-представление может быть неочевидным. Оптимист обнаруживает, что преобразование модели значительно усложняет имитационное моделирование.
Стратегия сохранения модели
Ясно, что здесь оптимист чувствует себя более уверенно, поскольку модель, спроектированная бизнес-аналитиком, один-в-один исполняется процессным движком. Оптимальные настройки с большей вероятностью отражают реальность.
Для пессимиста обе стратегии примерно равноценны. Имитационное моделирование способствует лучшему пониманию динамики процесса, и это справедливо вне зависимости от того, преобразуется модель или нет. Хотя можно заметить, что если нет преобразования модели, то нет и необходимости завершать имитационное моделирования до перехода к следующему этапу. Если формат модели на протяжении жизненного цикла сохраняется, то бизнес-аналитик и системный интегратор могут объединить усилия для достижения большей точности имитационного моделирования.
Выводы
Таким образом, для пессимиста основные преимущества имитационного моделирования не зависят от того, преобразуется модель или нет. Оптимист же, стремящийся получить от имитационного моделирования количественные результатов, добьется намного большего с помощью системы с сохранением модели.
Обсудить в нашей группе в фейсбуке >>