Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Екзаменаційні питання до Моделювання та реінж.docx
Скачиваний:
6
Добавлен:
16.09.2019
Размер:
801.19 Кб
Скачать
  1. Моделювання потоків робіт (idef3) в bpWin. Наведіть приклад.

На відміну від діаграм IDEF0 і DFD, елементи яких дозволяють точно описати функціональність системи та організацію документообігу, описати за їх допомогою логіку побудови системи не вдасться. Для опису логіки взаємодії інформаційних потоків, послідовності виконання робіт і сценаріїв взаємодії модель доповнюють діаграмами ще однієї методології - IDEF3, також званої діаграмами workflow. У IDEF3 включені елементи логіки, що дозволяє аналітику моделювати й аналізувати альтернативні сценарії розвитку бізнес-процесу. Методологія моделювання IDEF3 дозволяє графічно описати і документувати процеси, фокусуючи увагу на перебігу цих процесів і на відносинах процесів і важливих об'єктів, що є частинами цих процесів. IDEF3 передбачає побудову двох типів моделей: модель може відображати деякі процеси в їх логічній послідовності, дозволяючи побачити, як функціонує організація, або ж модель може показувати "мережа перехідних станів об'єкта", пропонуючи увазі аналітика, послідовність станів, в яких може опинитися об'єкт при проходженні через певний процес. За допомогою діаграм IDEF3 можна аналізувати сценарії з реального життя, наприклад, як здійснювати оформлення документів при прийманні вантажу. Кожен такий сценарій містить у собі опис процесу і може бути використаний, щоб наочно показати чи краще документувати бізнес-функції організації. Перераховані інформаційні розрізи по-своєму унікальні. Кожен з них може бути виконаний окремо за допомогою BPwin, але їх сукупність, укладена в модель, дає аналітику повну картину предметної області клієнта.

  1. У чому полягає реінженерінг бізнес-процесів та його зв’язок з впровадженням системи якості.

Реинжиниринг бизнес-процессов (англ. Business process reengineering)— фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимального эффекта производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Реинжиниринг использует специфические средства представления и обработки проблемной информации, понятные как менеджерам, так и разработчикам информационных систем.

Смысл реинжиниринга бизнес-процессов в двух его основных этапах:

  • определение оптимального (идеального) вида бизнес-процесса (в первую очередь основного);

  • определение наилучшего (по средствам, времени, ресурсам и т.п.) способа перевода существующего бизнес-процесса в оптимальный.

  1. Дайте загальну характеристику організаційної моделі об’єкта управління та засоби її побудови в ARIS. Наведить типи оргструктур управління.

Організаційна структура найбільш легко піддається перенесенню на ARIS, оскільки вона, як правило, чітко визначена і не вимагає попередньої аналітичної проробки. З використанням детального опису організаційної структури можна проаналізувати кількість рівнів ієрархії, виявити наявність занадто великого або занадто малої кількості підлеглих у одного керівника, підпорядкування одних і тих же співробітників різних керівниками і т. п. - одним словом, провести елементарну перевірку. Організаційна структура схильна частих змін, для підтримки її опису в актуальному стані будуть потрібні додаткові ресурси. З урахуванням того, що семантика ARIS досить складна, ці додаткові ресурси будуть значні. Має сенс також попередньо формалізувати процес документування організаційної структури і оформити його у вигляді регламенту. Серйозну перевагу ARIS перед іншими інструментами полягає в тому, що в ARIS добре розвинені графічні засоби представлення сформованих моделей.

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

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

Функциональная организационная структура реализует тесную связь административного управления с осуществлением функционального управления (рис.15).

Д- директор; ФН - функциональные начальники; И - исполнители

Рис. 15. Функциональная структура управления

  1. Подання функціональної моделі в ARIS.

Разработаны функциональные модели технологии в 2-х нотациях:

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

  2. Нотация ARIS-VAD (см. Рис. 3). Модель технологии верхнего уровня.

  3. Нотация ARIS-VAD (см. Рис. 4).  Детализации модели верхнего уровня. Данная модель сделана максимально информативной и формализованной. Главным элементом модели является цепочка технологий, изображённая в виде горизонтально выстроенных стрелок. Выходом данной цепочки является продукт – интегрированная система управления. Таким образом, чтобы разработать интегрированную систему управления, нам необходимо последовательно реализовать (выполнить, проработать) все технологии, входящие в интегрированную технологию управления.

