INITIAL DATA UNCERTAINTY INFLUENCE ON EFFECTIVENESS OF NON-REFLECTIVE SYS-TEM STATISTICAL SIMULATION. PART 1. TEST STATISTICAL SIMULATION MODEL

Full Text

Введение Статистическое имитационное моделирование (СИМ) по версии метода Димова-Маслова (МДМ) отличается от других подходов к созданию моделей сложных систем (СС) различного назначения (аналитические методы; агрегативное моделирование; системная динамика; агентное моделирование; нелинейная динамика и т.п.) уже на стадии постановки целей и задач моделирования. Помимо исследования процессов функционирования СС в статике и динамике, МДМ направлен на совершенствование управления СС и адаптирован для решения широкого круга связанных с этой целью задач. Методика СИМ по МДМ предусматривает проведение следующих действий: - содержательное описание объекта (реальной СС) в интересах СИМ с учетом особенностей рассматриваемой предметной области; - определение состава случайных величин (СВ), отражающих воздействие на СС (объект СИМ, моделируемый бизнес-процесс) стохастических факторов по результатам ее описания; - определение состава исходных данных, необходимых для проведения СИМ, применительно к условиям работы моделируемой СС; - комплексное (в том числе статистическое) исследование СС как объекта СИМ; - идентификация законов распределения СВ, признанных наиболее важными для СИМ рассматриваемой СС; - разработка математических моделей, соответствующих описанию частей СС (подсистем и элементов) и СС в целом; - разработка моделирующего алгоритма, реализующего полученные математические модели; - разработка компьютерных программ для моделирования СС; - разработка и описание задач управления СС, решаемых с помощью СИМ по МДМ; - разработка и реализация плана компьютерного эксперимента, проводимого с СИМ-моделью; - обработка, анализ и интерпретация выходных данных СИМ, а также любые другие необходимые варианты практического применения полученных результатов. Существенно также, во-первых, что МДМ предполагает применение наиболее развитых (по сравнению с другими подходами) способов повышения эффективности управления СС на основе моделирования динамики их функционирования с учетом случайных факторов (в том числе различного рода неопределенностей), влияющих на принятие управленческих решений. Во-вторых, что ключевое значение имеют операции, предваряющие математическое моделирование объекта - непосредственным образом связанные с его исследованием и формированием исходных данных для проведения СИМ. Цель первой части статьи - представление СИМ-модели бизнес-процесса «Предоставление государственных и муниципальных услуг» Многофункционального Центра (МФЦ) областного уровня, выбранной в качестве тестового объекта для проведения дальнейших исследований. Цель второй части статьи - анализ на примере выбранной тестовой модели влияния неопределенности и кумулятивности (под которой понимается свойство минимального объема информации быть максимально полезной для достижения поставленной цели) исходных данных СИМ на его эффективность. Принципы СИМ нерефлекторных СС Различие между рефлекторными (преимущественно технического типа) и нерефлекторными (организационно-техническими, социально-экономическими, экологическими, медицинскими, военными и др.) иерархическими СС впервые определил Н.Н. Моисеев: реакция рефлекторных СС на внутренние и внешние возмущения однозначна, изучение процессов управления ими сводится к задачам оптимизации на основе принципа максимума Понтрягина без учета особенностей поведения звеньев (подсистем, элементов) СС [1]. Изучение нерефлекторных СС, напротив, требует от лиц, принимающих решения (ЛПР), введения гипотез относительно поведения указанных звеньев: поскольку они способны самостоятельно максимизировать (ввиду наличия «человеческого фактора», делегирования полномочий «сверху - вниз» и т.п.) свои функционалы качества при воздействии возмущений, что ведет к конфликтным ситуациям и невозможности использовать принцип максимума Понтрягина при управлении ими [2]. Иерархичность и нерефлекторность возникают в СС естественным путем - по мере роста, развития и усложнения любой простой системы. Случайные возмущения при этом можно рассматривать как фактор неопределенности знаний ЛПР, которая осложняет его действия - ввиду отсутствия необходимой информации, присутствия помех, наличия нескольких целей и неопределенности намерений самого ЛПР, а также противодействия ему со стороны конкурента или злоумышленника, отсутствии согласованного взаимодействия с партнерами. Поскольку знания ЛПР могут быть как верифицированными, так и аксиологическими, последние представляют наибольший интерес при организации управления нерефлекторными СС, так как предоставляют гипотезы поведения звеньев, которые выдвигают ЛПР [1]. Согласно теории управления СС, в основу принятия решений могут быть положены экспертные, теоретико-вероятностные, вероятностно-статистические и статистические методы и модели [3-4]. Применительно к проектированию систем управления (СУ) СС экспертные методы представляются слишком «слабыми», а статистические - слишком жесткими. Наилучшее предлагаемое решение - это СИМ по МДМ, сочетающее достоинства теоретико-вероятностного и статистически-вероятностного подходов, а также компьютерную технологию метода Монте-Карло (ММК) [5-6]. Сегодня СИМ является одним из универсальных и эффективных средств исследования СС: математики используют его при проведении компьютерных экспериментов, призванных проверить и подтвердить аналитические выкладки. Прикладные специалисты видят в СИМ средство конкретных решения задач, не решаемых другими способами [9]. Системные аналитики применяют СИМ, когда объем знаний об иерархии подсистем и элементов в СС существенно меньше знаний о них [7; 12]. Менеджеры заинтересованы в управлении бизнес-процессами с помощью СИМ. Предложение использовать СИМ по МДМ при проектировании СУ СС отвечает указанной тенденции в полной мере. Идеология любого моделирования (мысленного, вербального, физического, математического, компьютерного имитационного и т.д.) СС состоит в том, чтобы, после выполнения ряда первоначальных действий, перейти из реальной среды в виртуальную, где исследуются свойства моделей СС и СУ, а затем полученные результаты «вернуть» из виртуальной среды в реальную. Эффективность и практическая значимость данного возвращения зависят от точности и адекватности используемых моделей, а также от соответствия их параметров характеристикам реальной СС. В этом смысле кумулятивность СИМ-модели предполагает также отсутствие у нее управляемых параметров, которые не имеют себе аналогов на реальном объекте - что обнаруживает ряд недостатков вероятностных моделей, наиболее часто применяемых при проектировании и управлении СС. Отечественные специалисты в области СИМ полагают, что проведение полноценного статистического исследования объекта необходимо, так как это способствует эффективности работы будущей СУ [3]. Школа Форрестера-Медоуза, напротив, не считает препятствием для проведения СИМ отсутствие надежных и достоверных исходных данных, хотя неопределенности знаний ЛПР могут быть существенно большими [4]. Вместе с тем, проведение трудоемких предварительных исследований и преодоление сложностей, возникающих при моделировании конкретных СС, явно не оправдывают себя, если итог сводится к выбору из двух-трех типовых моделей, которым примерно в равной мере лишь не противоречат - например, в соответствии с критерием Пирсона - полученные экспериментальные данные. Неопределенность исходных и промежуточных данных при проведении СИМ по МДМ в значительной мере компенсируется путем применения технологии ММК, однако детали этой компенсации представляются неясными, если речь идет о моделировании конкретных объектов. В то же время имеется возможность максимально упростить и автоматизировать первоначальные этапы СИМ, что обусловлено следующими причинами [8; 11]: - на рынке сегодня присутствуют высокопрофессиональные программные продукты, предназначенные как для обработки статистических данных, так и для идентификации соответствующих им законов распределения с оценкой параметров этих законов; - для обширного класса устойчивых (робастных) СС результаты СИМ не должны (и не будут на практике) в критической мере зависеть от правильности действий ЛПР на предварительных этапах моделирования; - неопределенность исходных и промежуточных данных в рамках СИМ обычно означает неполноту верифицированных знаний о СС, но не их отсутствие, а тем более недостаток аналогичных аксиологических знаний [12], даже с учетом их неизбежной неопределенности - что дает новые потенциальные возможности для повышения эффективности МДМ. Учет неопределенности знаний при моделировании случайных факторов Перспективная СУ является открытой СС, которая обеспечивает решение поставленных перед ней задач так, что это, во-первых, в разной степени, но устраивает всех заинтересованных ЛПР, а во-вторых, допускает возможность в дальнейшем «усилить» режим работы СУ. Системный подход диктует проектировщику необходимость, прежде всего, уяснить роль и место СУ, ее влияние на все аспекты работы СС. Одновременно возникает вопрос о методах и средствах преодоления неопределенностей, сопровождающих процесс проектирования СУ. «Когда речь идет о любой реальной системе: технической, экономической, военной, - то процесс ее проектирования никогда не может быть четко сформулирован и сведен к решению какой-либо одной задачи или даже цепочки математических задач. Противоречивость требований к конструкции и наличие ряда других неопределенностей, с которыми неизбежно сталкивается человек, проектирующий систему, приводит к тому, что неформальный анализ, поиск компромисса занимает значительное место в процессе проектирования» [1]. На практике ЛПР необходимо определиться с выбором разных знаний, поскольку совместное использование верифицируемых (объективных, строго научных, многократно проверенных и подтвержденных) и аксиологических (субъективных, интуитивных, иррациональных, гипотетических) знаний ведет к применению при проведении СИМ, наряду с математическими моделями, онтологических моделей, основанных на упрощенных соотношениях и логических правилах. Правомерность выбора, а также области применения знаний разного типа, подтверждаются комплексным тестированием разработанных СИМ-моделей, а также проверкой фрагментов СУ путем обработки полученных экспериментальных и эксплуатационных данных. Сложность этой проблемы известна разработчикам СУ нерефлекторными СС достаточно хорошо. «Как ни труден отбор надежных данных в физике, гораздо сложнее собрать обширную информацию экономического или социологического характера, состоящую из многочисленных серий однородных данных… В этих обстоятельствах безнадежно добиваться слишком точных определений величин, вступающих в игру. Приписывать неопределенным по самой своей сути величинам какую-то особую точность бесполезно и нечестно, и, каков бы ни был предлог, применение точных формул к этим слишком вольно определяемым величинам есть не что иное, как обман и пустая трата времени» [10]. В то же время: «Многие не признают потенциальной пользы модели, основываясь на том, что у нас нет достаточных данных для моделирования. Они уверены, что первым шагом должен быть широкий сбор статистических сведений. Верно же как раз обратное». И далее: «Мнение о том, что математическая модель не может быть построена, пока не будут полностью известны каждая константа и функциональная зависимость, является недоразумением» [4]. Принимая во внимание эти и другие имеющиеся (в чем-то схожие, в чем-то противоречащие друг другу) точки зрения, МДМ предлагает схему учета и моделирования неопределенностей в интересах формирования исходных данных для проведения СИМ, показанную на рис. 1. Надпись: Экспериментальные и эвристические методы Рис. 1. Схема учета и моделирования неопределенностей по МДМ Согласно рис. 1, методы учета влияния неопределенности знаний ЛПР (СВ, моделирующих случайные факторы) на результаты СИМ последовательно ведут разработчиков СУ от модели в виде равномерного закона согласно принципу безразличия (что соответствует максимальной неопределенности знаний ЛПР) к финитным устойчивым моделям (включая нормальный закон) в условиях применимости предельных теорем классической теории вероятностей, и далее - к статистическим моделям, полученным в результате идентификация законов распределения СВ (см. методику проведения СИМ) и предложению использовать реальные данные, полученные при обследовании объекта СИМ, если такая возможность имеется - что соответствует минимальной и неустранимой неопределенности знаний. Во всех этих случаях задачей предварительного исследования объекта остается определение оценок числовых параметров СВ, осуществляемое экспериментальным и эвристическим методами. Более подробно разделение случайных факторов на основные и второстепенные, а также другие вопросы, связанные с анализом влияния неопределенности и кумулятивности исходных данных на эффективность СИМ, будут рассмотрены во второй части статьи. Рис. 2. Схема тестового бизнес-процесса «Предоставление государственных и муниципальных услуг» МФЦ Вербальная модель тестового бизнес-процесса Схема выбранного в качестве тестовой СИМ-модели бизнес-процесса «Предоставление государственных и муниципальных услуг» МФЦ представлена на рис. 2. Бизнес-процесс начинается с поступления заявки на оказание услуги в МФЦ - интенсивность поступления заявок обозначена на рис. 2 как СВ23, это случайная величина, которая изменяется согласно расписанию интенсивностей, так как число заявителей в час зависит от временного периода в течение дня (напомним, что для краткости все случайные величины именуются СВ). Рис. 2. (окончание) По приходу в МФЦ заявитель попадает к регистратору, который принимает у него необходимый для оказания услуги комплект документов (КД). Длительность приема КД составляет СВ2 - поскольку услуги бываю разные и, соответственно, в КД входит разное число документов, которые нужно принять и, при необходимости, сканировать копии. Далее регистратор делает вывод о полноте КД, который может быть полным (если заявитель принес все обязательные документы) или неполным (если в КД не хватает ряда документов - см. СВ16). Если КД неполный, то заявителя отправляют за недостающими документами, и МФЦ ожидает эти документы - время ожидания есть СВ2, так как заявитель может принести эти документы либо в этот же день, либо в течение нескольких рабочих дней. После того, как заявитель предоставит в МФЦ недостающие документы, регистратор принимает их - длительность приема является СВ3. Затем регистратор проверяет КД на предмет того, соответствуют ли данные КД требованиям предоставления услуги - длительность составляет СВ4, после этого он принимает решение, сможет ли МФЦ оказать услугу или вынужден отказать заявителю (см. СВ17). Если состоялось решение в пользу оказания услуги, регистратор передает КД контролеру для дальнейшего анализа длительностью СВ5 о необходимости межведомственных запросов (МВ-запросов) в соответствующие органы государственной власти (ОГВ) - эти запросы могут быть промежуточными (для получения промежуточных документов, которые необходимы для предоставления услуги) и результирующими (для получения итогового результата предоставления услуги), механизм отправки промежуточных и результирующих (итоговых) запросов является одинаковым. Если необходимости в отправке МВ-запроса в ОГВ нет, процесс переходит на этап формирования результата предоставления услуги; если есть - контролер готовит документы для отправки запроса. Обычно для отправки МВ-запроса требуются не все документы из КД, а только некоторые, и суть подготовки заключается в определении их перечня в соответствии с требованиями ОГВ - длительность подготовки документов для отправки МВ-запроса в ОГВ является СВ6. В зависимости от специфики и содержания МВ-запросы могут быть отправлены в ОГВ электронным способом (см. СВ19) или курьером. Запрос отправляется электронным способом, если в автоматизированной информационной системе МФЦ имеется соответствующая интеграция с ОГВ - в этом случае сотруднику МФЦ необходимо определить параметры, которые у каждого запроса свои, и отправить его в ОГВ. Длительность подготовки электронного запроса есть СВ7; запрос может быть успешно выполнен или не выполнен - см. СВ20. В случае выполнения запроса контролер получает его результат, в случае невыполнения - отправляет запрос с курьером. Для отправки запроса с курьером контролер готовит посылку с документами в ОГВ - длительность подготовки составляет СВ8, после чего курьер доставляет ее в ОГВ - длительность доставки СВ9. Получив КД, сотрудник ОГВ принимает его и приступает к анализу (СВ10), по результатам которого делает вывод, все ли документы, необходимые для выполнения запроса у него на руках - см. СВ21. В случае отсутствия необходимых документов сотрудник ОГВ сообщает МФЦ об этом - время ожидания недостающих документов из МФЦ соответствует СВ11, после чего процесс возвращается на этап подготовки посылки в ОГВ. При наличии всех требуемых документов сотрудник ОГВ формирует результат запроса - длительность оформления результата составляет СВ12.Далее курьер доставляет результат запроса в МФЦ - длительность доставки результата запроса есть СВ13. Если МВ-запрос был выполнен (электронным способом или курьером), процесс переходит на этап получения контролером МФЦ результата запроса. Если осталась необходимость в отправке МВ-запросов (см. СВ22), процесс переходит на этап подготовки документов для отправки МВ-запросов в ОГВ до тех пор, пока каждый запрос в рамках данной услуги не будет выполнен. Если в рамках данной услуги нет необходимости в отправке МВ-запросов в ОГВ (отсутствуют промежуточные запросы, а типовой вариант результата услуги имеется в МФЦ) или все МВ-запросы были выполнены, то процесс переходит на этап формирования результата предоставления услуги, целью которого является подготовка итогового документа для выдачи заявителю. Далее контролер сообщает заявителю о готовности результата услуги - время ожидания заявителя составляет СВ14. В завершение сотрудник МФЦ выдает результат услуги заявителю (время выдачи результата услуги СВ15), после чего услуга считается оказанной. Моделирующий алгоритм бизнес-процесса Моделирующий алгоритм является ядром СИМ-модели, благодаря которому имитируется (воспроизводится) функционирование моделируемого объекта подобно тому, как это происходит в реальности. Известны два типа моделирующих алгоритмов: с детерминированным шагом и со случайным шагом. Независимо от типа алгоритм раскладывает процесс моделирования на простейшие шаги, последовательность выполнения которых формирует соответствующую СИМ-модель: алгоритм должен быть прост и понятен, логично выстроен и подробно описан. Для тестового бизнес-процесса выбран механизм продвижения модельного времени со случайным шагом. Первоначально составляется обобщенный моделирующий алгоритм, «раскладывающий» имитацию на ряд укрупненных блоков, логично следующих друг за другом. Далее блоки укрупненного алгоритма детализируются, образуя более подробный, детальный алгоритм. Моделируемый бизнес-процесс предоставления услуги можно представить, как работу системы массового обслуживания (СМО), где происходит поступление и обслуживание заявок. Поступление заявок реализуют приходящие в МФЦ заявители, их поток задается расписанием интенсивностей (см. СВ23), затем эти заявки обслуживаются и покидают СМО: либо удовлетворив потребности заявителей, либо нет (см. СВ17). Рис. 3. Укрупненный алгоритм моделирования В укрупненном виде моделирование тестового бизнес-процесса можно разделить на два этапа: моделирование поступления заявок и моделирование обслуживания заявок. При поступлении в СМО заявки срабатывает блок сравнения, где осуществляется проверка, закончен период моделирования Т (то есть готова ли СМО обслужить ее), или нет. Также необходимы вспомогательные блоки, реализующие следующие процедуры: ввод исходных данных; объявление и обнуление переменных; расчет итоговых показателей; вывод результатов пользователю. Полученный укрупненный алгоритм приведен на рис. 3. Алгоритм начинается с ввода исходных данных пользователем - это блок 1, где необходимо ввести значения параметров СИМ-модели, с помощью которых пользователь может менять условия моделирования, а также параметры законов распределения СВ. Блок 2 предназначен для объявления и обнуления переменных, используемых в модели - эти переменные будут менять свои значения в процессе моделирования, а к моменту окончания должны содержать итоговые значения, необходимые пользователю. Далее следует блок 3, это один из основных блоков, предназначенный для моделирования поступления заявок в СМО согласно закону распределения вероятностей, а также для учета этих заявок. В блоке 4 происходит сравнение времени поступления очередной заявки с периодом моделирования Т - если время не выходит за пределы моделирования, то заявка передается блоку 5 для последующей обработки. Если же время выходит за период Т, то осуществляется переход к блоку 6. Блок 5 моделирует обслуживание заявки и передает управления блоку 3 для моделирования поступления новой заявки. Переход к блоку 6 означает окончание периода моделирования Т - здесь производится расчет итоговых показателей, характеризующих функционирование процесса в течение заданного времени. Заключительным шагом является срабатывание блока 7, который отвечает за вывод результатов пользователю. Детальный алгоритм моделирования показан на рис. 4. Он также начинается в блоке 1 с ввода в СИМ-модель следующих исходных данных: - период моделирования T; - вероятность отсутствия документов в КД Pnehdoсkd; - вероятность отказа в предоставлении услуги Potkus; - вероятность отсутствия МВ-запросов в ОГВ Potszap; - вероятность отсутствия документов для выполнения запроса Pnehdoсzap; - вероятность невыполнения электронного запроса Pnelzap; - вероятность невыполнения требуемых МВ-запросов Pnvzap; - вероятность отправки запроса электронно Potelzap; - параметры законов распределения СВ1-СВ15. В блоке 2 происходит объявление и обнуление следующих переменных СИМ-модели: - текущее модельное время t; - время поступления последней заявки на оказание услуги tpost; - текущее число поступивших заявок на оказание услуги kpost; - текущее число оказанных услуг kokaz; - текущее число отказов kotk; - текущее число МВ-запросов в ОГВ kzapogv; - текущее число невыполненных электронных запросов в ОГВ knelzap; - текущее число выполненных электронных запросов в ОГВ kvelzap; - текущее число отправленных запросов в ОГВ курьером kzapkur. Рис. 4. Детальный алгоритм моделирования Рис. 4 (продолжение) Блок 3 моделирует поступление очередной заявки - для этого генерируется СВ23, которая прибавляется к времени поступления последней заявки tpost = tpost + СВ23. В блоке 4 поступление последней заявки сравнивается с периодом моделирования: если tpost < = T, то управление передается в блок 5, где счетчик поступления заявок kpost увеличивается на единицу. Если же tpost > T, то осуществляется переход к блоку 38. Далее в блоке 6 осуществляется моделирование длительности приема документов СВ1 и модельное время продвигается на соответствующую величину: tpost = tpost + СВ1. В блоке 7 моделируется возможное отсутствие документов в КД (см. СВ16) и блок 8 осуществляет сравнение смоделированного значения СВ16 с исходно заданным параметром: если СВ16 < = Pnehdockd, то в КД не хватает обязательных документов, и алгоритм передает управление в блок 9, где моделируется время ожидания недостающих документов и модельное время продвигается на соответствующую величину: t = t + СВ2. Если же СВ16 > Pnehdockd, что соответствует наличию всех документов в КД, управление сразу переходит к блоку 12, где моделируется СВ17. Рис. 4 (окончание) Блок 10 моделирует длительность приема недостающих документов СВ3 и обеспечивает продвижение модельного времени на величину t = t + СВ3. Блок 11 моделирует длительность анализа КД СВ4 и обеспечивает продвижение модельного времени на величину t = t + СВ4. В блоке 12 моделируется возможный отказ в предоставлении услуги СВ17; в блоке 13 смоделированное значение СВ17 сравнивается с исходно заданным параметром: если СВ17 < = Potkus, что означает отказ заявителю в предоставлении услуги, алгоритм передает управление блоку 3, где моделируется поступление новой заявки. Если СВ17 > Potkus, то есть услуга будет оказана заявителю, алгоритм передает управление блоку 14, где моделируется длительность анализа поступившего дела СВ5 и осуществляется продвижение модельного времени на величину t = t + СВ5. В блоке 15 моделируется возможное отсутствие необходимости в отправке МВ-запроса в ОГВ СВ18; в блоке 16 осуществляется сравнение смоделированного значения СВ18 с исходно заданным параметром: если СВ18 < = Potszap (это означает, что необходимость МВ-запросов в ОГВ отсутствует), алгоритм передает управление в блок 36, где осуществляются моделирование срока ожидания заявителем СВ14 и продвижение модельного времени на величину t = t + СВ14. В противном случае, при СВ18 > Potszap, есть необходимость в отправке МВ-запросов в ОВГ и алгоритм передает управление в блок 17, где увеличивается счетчик числа МВ-запросов в ОГВ kzapogv = kzapogv + 1. Блок 18 моделирует длительность подготовки документов для отправки МВ-запроса в ОГВ СВ6 и обеспечивает продвижение модельного времени на величину t = t + СВ6. В блоке 19 моделируется возможная отправка запроса электронным способом (см. СВ19); блок 20 сравнивает смоделированное значение СВ19 с исходно заданным параметром: если СВ19 < = Potelzap, это означает, что осуществляется отправка запроса электронным способом и алгоритм передает управление в блок 21, где моделируется длительность подготовки электронного запроса СВ7. В противном случае, при СВ19 > Potelzap, что соответствует необходимости отправки МВ-запроса с курьером, алгоритм передает управление блоку 26. Блок 21 моделирует длительность подготовки электронного запроса СВ7 и обеспечивает продвижение модельного времени на величину t = t + СВ7. Блок 22 моделирует возможное невыполнение запроса электронным способом СВ20, в блоке 23 осуществляется сравнение смоделированного значения СВ20 с исходно заданным параметром: если СВ20 > Pnelzap, это означает, что электронный запрос успешно выполнен, и алгоритм передает управление блоку 25, где срабатывает счетчик числа выполненных электронных МВ-запросов в ОГВ: kvelzap = kvelzap + 1, после чего управление переходит в блок 34. В противном случае, при СВ20 < = Pnelzap, то есть электронный запрос не был успешным, управление переходит в блок 24, где срабатывает счетчик числа невыполненных электронных запросов в ОГВ: knelzap = knelzap + 1. Блок 26 моделирует СВ8 - длительность подготовки посылки в ОГВ и продвигает модельное время на величину t = t + СВ8. В блоке 27 осуществляются моделирование СВ9 - это длительность доставки посылки в ОГВ, а также продвижение модельного времени на величину t = t + СВ9. Блок 28 моделирует СВ10 - длительность анализа КД в ОГВ и обеспечивает продвижение модельного времени t = t + СВ10. В блоке 29 моделируется возможная нехватка документов для выполнения запроса СВ21; блок 30 сравнивает смоделированное значение СВ21 с исходно заданным параметром: если СВ21 < = Pnehdoczap (это означает, что в КД не хватает обязательных документов для выполнения запроса), алгоритм передает управление блоку 31, где осуществляется моделирование СВ11 и продвижение модельного времени t = t + СВ11. Затем управление передается блоку 26 для доставки из МФЦ в ОГВ недостающих документов - в противном случае, если СВ21 > Pnehdoczap, то есть в КД присутствуют все обязательные документы, управление передается блоку 32, который моделирует длительность оформления результата запроса СВ12 и продвижение модельного времени t = t + СВ12. Блок 33 моделирует длительность доставки результата запроса СВ13 и обеспечивает продвижение модельного времени на величину t = t + СВ13. В блоке 34 моделируется возможное невыполнение требуемых МВ-запросов СВ22; блок 35 сравнивает смоделированное значение СВ22 с исходно заданным параметром: если СВ22 < = Pnvzap (это означает, что невыполненные МВ-запросы остались), управление передается блоку 17, и эта процедура будет продолжаться до тех пор, пока по всем МВ-запросам не будут получены результаты. В противном случае, если СВ22 > Pnvzap, то есть МВ-запросы выполнены все, управление передается блоку 36, где моделируется время ожидания заявителя СВ14 и осуществляется продвижение модельного время t = t + СВ14. Блок 37 моделирует время выдачи результата услуги заявителю СВ15 и обеспечивает продвижение модельного времени на величину t = t + СВ15, после чего управление передается блоку 3. Завершают алгоритм срабатывание блока 38, в котором производится расчет итоговых значений kotk и kzapkogv, и блок 39 - осуществляющий вывод пользователю результатов моделирования в виде текущих значений kpost; kokaz; kotk; kzapogv; knelzap; kvelzap, kzapkogv. Программная реализация моделируемого бизнес-процесса Среда имитационного моделирования AnyLogic [8; 11] - это первый и единственный пока программный инструмент отечественной разработки, объединивший методы системной динамики, «процессного» дискретно-событийного и агентного моделирования в одном языке Java и в одной среде разработки СИМ-моделей. Гибкость AnyLogic позволяет отражать динамику сложных и разнородных экономических и социальных систем на любом желаемом уровне абстракции; среда поддерживает множество разнообразных типов экспериментов с моделями: простой прогон, сравнение прогонов, варьирование параметров, применение метода Монте-Карло (ММК), анализ чувствительности, калибровка (тестирование) и оптимизация СИМ-модели, а также проведение эксперимента по сценарию пользователя. Имитационная модель, построенная в среде AnyLogic, позволяет наглядно и убедительно выявлять узкие места бизнес-процесса, а затем устранять их, повышая уровень удовлетворенности клиентов, а также прогнозировать оптимальное время работы СМО на каждом этапе реализации бизнес-процесса. Модель тестового бизнес-процесса строится с «нуля»: принимается, что МФЦ представляет собой СМО, построение СИМ-модели которой выполняется при помощи элементов библиотеки AnyLogic, где в качестве агентов фигурируют заявки на оказание услуг и для построения СИМ-модели используются следующие элементы: - Source - создает агентов (заявки в СМО); - Queue - моделирует очередь агентов, ожидающих приема объектами; - Service - «захватывает» для агента заданное количество ресурсов, задерживает их, а затем освобождает захваченные им ресурсы; - ResourcePool - задает набор ресурсов, которые могут захватываться и освобождаться агентами с помощью объекта Service (моделирует узел обслуживания с использованием ресурсов); - Delay - задерживает агентов на заданный период времени (моделирует узел обслуживания без использования ресурсов); - SelectOutput - этот объект направляет входящие заявки в один из двух выходных портов в зависимости от выполнения заданного (детерминистического или вероятностного) условия; - Sink - принимает отработанные заявки, используется в качестве конечной точки потока агентов; - ТimeMeasureStart и TimeMeasureEnd - пара объектов, позволяющая измерить время, проведенное агентами между двумя точками диаграммы процесса, в данном случае они используются для измерения среднего времени предоставления услуги; - Batch - преобразует заданное число поступающих в объект агентов в одного агента-партию, объект используется для накопления документов для групповой отправки в ОГВ; - Unbatch - извлекает всех агентов, содержащихся в поступающем агенте (который представляет собой партию агентов), и пересылает их далее поочередно через выходной порт, сохраняя порядок, в котором они хранились в партии. Рис. 5. Схема тестового бизнес-процесса «Предоставление государственных и муниципальных услуг» в среде AnyLogic» Элементы среды AnyLogic, задействованные в схеме моделирования тестового бизнес-процесса, а также дополнительные сведения о них, представлены в таблице 1. Таблица 1. Элементы AnyLogic в схеме бизнес-процесса Имя объекта Элементы библиотеки AnyLogic Наименование случайной величины Переменные, параметры Дополнительные сведения PostZayavk Source СВ23 - интенсивность поступления заявок (чел/час) kpost Моделирует заявки согласно расписанию интенсивностей и ведет подсчет числа поступивших заявок на оказание услуги: kpost = kpost + 1 Nakopitel Queue - - DlPriemDoc_СВ1 Service СВ1 - длительность приема документов SV1 Тип ресурса: registrator (регистратор) registrator ResourcePool - - Количество ресурсов 6 чел. задано расписанием доступности NehDocKD SelectOutput СВ16 - возможное отсутствие документов в КД Pnehdockd Задается параметром Вероятность отсутствия документов в КД Pnehdockd VrOzhNedDoc_СВ2 Delay СВ2 - время ожидания недостающих документов SV2 DlPrNedD_СВ3 Service СВ3 - длительность приема недостающих документов SV3 Тип ресурса: registrator (регистратор). DlAnKDReg_СВ4 Service СВ4 - длительность анализа КД регистратором SV4 Тип ресурса: registrator (регистратор). OtkPredUs SelectOutput СВ17 - возможный отказ в предоставлении услуги Potkus Задается параметром Вероятность отказа в предоставлении услуги Potkus Otkaz Sink - kotk Используется в качестве конечной точки потока агентов, если СВ17 < = Potkus; ведет подсчет числа отказов kotk = kotk + 1 DlAnPosD_СВ5 Service СВ5 - длительность анализа поступившего КД SV5 Тип ресурса: kontroler (контролер). OtNeobOtMV SelectOutput СВ18 - возможное отсутствие необходимости в отправке МВ-запросов в ОГВ Potszap Задается параметром Вероятность отсутствия МВ-запросов в ОГВ Potszap DlPodDOtMV_СВ6 Service СВ6 - длительность подготовки документов для отправки МВ-запроса в ОГВ SV6 Тип ресурса: kontroler (контролер). VozOtZapEl SelectOutput СВ19 - возможная отправка запроса электронным способом Potelzap Задается параметром Вероятность невыполнения электронного запроса Pnelzap DlPodgElZap_СВ7 Service СВ7 - длительность подготовки электронного запроса SV7 Тип ресурса: kontroler (контролер). VozNevZapEl SelectOutput СВ20 - возможное невыполнение электронного запроса Pnelzap knelzap kvelzap Задается параметром Вероятность невыполнения электронного запроса Pnelzap; ведет подсчет числа невыполненных электронных запросов в ОГВ: knelzap = knelzap + 1; ведет подсчет числа выполненных электронных запросов в ОГВ: kvelzap = kvelzap + 1 DlPodPosOGV_СВ8 Service СВ8 - длительность подготовки посылки в ОГВ SV8 Тип ресурса: kontroler (контролер). DlDosPosOGV_СВ9 Service СВ9 - длительность доставки посылки в ОГВ SV9 Тип ресурса: kuryer (курьер). kuryer ResourcePool - - Количество ресурсов 1 чел. задано расписанием доступности DlAnalKDvOGV_10 Service СВ10 - длительность анализа КД в ОГВ SV10 Тип ресурса: sotrudnik_OGV (сотрудник ОГВ) sotrudnik_OGV ResourcePool - - Количество ресурсов 10 чел. задано расписанием доступности VozNehDocVipZ SelectOutput СВ21 - возможное отсутствие документов для выполнения запроса Pnehdoczap Задается параметром Вероятность нехватки документов для выполнения запроса Pnehdoсzap VrOzhNedDocVipZ_СВ11 Delay СВ11 - время ожидания недостающих документов из МФЦ SV11 DlOfRezZap_СВ12 Service СВ12 - длительность оформления результата запроса SV12 Тип ресурса: sotrudnik_OGV (сотрудник ОГВ) DlPerRezZap_СВ13 Service СВ13 -длительность перевозки результата запроса SV13 Тип ресурса: kuryer (курьер). VozNevTrMV SelectOutput СВ22 - возможное невыполнение требуемых МВ-запросов Pnvzap Задается параметром Вероятность невыполнения требуемых МВ-запросов Pnvzap KolZapOGV Delay - kzapogv Объект имеет нулевое время задержки, так как он необходим только для подсчета промежуточного значения - числа запросов в ОГВ: kzapogv = kzapkur + kvelzap VrOzhZayvit_СВ14 Delay СВ14 - время ожидания заявителя SV14 VrVidRezUs_СВ15 Service СВ15 - время выдачи результата услуги заявителю SV15 kokaz Тип ресурса: registrator (регистратор); ведет подсчет текущего числа оказанных услуг: kokaz = kokaz +1 Zavershenie Sink - - Используется в качестве конечной точки потока агентов, когда услуга считается предоставленной Заключение В первой части статьи представлена СИМ-модель тестового бизнес-процесса «Предоставление государственных и муниципальных услуг» МФЦ областного уровня, необходимая для исследования кумулятивности исходных данных, оказывающей влияние на эффективность СИМ сложной системы нерефлекторного типа.

About the authors

Kristina Vladimirovna Vaulina

Povolzhsky State University of Telecommunications and Informatics

Oleg Nikolayevich Maslov

Povolzhsky State University of Telecommunications and Informatics

Email: maslov@psati.ru

References

Supplementary files