Роль и место имитационного моделирования в управлении предприятием

Основная цель управления бизнесом в терминах IDEF0 заключается в построении модели ТО-BE («как будет»). Естественно предположить, что данная модель базируется на реальном положении дел (AS-IS). Однако в отличие от модели AS-IS модель ТО-BE носит предписывающий характер. В ней должны быть учтены и исправлены все недостатки, выявленные в процессе анализа модели AS-IS.

Очевидно, что процесс построения обеих моделей носит итерационный характер и подчиняется одинаковым правилам моделирования.

В общем случае процесс моделирования (т.е. построение моделей AS-IS и ТО-BE) включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели, а также уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе деятельности организации.

В определенном смысле моделирование объединяет итеративный процесс создания модели, нотации, управляющие конфигурацией модели, язык ссылок для диаграмм, язык функций моделей с графическим языком описания системы, а также рекомендации, но реализации аналитических проектов. Нотации, управляющие конфигурацией, гарантируют, что новые диаграммы будут корректно встроены в иерархическую структуру модели. Язык ссылок, правила сокращений для ссылок, адресованных к отдельным частям диаграммы, облегчают оформление замечаний при рецензировании модели. Язык функций позволяет декларативно определять правила работы системы, что часто является особенно важным завершающим шагом в описании системы.

Высокая эффективность процесса моделирования в стандарте IDEF0 обусловлена его организацией, в основе которой лежит разделение функций, выполняемых участниками создания проектов: эксперты являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а комиссия технического контроля принимает и утверждает модель.

В процессе моделирования сведения об изучаемой системе получают с помощью методов экспертного опроса.

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

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

Создание модели (блок 2 на рис. 4.60) — это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной предметной области, представляя их в виде одной или нескольких диаграмм. Процесс создания модели осуществляется с помощью специального метода детализации ограниченного структурного элемента. Автор вначале анализирует объекты, входящие в систему, а затем использует полученные знания для анализа функций системы. На основе этого анализа создается диаграмма, в которой объединяются сходные объекты и функции. Этот конкретный путь проведения анализа и документирования его результатов является особенностью всего процесса IDEF0- моделирования.

Модели создаются исходя из действительной ситуации и проходят через серию последовательных улучшений до тех пор, пока они в точности не будут представлять реальную (для модели AS-IS) или желаемую (для модели ТО-BE) ситуацию. Одной из основных компонент при этом является итеративное рецензирование, в процессе которого автор и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом «автор — читатель».

Цикл «автор — читатель» начинается в тот момент, когда автор принимает решение распространить информацию о какой-либо части своей.

Рис. 4.60. Процесс моделирования работы с целью получения отзыва о ней. Материал для распространения оформляется в виде «папок» — небольших пакетов с результатами работы, которые критически обсуждаются другими специалистами в течение определенного времени. Сделанные письменные замечания также помещаются в папку в виде нумерованных комментариев. Папки с замечаниями являются, таким образом, обратной связью, которую авторы получают на свою работу. Читатели — это те, кто читает и критикует создаваемую модель (блок 4 на рис. 4.60), а затем помещает замечания в папки. Их работа возможна благодаря тому, что графический язык диаграмм позволяет создавать диаграммы и модели, которые можно легко и быстро читать. Простота графического языка потому не случайна: она позволяет получить представление о системе, на основе которого можно дать обоснованное заключение о достоверности модели.

Обычно отдельная папка рецензируется одновременно несколькими читателями, и все их замечания поступают к определенному сроку к автору. Затем автор отвечает на каждое замечание и обобщает критику, содержащуюся в замечаниях. С помощью таких обсуждений можно довольно быстро обмениваться идеями. Таким образом, поддерживается как параллельный, так и асинхронный просмотр модели, что является наиболее эффективным способом распределения работы в коллективе.

Как правило, модель редко создается одним автором. На практике над различными частями модели могут совместно работать множество авторов, потому что каждый функциональный блок модели представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован. Таким образом, модель сама координирует работу коллектива авторов, в то время как процесс моделирования координирует совместное рецензирование возникающих идей.

Организация своевременной обратной связи имеет огромное значение для эффективного моделирования, потому что устаревшая информация потенциально способна свести на нет все усилия по разработке модели. Поэтому выделяется специальная роль наблюдателя за процессом рецензирования. На рис. 4.60 показано, что эту роль выполняет библиотекарь, который является главным координатором процесса моделирования, обеспечивая своевременное и согласованное распространение рабочих материалов. Библиотекарь распространяет полученные от авторов папки, контролирует их движение, рассылает напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей. Кроме того, библиотекарь печатает законченные модели после того, как они одобрены и приняты к использованию.

Модели создаются с конкретной целью, и эта цель записана на диаграмме АО модели. В каком-то смысле эта цель определяет, как будет использоваться модель. Следовательно, как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели, например для обеспечения и поддержания реинжиниринга бизнес-процессов организации.

В процессе моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа, называемая условно комиссией технического контроля (блок 5 на рис. 4.61), отвечает за контроль качества моделей, создаваемых авторами проекта. Комиссия следит за выполняемой работой и ее соответствием конечным целям всего проекта. Специалисты комиссии обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей.

Модели, которые достигли желаемого уровня детализации и точности с точки зрения технических требований, направляются в комиссию технического контроля для обсуждения и утверждения. Комиссия оценивает, насколько применима данная модель. Если модель признана комиссией применимой, она публикуется (утверждается). В противном случае авторам направляются замечания для необходимой доработки.