Сверху на данной модели показаны информационные входы и выходы по каждой технологи. Снизу показаны:

  1. Структура технологии, которая включает в себя совокупность методик, документов, алгоритмов и прочих материалов, необходимых для реализации технологии.

  2. Информационная система, которая автоматизирует реализацию технологии. Каждой технологии соответствует определённый класс информационных систем.

  3. Выход технологии (продукт), в виде конкретной системы управления.

Функциональная модель технологии разработана в соответствии с типовой схемой проектирования системы управления, которая используется в ведущих программных средствах бизнес-инжиниринга "ARIS", "Бизнес-Студио", "Инталев-Навигатор" и ведущих консалтинговых компаниях. Особое внимание следует обратить на следующие принципы технологии:

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

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

Варианты применения технологии:

  1. Полный технологический цикл (от начального до завершающего этапа).

  2. Частичный технологический цикл (от определённого этапа до завершающего этапа). Например, когда заказчику не требуется выполнение первых этапов технологии.

  3. Применение отдельных этапов технологии в качестве самостоятельных. Например, для разработки отдельных систем управления.

  4. Применение определённых задач отдельных этапов. Выполняется в том случае, когда у заказчика нет достаточного времени и средств для выполнения всех работ по этапу или для решении задачи не обязательно выполнять весь этап полностью.

Рис. 2. Функциональная модель технологии (свободная нотация)

Рис. 3. Функциональная модель технологии (нотация ARIS-VAD, верхний уровень)

  1. Подання моделі даних (інформаційної моделі) в ARIS.

В информационных моделях интегрированной технологии (см. Рис. 5) показаны все информационные потоки, циркулирующие в технологиях. Разработаны модели двух уровней детализации. На верхнем (первом уровне) показаны группы информационных потоков, разбитые по соответствующим технологиям (см. Рис. 5), на втором уровне показаны сами информационные потоки по соответствующим технологиям.

  1. Рис. 5. Информационные потоки по интегрированной технологии (верхний уровень)

  1. Подання процесної моделі в ARIS.

Процессная модель системы управления качеством на базе ARIS

Для многих российских предприятий становится актуальным соответствие их деятельности международным стандартам серии ИСО 9000 (ISO 9000). Системы управления качеством (Quality Management Systems, QM-системы) являются важной составной частью системы управления предприятием.

Реальная QM-система обычно включает 20 элементов, которые составляют международный стандарт ИСО 9001, и определяют основные требования к QM-системе. На Рис. 3 показаны эти 20 элементов, которые можно разделить на три группы, а именно:

  • Управление QM-системой.

  • Рабочий процесс.

  • Обеспечивающая деятельность.

  1. Порівняльна характеристика BPWin та ARIS.

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPWin. Сравнение функциональных возможностей систем приводится в следующей таблице.

Таблица 5.

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В Model Mart так же предусмотрено администрирование базы данных.

Часто одним из недостатков BPWin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPWin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPWin), содержащие более 500 объектов, фактически невозможно использовать. Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%. В свою очередь, BPWin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPWin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

  1. Охарактеризуйте рівні представлення моделей в ARIS.

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

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

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

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

модели управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы.

Графически такой подход может быть представлен следующим образом:

Рис. 2. Взаимосвязь типов моделей, используемых ARIS архитектура ARIS

В рамках каждого из перечисленных типов создаются модели разных видов, отражающие соответствующие стороны исследуемой системы. ARIS поддерживает большое количество методов моделирования, используемых для построения этих моделей. Среди них такие известные как диаграммы Чена, Unified Modeling Language (UML), Object Modeling Technique (OMT) и т.п. Последняя версия ARIS поддерживает более 83 методов моделирования.

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

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

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

  1. Уровень определения требований. На данном уровне разрабатываются модели, описывающие то, что должна делать система - как она организована, какие деловые процессы в ней присутствуют, какие данные при этом используются.

  2. Уровень проектной спецификации. Этот уровень соответствует концепции информационной системы, определяющей основные пути реализации предъявленных на втором этапе требований.

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

Графически такое разделение по уровням в ARIS выглядит следующим образом:

Рис. 3. Уровни представления моделей в ARIS

  1. ABC-аналіз та його реалізація в BPWin. Наведіть приклад.

Анализ показателей затрат и производительности. AllFusion Process Modeler 7 (BPwin) полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC). Функционально-стоимостной анализ, реализованный в AllFusion Process Modeler 7, позволяет оценить стоимостные и временные характеристики бизнес-процессов. Обычно ABC-анализ применяется для того, чтобы понять происхождение выходных затрат и/или облегчить выбор нужной модели бизнес-процессов при реорганизации (оптимизации) бизнес-процессов. Результаты стоимостного анализа могут быть наглядно представлены в специализированном отчете AllFusion Process Modeler 7.

  1. Діаграми FEO та інші (крім IDEF0) в BPWin. Наведіть приклади.

