Информационные системы в информационном менеджменте

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Информационные системы в информационном менеджменте

Информационные системы в информационном менеджменте

17

Содержание

• Введение
• 1. Обследование предметной области
• 1.1 Краткое описание предприятия
• 1.2 Описание деятельности подразделения
• 2. Анализ предприятия и построение диаграмм
• 2.1 Построение модели деятельности
• 2.2 Функционально-стоимостной анализ
• 2.3 Построение организационной диаграммы и диаграммы Swim Lane
• 2.4 Построение диаграмм Node Tree и IDEF3 Scenario
• 3. Создание имитационной модели
• Заключение
• Библиографический список

BPwin предоставляет аналитику два инструмента для оценки модели - стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации истинных движителей затрат в организации.

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

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

ABC включает следующие основные понятия:

1. Объект затрат - причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат;

2. Движитель затрат - характеристики входов и управлений paботы, которые влияют на то, как выполняется и как долго длится работа;

3. Центры затрат, которые можно трактовать как статьи расхода.

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Edit/Model Properties), вкладка ABC Units.

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Dictionary (меню Dictionary/Cost Center).

Основные центры затрат учета ТМЦ ОАО «Омский бекон»

Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions, подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх.

Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report (меню Tools/Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат. Отчет Activity Cost Report представлен в приложении.

Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню Model/Model Properties), вкладка Display, опции ABC Data и ABC Units.

BPwin содержит набор инструментов для моделирования организационной структуры предприятия. К ним относятся словари - словарь ролей и словарь групп ролей.

Словарь групп ролей Role Group Dictionary позволяет создать и определить свойства групп ролей. Группы ролей могут использоваться как на организационных диаграммах, так и на диаграммах Swim Lane. В качестве значения группы ролей может быть название предприятия, отдела, цеха или название региона, города и т. д. Для каждой группы ролей может быть внесено описание, указано изображение, предварительно импортированное в словаре изображений, и указана важность группы ролей.

Рис. 9.

Словарь ролей Role Dictionary определяет должность или позицию конкретного исполнителя. Каждой роли может соответствовать одна или несколько групп ролей. Кроме того, в словаре ролей для каждой роли можно внести определение, связать роль с изображением и геометрической фигурой, указать важность роли.

Рис. 10.

Для построения организационной диаграммы сначала были заполнены словари: словарь ролей и словарь групп ролей.

Рис. 11.

Диаграмма Swim Lane позволяет явно описать роли и ответственности исполнителей в конкретной технологической операции. Эта диаграмма разделена на горизонтальные полосы, с каждой полосой может быть связана роль или UDP типа Text List. Полоса может содержать объекты диаграммы IDEF3 (UOW, перекрестки и объекты ссылок), относящиеся к соответствующей роли. На втором шаге следует выбрать роли, на основе которых будет создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Line.

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

Рис. 12.

В IDEF3 декомпозиция используется для детализации работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание включает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.

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

Имитационное моделирование - это метод, позволяющий строить модели, учитывающие время выполнения функций. Полученную модель можно “проиграть” во времени и получить статистику происходящих процессов так, как это было бы в реальности. В имитационной модели изменения процессов и данных ассоциируются с событиями. “Проигрывание” модели заключается в последовательном переходе от одного события к другому. Обычно имитационные модели строятся для поиска оптимального решения в условиях ограничения по ресурсам, когда другие математические модели оказываются слишком сложными.

Одним из наиболее эффективных инструментов имитационного моделирования является система Arena компании Systems Modeling Arena. Она позволяет строить имитационные модели, проигрывать их и анализировать результаты такого проигрывания.

Имитационная модель компании Systems Modeling включает следующие основные элементы: источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue). Источники - это элементы, от которых в модель поступает информация или объекты. Скорость поступления данных или объектов от источника обычно задается статистической функцией. Сток - это устройство для приема информации или объектов. Понятие очереди близко к понятию хранилища данных - это место, где объекты ожидают обработки. Время обработки объектов в разных процессах могут быть разными. В результате перед некоторыми процессами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь может быть похожа на стек - пришедшие последними в очередь объекты первыми отправляются на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может быть последовательная обработка, когда первыми на дальнейшую обработку отправляются объекты, пришедшие первыми (FIFO: first-in-first-out). Могут быть заданы и более сложные алгоритмы обработки очереди. Процессы - это аналог работ в функциональной модели. В имитационной модели может быть задана производительность процессов.

После проигрывания модели автоматически генерируются отчеты в формате Crystal Reports.

Модель в Arena может включать сотни модулей различных типов. Модули, обрабатывающие сущности могут иметь различные состояния, например “ожидание” или “работа”. Каждому состоянию можно поставить в соответствие определенное изображение и, тем самым, анимировать имитационную модель.

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

В результате, на основе построенной модели деятельности, была создана имитационная модель, отображающая движение документов в отделе кадров МОУ ДОД “Школа искусств №6 ”.

Рис. 14.

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

Устанавливаем продолжительность работы модели. Для этого выбираем Run - Setup вкладка Replication Parameters.

Для запуска модели нажимаем на кнопку (Go) на панели инструментов. Работа модели за 50 000 часов представлена на рис. 21

Для просмотра результатов нажимаем Да.