Следует отметить, что в ходе создания модели ТО-BE в настоящее время все чаще применяются новейшие достижения в области анализа данных и, прежде всего, OLAP-технологии и технологии углубленного непараметрического анализа Data Mining.

Таким образом, результатом моделирования в стандарте IDEF0 являются модели AS-IS и производная от нее — ТО-BE, как показано на рис. 4.61. При этом модель ТО-BE — это желаемое (предполагаемое) состояние бизнеса в будущем, к которому следует стремиться. Если это так, то модель ТО-BE в принципе не может быть реализована полностью в перспективе.

Рис. 4.61. Модели стандарта IDEF0.

Причины этого очевидны:

• • высокая динамика изменения внешних условий и, как следствие, конкретных требований рынка;
• • возможное перераспределение акцентов потребительского рынка;
• • возрастание нестабильности цен;
• • возможное изменение приоритетов развития бизнеса и др.

Следовательно, без дополнительного анализа адекватно спрогнозировать успешность перехода к модели ТО-BE вряд ли представляется возможным. Поэтому на рис. 4.61 переход от модели AS-IS к модели ТО-ВЕ показан пунктиром. Еще раз отметим, что в этом случае имитационное моделирование позволит:

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

С учетом этого рис. 4.61 можно представить в виде рис. 4.62.

Рис. 4.62. Место имитационного моделирования в управлении развитием бизнеса.

Следует отметить, что функциональное моделирование как средство разработки моделей AS-IS и ТО-BE совсем не обязательно должно осуществляться с использованием нотаций IDEF. Среди лидеров производства средств моделирования бизнес-процессов и немецкая фирма IDS ScheerAG (ARIS), и французская фирма Mega (Mega Process), и американские фирмы.

Sybase (PowerDesigner) и Meta Software (WorkFlow Modeler) и др. Однако это нисколько нс меняет общего подхода, показанного на рис. 4.62. Более того, осознавая насущную необходимость применения имитационного моделирования, некоторые программные продукты имеют встроенные средства имитационного моделирования (например, ARIS и Mega Process).

Картина была бы не полной, если не отметить еще одно обстоятельство. После получения так называемой улучшенной модели TO-BE (Improved TO-BE) все-таки остается открытым вопрос об оптимальном переходе к ней, т. е. об управлении проектом перехода. Очевидно, что в этом случае необходимо использовать известные средства управления проектами, как показано на рис. 4.63.

При отслеживании задач в проекте для анализа хода выполнения удобно использовать следующие параметры: длительность, трудозатраты, дату начала, дату окончания и затраты.

Фактические данные отражают окончательные сведения о выполнении задачи. Первоначально планируются длительности, трудозатраты, затраты, даты начала и окончания. Затем вводятся сведения о ходе выполнения, или фактические данные, для задач, и создается реальная картина выполнения проекта. Фактические данные отражают реальные затраты на выполнение задачи, количество дней, потребовавшихся на ее выполнение, фактическую длительность и фактические даты начала и окончания.

Важнейшей характеристикой выполнения проекта является критический путь.

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

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

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

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

Рис. 4.63. Информационно-технологическая поддержка развития бизнеса.

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

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

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

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

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

Анализ освоенного объема — это способ определения производительности проекта. Он показывает, какая часть бюджета должна была бы быть израсходована, в виде суммы трудозатрат, выполненных на данный момент, и базовых затрат на задачу, назначения и ресурсы.

В основе анализа освоенного объема лежат три основных значения:

• 1) базовые затраты отдельных задач в соответствии с планом проекта, определенные как сумма стоимости ресурсов, назначенных этим задачам, и любых фиксированных затрат, связанных с задачами. Это базовая стоимость запланированных работ (БСЗР). Значение БСЗР — это базовые затраты на выбранную дату отчета о состоянии;
• 2) фактические затраты, необходимые для завершения всех задач или части задач на дату отчета о состоянии. Это фактическая стоимость выполненных работ (ФСВР). Обычно фактические затраты коррелируют с фактическими трудозатратами;
• 3) значение стоимости выполненных работ на дату отчета о состоянии, выраженное в денежных единицах. Фактически это значение освоенного объема по выполненным работам, оно называется базовой стоимостью выполненных работ (БСВР). Это значение рассчитывается для каждой отдельной задачи, но анализируется на более общем уровне (как правило — на уровне проекта).

Анализ освоенного объема всегда выполняется на указанную дату отчета о состоянии. Это может быть текущая дата или любая дата, предшествующая текущей.

Основные положения теории управления проектами приведены, чтобы показать, что основной целью управления в данном случая является оптимизация процесса перехода к модели Improved TO-BE (см. рис. 4.63). В контексте управления бизнесом это означает, что недостаточно иметь желаемую модель организации хозяйственной деятельности. Для достижения этого состояния необходимы механизмы поддержки перехода к перспективе.

Таким образом, управление бизнесом основывается на циклической реализации информационно-технологической цепочки: модель текущего состояния (AS-IS) —" идеальная модель желаемого состояния (ТО-ВЕ) —" —" реальная модель желаемого состояния (Improved ТО-ВЕ) —> переход к желаемому состоянию (Project Management). Важнейшую роль при этом играет имитационное моделирование, которое обеспечивает наиболее обоснованное формирование модели Improved ТО-ВЕ, являющейся, по сути, основным ориентиром развития бизнеса.