Презентаційні діаграми

(For Exposition Only diagrams — FEO diagrams) часто включають в моделі щоб проілюструвати інші точки зору або деталі, що виходять за рамки традиційного синтаксису IDEF0. Діаграми FEO допускають порушення будь-яких правил побудови діаграм IDEF0 в цілях виділення важливих з погляду аналітика частин моделі. Природно якщо діаграма FEO включена в модель виключно для відображення іншої точки зору на систему, вона швидше за все виглядатиме як звичайна діаграма IDEF0, задовольняючи всім обмеженням IDEF0.

Один із способів використання FEO-діаграм полягає у відділенні функціонального блоку від його оточення за допомогою створення діаграми з єдиним блоком і всіма стрілками, що відносяться до нього, на зразок контекстної діаграми (рис. 2.16). Це може виявитися корисним в ситуаціях, коли необхідно швидко одержати інформацію про інтерфейс (стрілках) функціонального блоку, а відповідна діаграма декомпозиції містить дуже багато об'єктів.

Як вже пікреслювалося, діаграма FEO може бути використана для пояснення якої-небудь частини процесу, відображенням особливої точки зору або виділенням функціональних деталей, які неможливо показати з використанням синтаксису IDEF0. Вони можуть забезпечуватися додатковим пояснюючим текстом і необов’язково повинні розроблятися із врахуванням обмежень стандарту IDEF0. Діаграми FEO можуть бути асоційовані із будь-якою існуючою в моделі діаграмою, але не являються ієрархічною частиною моделі. Діаграма FEO – копія будь-якої існуючої в моделі діаграми. Діаграма ідентифікується за допомогою:

  • імені, яке задається розробником;

  • ідентифікатора типу AxF, де x показує номер вихідної діаграми, а символ F показує, що діаграма має тип FEO.

  1. Типи зв’язків між функціями в функціональних діаграмах IDEF0. Наведіть приклади.

Щоб бути корисним, опис будь-якого блоку повинен, як мінімум, включати опис об'єктів, які блок створює в результаті своєї роботи ("виходу"), і об'єктів, які блок споживає або перетворює ("вхід").

У IDEF0 також моделюється управління і механізми виконання. Під управлінням розуміються об'єкти, що впливають на спосіб, яким блок перетворює вхід у вихід. Механізм виконання — об'єкти, які безпосередньо виконують перетворення входу у вихід, але не споживаються при цьому самі по собі. Для відображення категорій інформації, присутніх діаграмах IDEF0, існує абревіатура ICOM, що відображає чотири можливих типів стрілок:

I (Input) — вхід: те, що споживається в ході виконання

процесу;

C (Control) — управління: обмеження і інструкції, що впливають на хід виконання процесу;

O (Output) — вихід: щось, що є результатом виконання процесу;

М (Mechanism) — виконуючий механізм: щось, що використовується для виконання процесу, але не споживається саме по собі. Рис. 2.3 показує 4 можливих типу стрілок в IDEF0, кожний з типів з'єднується з своєю стороною функціонального блоку.

Рис. 2.3. Кожен тип стрілки з'єднується з своєю стороною функціонального блоку

Для назви стрілок, як правило, вживаються іменники. Стрілки можуть бути людьми, місцями, речами, ідеями або подіями. Як і у випадку з функціональними блоками, привласнення імен всім стрілкам на діаграмі є тільки необхідною умовою для розуміння читачем суті зображеного. Окремий опис кожної стрілки в текстовому вигляді може опинитися критичним чинником для побудови точної і корисної моделі.

Стрілки входу. Вхід є сировиною, або інформацією споживану або перетворювану функціональним блоком для виробництва виходу. Стрілки входу завжди направлені в ліву сторону прямокутника, що позначає в IDEF0 функціональний блок. Наявність вхідних стрілок на діаграмі не є обов'язковою оскільки можливо, що деякі блоки нічого не перетворюють і не змінюють. Прикладом блоку, що не має входу, може служити «ухвалення рішення керівництвом», де для ухвалення рішення аналізується декілька чинників, але жоден з них безпосередньо не перетвориться і не споживається в результаті ухвалення якого-небудь рішення.

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

Управління часто існує у вигляді правил, інструкцій, законів, політики, набору необхідних процедур або стандартів. Впливаючи на роботу блоку, воно безпосередньо не споживається і не трансформується в результаті. Може трапитися, що метою функціонального блоку є якраз зміна того або іншого правила, інструкції стандарту і т.п. В цьому випадку стрілка, що містить відповідну інформацію, повинна розглядатися не як управління, а як вхід функціонального блоку.

Управління можна розглядати як специфічний вид входу. У випадках, коли неясно, відносити стрілку до входу чи до управління, здебільшого відносити її до управління до моменту, поки неясність буде вирішена.

Стрілки виходу. Вихід — це продукція або інформація, яку отримуємо в результаті роботи функціонального блоку. Кожен блок повинен мати, як мінімум, один вихід. Дія, яка не проводить ніякого чітко визначуваного виходу, не повинна моделюватися взагалі (щонайменше, повинна розглядатися в якості одного з перших кандидатів на виключення з моделі). При моделюванні невиробничих наочних областей виходами, як правило, є дані, які в якому-небудь вигляді обробляються функціональним блоком. В цьому випадку важливо, щоб назви стрілок входу і виходу були достатньо помітні за своїм змістом. Наприклад, блок «Прийом пацієнтів» може мати стрілку «Дані про пацієнта» як на вході, так і на виході. У такій ситуації вхідну стрілку можна назвати «Попередні дані про пацієнта», а вихідну — «Підтверджені дані про пацієнта».

Стрілки механізму виконання. Механізми є ресурсами, які безпосередньо виконують модельовану дію. За допомогою механізмів виконання можуть моделюватися: ключовий персонал, техніка і (або) устаткування. Стрілки механізму виконання можуть бути відсутніми у випадку, якщо виявляється, що вони не є необхідними для досягнення поставленої мети моделювання.

Комбіновані стрілки. В IDEF0 існують п'ять основних видів комбінованих стрілок: вихід–вхід, вихід–управління, вихід–механізм виконання, вихід–зворотний зв'язок на управління і вихід — зворотний зв'язок на вхід.

Стрілка вихід–вхід застосовується, коли один з блоків повинен повністю завершити роботу перед початком роботи іншого блоку. Так, на рис. 2.4

Рис. 2.4. Комбінація стрілок вихід–вхід

формування рахунку повинне передувати прийому замовлення.

Стрілка вихід–управління відображає ситуацію переважання одного блоку над іншим, коли один блок управляє роботою іншого. На рис. 2.5 принципи формування інвестиційного портфелю що управляють поведінкою брокерів на біржі.

Рис. 2.5. Комбінована стрілка вихід–управління

Стрілки вихід–механізм виконання зустрічаються рідше і відображають ситуацію, коли вихід одного функціонального блоку застосовується як устаткування для роботи іншого блоку. На рис. 2.6 затиск, пристрій, використовуваний для закріплення деталі в час її складання, повинно бути зібрано для того, щоб виконати складання предмету.

Рис. 2.6. Комбінована стрілка вихід–механізм виконання

Зворотні зв'язки на вхід і на управління застосовуються у випадках коли залежні блоки формують зворотні зв'язки для керівних блоків. На рис. 2.7 отримана від брокерів інформація про поточних біржових курсах застосовується для корегування стратегічної гри на біржі.

Рис. 2.7. Комбінована стрілка вихід–зворотний зв'язок на управління

Стрілка вихід–зворотний зв'язок на вхід звичайно застосовується для опису циклів повторюваної обробки чого-небудь. Рис. 2.8 може служити прикладом застосування стрілки такого типу. Крім того, вихідний зв'язок–зворотний зв'язок на вхід можуть застосовуватися у випадку, якщо бракована продукція може знову використовуватися як сировина як це відбувається, наприклад, при виробництві віконного скла, коли розбите в процесі виробництва скло перемелюється і переплавляється знову разом із звичайною сировиною.

Рис. 2.8. Комбінована стрілка вихід–зворотний зв'язок на вхід

Розгалуження і сполучення стрілок. Вихід функціонального блоку може використовуватися в декількох інших блоках. Фактично майже головна цінність IDEF0 полягає в тому, що ця методологія допомагає виявити взаємозалежності між блоками системи. Відповідно IDEF0 передбачає як розгалуження, так і сполучення стрілок на діаграмі. Розгалужені на декілька частин стрілки можуть мати найменування, які відрізняються від назви результатної стрілки. Результатна і розгалужена (або об'єднані) стрілки в сукупності називаються зв'язаними. Така техніка звичайно застосовується для того, щоб відобразити використання в процесі тільки частини сировини або інформації, що позначається початковою стрілкою (рис. 2.9). Аналогічний підхід застосовується і до об'єднуваних стрілок.

Рис. 2.9. Розгалужена на дві частини і перейменована стрілка