I. Перед идентификацией наркотина его отделяют от морфина

Г. разделении определенным элюентом в одном направлении, затем элюируют в противоположную сторону (под углом 1800) тем же растворителем

Положение о подразделение предназначено для формализации задач подразделения и установления границ взаимодействия сотрудников подразделения с другими подразделениями.

Подраздел положения	Описание подраздела
Титульный лист
Наименование компании	Значение параметра «Название компании». Задается в окне «Базовые настройки Business Studio» (Сервис −> Настройки для всех пользователей).
Наименование подразделения	Значение параметра «Название» Подразделения (см. Табл.15).
Лист согласования
Значение параметра «Руководитель подразделения» Подразделения (см. Табл.16)
Содержание
Содержание положения о подразделении (формируется автоматически).
1. Общие положения
Подразделение является структурным подразделением	Значение параметра «Название компании». Задается в окне «Базовые настройки Business Studio» (Сервис −> Настройки для всех пользователей).
Подразделение входит в состав	Наименование подразделения, вышележащего по отношению к Подразделению.
Подразделение создается и ликвидируется решением	Значение параметра «Руководитель организации в родит. падеже». Задается в окне «Базовые настройки Business Studio» (Сервис −> Настройки для всех пользователей).
Структуру и штат Подразделения утверждает	Значение параметра «Руководитель организации». Задается в окне «Базовые настройки Business Studio» (Сервис −> Настройки для всех пользователей).
1.1. Руководитель подразделения	Выводятся: - значение параметра «Руководитель подразделения» Подразделения (см. Табл.16); - наименование должности, вышележащей по отношению к Руководителю Подразделения.
1.2. Функциональное подчинение
Подразделение функционально подчиняется следующим структурным единицам:	Перечень субъектов, которым Подразделение подчиняется функционально. Подразделение функционально подчиняется субъекту, если между субъектом и Подразделением наведена связь «Функциональное подчинение», направленная от субъекта к Подразделению.
Подразделение имеет в функциональном подчинении следующие структурные единицы:	Перечень субъектов, функционально подчиненных Подразделению. Субъект функционально подчиняется Подразделению, если между Подразделением и субъектом наведена связь «Функциональное подчинение», направленная от Подразделения к субъекту.
1.3. Цели деятельности подразделения	Перечень целей, показатели которых назначены процессам, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем.
1.4. Документация	Перечень документов, регламентирующих деятельность Подразделения. Выводятся: - объекты класса «Документы» со стрелок управления процессов, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем. Если процесс расположен на диаграмме IDEF0, то выводятся объекты класса «Документы» со стрелок управления процесса. Если процесс расположен на диаграмме Процесса/Процедуры/ЕРС, то выводятся объекты класса «Документы» со стрелок управления того родителя процесса, который расположен на диаграмме IDEF0. Если тип процесса – ссылка, то выводятся объекты класса «Документы» со стрелок управления процесса-ссылки и типового процесса. - нормативно-справочные документы процесса, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем (см. Табл.11). Если тип процесса – ссылка, то выводятся нормативно-справочные документы процесса-ссылки и типового процесса; - нормативно-справочные документы Подразделения или Роли, в состав которой оно входит (см. Табл.15).
1.5. Права	Значение параметра «Права» Подразделения (см. Табл.16).
1.6. Ответственность	Значение параметра «Ответственность» Подразделения (см. Табл.16).
2. Организационная структура подразделения
2.1. Структурные единицы	Перечень подразделений, нижележащих по отношению к Подразделению.
2.2. Штатная численность
Руководитель подразделения	Руководитель, указанный в параметре «Руководитель подразделения» подразделения. Руководитель подразделения не выводится, если он находится по иерархии ниже подразделения.
Состав подразделения	Выводятся: - перечень подразделений, нижележащих по отношению к Подразделению; - перечень должностей этих подразделений; - значение параметра «Всего ставок» для каждой должности (см. Табл.17); - информация о количестве ставок каждой категории должности (см. Табл.17).
2.3. Организационная диаграмма	Организационная диаграмма Подразделения.
3. Задачи подразделения
3.1. Бизнес-процессы подразделения
Подразделение выполняет следующие бизнес-процессы:	Перечень процессов, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем.
Подразделение участвует в выполнении следующих бизнес-процессов:	Перечень процессов, где Подразделение (или Роль, в состав которой оно входит) является Участником (не Исполнителем и не Владельцем). Выводятся: - наименование процесса; - тип участия Подразделения или Роли (в состав которой оно входит) в процессе.
3.2. Участие в выполнении бизнес-процессов
Сотрудники Подразделения непосредственно выполняют следующие подпроцессы:	Перечень процессов, где субъекты Подразделения (или Роли, в состав которых входят субъекты Подразделения) являются Исполнителями. Процессы сгруппированы по процессу-родителю. Выводятся: - наименование процесса-родителя; - владелец процесс-родителя; - наименование процесса. В раздел не попадает информация о процессе, если в разделе 3.1выведена информация о родителе этого процесса.
Сотрудники Подразделения участвуют в выполнении следующих функций:	Перечень процессов, где субъекты Подразделения (или Роли, в состав которых входят субъекты Подразделения) являются Участниками (не Исполнителями и не Владельцами). Процессы, сгруппированы по процессу-родителю. Выводятся: - наименование процесса-родителя; - наименование процесса; - тип участия субъекта Подразделения в процессе; - наименование субъекта Подразделения. В раздел не попадает информация о процессе, если в разделе 3.1выведена информация о родителе этого процесса.
3.3. Прочие задачи и функции	Выводятся: - значение параметра «Задачи» Подразделения (см. Табл.16); - значение параметра «Функции» Подразделения (см. Табл.16).
4. Взаимодействие с другими подразделениями и внешней средой
4.1. Входящие документы и объекты	Документы или объекты, поступающие в Подразделение от других субъектов. Если поступление документа или объекта в Подразделение отображено на диаграмме SADT, то выводятся: - стрелки, входящие в процессы, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем; - перечень документов или объектов этих стрелок; - подразделение, откуда поступает каждый документ или объект, - субъект подразделения, от которого поступает документ или объект, - процесс-поставщик документа или объекта. Если процесс-поставщик − Действие, то выводится вышележащий процесс. Если поступление документа или объекта в Подразделение отображено на диаграмме ЕРС, то выводятся: - перечень документов или объектов, входящих в процессы, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем; - подразделение, откуда поступает каждый документ или объект, - субъект подразделения, от которого поступает документ или объект, - процесс-поставщик документа или объекта. Если процесс-поставщик − недекомпозированный процесс ЕРС, то выводится вышележащий процесс.
4.2. Исходящие документы и объекты	Документы или объекты, которые из Подразделения передаются другим субъектам. Если передача документа или объекта из Подразделения отображена на диаграмме SADT, то выводятся: - стрелки, исходящие из процессов, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем; - перечень документов или объектов этих стрелок; - подразделение, куда поступает каждый документ или объект, - субъект подразделения, к которому поступает документ или объект, - процесс-потребитель документа или объекта. Если процесс-потребитель − Действие, то выводится вышележащий процесс. Если передача документа или объекта из Подразделения отображена на диаграмме ЕРС, то выводятся: - перечень документов или объектов, исходящих из процессов, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем; - подразделение, куда поступает каждый документ или объект, - субъект подразделения, к которому поступает документ или объект, - процесс-потребитель документа или объекта. Если процесс-потребитель − недекомпозированный процесс ЕРС, то выводится вышележащий процесс.
4.3. Роли, участвующие во взаимодействии с подразделением	Перечень ролей, наименования которых встречаются в разделах 4.1 и 4.2. Выводятся: - значение параметра «Название» роли (см. Табл.15); - значение параметра «Субъект» из списка «Субъекты» роли (см. Табл.18); - значение параметра «Вышестоящее подразделение» из списка «Субъекты» роли (см. Табл.18); - значение параметра «Предмет деятельности» из списка «Субъекты» роли (см. Табл.18).
5. Критерии оценки деятельности подразделения
Перечень показателей, назначенных процессу, где Подразделение (или Роль, в состав которой оно входит) является Исполнителем. Для каждого показателя выводятся: - наименование; - единица измерения; - целевое значение; - целевая дата.
Приложение А. Состав наборов объектов
Перечень наборов объектов, наименования которых встречаются в положении о подразделении. Для каждого набора выводится перечень объектов, входящих в его состав.

Отчет вызывается от элементов класса «Субъекты» с типом «Подразделение».

7. Функциональный подход в моделировании бизнес-процессов (БП) 11

8. Объектно-ориентированный подход в моделировании БП.. 13

9. Что дает предприятию построение моделей по бизнес – процессам. 14

10. Основные виды БП (краткое описание, назначение) 16

11. Инжиниринг и реинжиниринг (краткое описание, отличия) 17

13. Словесное (вербальное) описание предприятия. 20

16. Моделирование БП “как есть”(краткое описание, назначение) 25

17. Моделирование БП «как должно быть» (краткое описание, назначение) 26

18. DFD (Data Flow Diagrams) – диаграммы потоков данных. 27

19. STD (State Transition Diagrams) – диаграммы перехода состояний. 28

20. ERD (Entity-Relationship Diagrams) – диаграммы “сущность-связь”. 29

21. Структурные карты Джексона (и/или Константайна) 30

22. FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции. 31

23. SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования. 32

25. IDEF0 – методология функционального моделирования. 36

26. IDEF1 – методология анализа и изучения взаимосвязей между информационными потоками. 38

27. IDEF1X – методология информационного моделирования. 40

28. IDEF3 – методология документирования технологических процессов предприятия. 42

29. IDEF4 – методология объектно-ориентированного проектирования. 43

30. IDEF5 – методология, обеспечивающая наглядное представление данных, полученных в результате обработки онтологических запросов, в простой. 44

Настоящий международный стандарт описывает основные положения систем менеджмента качества, являющихся объектом стандартов семейства ИСО 9000, и определяет соответствующие термины.

Международный стандарт может использоваться:

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

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

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

- теми сторонами, внутренними или внешними по отношению к организации, которые оценивают систему менеджмента качества или проверяют ее на соответствие требованиям ИСО 9001 (например, аудиторы, органы по сертификации/регистрации);

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

- разработчиками соответствующих стандартов.

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

Предназначение настоящего международного стандарта - побуждать принятие процессного подхода к менеджменту организации.

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

Стандарт EN ISO 9000:2000 <Системы менеджмента качества. Основные положения и словарь> описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества

ИСО 9001 направлен на обеспечение качества продукции и повышение удовлетворенности потребителей.

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

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

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

Требования, содержащиеся в стандарте ИСО 9001:2000 являются общими и предназначены для применения ко всем организациям независимо от вида деятельности, размера организации и поставляемой продукции (услуг). Стандарт определят что необходимо делать для внедрения системы качества, но не определяет как это делать. Именно за счет такого подхода требования стандарта являются универсальными и применимыми к любой организации. Методы, как реализовать то или иное требование стандарта предприятие выбирает само, исходя из своих потребностей и возможностей.

Стандарт EN ISO 9001:2000 устанавливает требования к системам менеджмента качества для тех случаев, когда организации необходимо продемонстрировать свою способность предоставлять продукцию, отвечающую требованиям потребителей и соответствующим нормативным требованиям, и направлен на повышение удовлетворенности потребителей.

Стандарт EN ISO 9004:2000 <Системы менеджмента качества - руководящие указания по улучшению деятельности> содержит рекомендации, касающиеся как результативности, так и эффективности системы менеджмента качества. Целью этого стандарта является улучшение деятельности организации и повышение удовлетворенности потребителей и других заинтересованных сторон. ИСО 9004:2000 предоставляет методическую помощь по более широкому спектру целей системы менеджмента качества, чем это делает ИСО 9001, особенно по постоянному улучшению деятельности организации и эффективности, а также ее результативности. ИСО 9004 рекомендуется как руководство для организаций, руководящий состав которых желает выйти за рамки требований ИСО 9001, преследуя цель постоянного улучшения деятельности. Однако он не предназначен для целей сертификации или заключения контрактов. ISO 9004 является руководством в более широком диапазоне целей системы менеджмента качества, чем ISO 9001, в частности по непрерывному совершенствованию общего функционирования организации и ее эффективности, а также ее результативности. ISO 9004 рекомендуется как руководство для организаций, высшее руководство которых хочет идти дальше требований ISO 9001, стремясь непрерывно совершенствовать эффективность. Стандарт ИСО 9004:2000 не предназначен ни для сертификации, ни для использования в договорных отношениях. Также данный стандарт не является руководством по внедрению ИСО 9001:2000. Отличие данного стандарта заключается в более расширенных требованиях к системе менеджмента качества и некоторых рекомендациях, какие методы можно использовать для реализации этих требований. Расширение требований в стандарте ИСО 9004:2000 осуществляется за счет учета требований всех заинтересованных сторон. К таким заинтересованным сторонам стандарт относит потребителей, акционеров предприятия, работников предприятия, людей и общество в целом, т.е. все те, кто может испытывать на себе результаты хозяйственной деятельности организации.

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

Конструктивное использование языка UML основывается на общих принципах моделирования сложных систем и процесса объектно-ориентированного проектирования (ООП) в частности.

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

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

- обеспечить независимость от конкретных языков программирования и процессов разработки;

- обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

- стимулировать рост рынка объектно-ориентированных инструментальных средств;

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

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

Программа «прокрутки» еЕРС отслеживает логику в цепочках выполняемых функций и проходит по объектам выбранных цепочек. Данная программа может быть использован как шаблон для создания программ имитации и анализа бизнес-процессов. Для работы программы необходимо в выбранной еЕРС-модели бизнес-процесса задать идентификаторы, используемые при обработке логических операторов. В атрибут Remark/Example функций или событий, предшествующих логическому оператору, необходимо внести в список идентификаторов выбираемых ветвей либо указать один идентификатор. Список идентификаторов разделяется пробелами. В атрибут Description/Definition каждой функции или события, стоящих после логического оператора, необходимо записывать идентификатор выбора ветви. Если в определенном выше списке идентификаторов встретилось совпадение с идентификатором выбора ветви, то данная ветвь считается выбранной.

Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.

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

Организационная единица. Например, управление или отдел.

Документ. Отражает реальные носители информации, например, бумажные документы.

Кластер информации. Характеризует набор сущностей и связей между ними.

Логический оператор. Оператор "И", "ИЛИ" или исключающее "ИЛИ", позволяет описать ветвление процесса.

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

Объединение функций и данных описывается в моделях типа EPCs (цепочка процесса, управляемая событиями), где для каждой функции могут быть определены начальные и конечные события, которые переключают функции и являются результатом их выполнения. Для получения динамической последовательности функций в функциональный поток необходимо включить события. События могут инициировать начало выполнения последовательности функций, ее завершение или изменение порядка выполнения функций и запускающих ее событий образует триггер. В отличие от функций, которые имеют некоторую продолжительность, события происходят мгновенно. События вместе с функциями играют ключевую роль в процессных цепочках. Они запускают функции и являются результатом их выполнения. События описывают состояние объекта и позволяют контролировать бизнес-процессы или влиять на ход его выполнения. Несколько событий связываются с функциями при помощи логических операторов. С помощью диаграмм ЕРС процедуры бизнес-процессов представляются как логические последовательности событий. События определяют, какое состояние или отношение будет переключать функцию и какое состояние наступит после ее выполнения. Поэтому модель ЕРС должна всегда иметь запускающие и завершающие события. Одно событие может инициировать выполнение одновременно нескольких функций, и наоборот, функция может быть результатом наступления нескольких событий. Объединения нескольких событий или функций отображаются на диаграмме ЕРС с помощью соединителей в виде небольшого кружка. Эти соединители не только отображают графические связи между объектами модели, но и определяют логические связи между ними.

7. Функциональный подход в моделировании бизнес-процессов (БП)

В функциональном подходе главным структуро-образующим элементом является функция (действие, операция), в объектно-ориентированном подходе – объект. Функциональный подход в моделировании БП сводится к построению схемы БП в виде последовательности операций, с которыми связаны материальные и информационные объекты, используемые ресурсы, организационные единицы и многое другое. Достоинством функционального подхода является наглядность последовательности и логики операций в БП предприятия, а недостатком – некоторая субъективность детализации операций.

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

Функциональный подход в моделировании БП сводится к построению схемы БП в виде последовательности операций, с которыми связаны материальные и информационные объекты, используемые ресурсы, организационные единицы и многое другое. Достоинством функционального подхода является наглядность последовательности и логики операций в БП предприятия, а недостатком – некоторая субъективность детализации операций.

Основными преимуществами функционального подхода являются:

· Привычность подхода для проектной команды;

· Привязка к иерархической структуре управления организацией;

· Ориентация на специализацию функций подразделений и сотрудников.

· Непрозрачность связей между функциональными областями и процессами;

· Вероятность искажения представления БП по причине функциональной иерархии;

· Проблемы взаимосвязей на стыке функциональных областей.

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

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

8. Объектно-ориентированный подход в моделировании БП

Объектно-ориентированный подход предполагает вначале выделение объектов, а затем определение тех действий, в которых они участвуют. При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, программное обеспечение), которые осуществляют действия. Такой подход позволяет объективно выделить операции над объектами и решить задачу о целесообразности использования этих объектов. Недостаток объектно-ориентированного подхода заключается в меньшей наглядности конкретных бизнес-процессов.

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

9. Что дает предприятию построение моделей по бизнес – процессам

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

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

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

Причины, по которым принимается решение
по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

- оптимизацию функций подразделений и сотрудников;

- перераспределение прав и обязанностей руководителей;

- изменение внутренних нормативных документов и технологии проведения операций;

- новые требования к автоматизации выполняемых процессов и т. д.

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

10. Основные виды БП (краткое описание, назначение)

Бизнес-процесс (БП) – это взаимосвязанный набор действий (операций, функций), которые по определенным правилам преобразуют исходные экономические ресурсы в конечные продукты или услуги. Под БП понимают совокупность различных видов деятельности, которые вместе взятые создают результат (продукт, услугу), имеющий ценность для потребителя, клиента или заказчика. БП выполняется с целью создания выхода (результата), спрос на который предъявляют корпоративные (внутренние) или внешние потребители (клиенты).

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

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

Обеспечивающими являются БП, которые обеспечивают выполнение основных БП. В общем случае они обеспечивают ресурсами все БП. В отличие от основных количество обеспечивающих БП достигает десятков.

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

К БП развития, как правило, относятся БП совершенствования выхода (производимого продукта или услуги) или технологии его получения, а также инновационные процессы.

11. Инжиниринг и реинжиниринг (краткое описание, отличия)

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

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

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

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

Сбор документов должен осуществляться на всех этапах проведения обследования. Целесообразно подготовить альбом форм с разбивкой их по деятельностям предприятия. Цель анкетирования – сбор информации, которая характеризует предприятие и его систему управления как в целом, так и по отдельным элементам.

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

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

13. Словесное (вербальное) описание предприятия

На стадии вербального описания предприятия выполняются следующие работы:

1. Форм улирование (уточнение) миссии предприятия.

2. Определение критических факторов успеха (5–7 факторов): длительность, издержки, качество продукции, качество обслуживания (сервис) и т.д.

3. Выявление основных, вспомогательных и других бизнесс-процессов, как существующих, так и перспективных (10-15 бизнесс-процессов).

4. Оценка бизнесс-процессов по степени реализации критических факторов успеха.

5. Ранжирование бизнесс-процессов с указанием приоритетов.

6. Описание отличительных особенностей бизнесс-процессов.

7. Описание существующих обеспечивающих, производственных и информационных технологий.

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

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

10. Определение внешних рисков, обеспечения финансовыми ресурсами, надежности партнеров.

Выполнение миссии организации обеспечивается ее стратегическими процессами. Цель процесса – ожидаемый (требуемый) будущий результат, на достижение которого направлен процесс.

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

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

Каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Параметры описания операции:

· адресат - пользователь или группа пользователей, получающих задание;

· экранная форма - это документ, содержащий предназначенные для заполнения пустые места, в которые вводятся данные;

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

· действия системы при инициализации и завершении операции.

В управлении и выполнении процесса Workflow участвуют следующие классы пользователей;

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

· разработчик процесса - разработка, тестирование и поддержка конкретного процесса;

· владелец процесса - редактирование конкретного процесса;

· менеджер - контроль исполнения экземпляров процесса посредством регистрационных отчетов и сервисных программ;

· пользователь - доступ к системе через очередь заданий, функция запуска экземпляра конкретного процесса и справочная подсистема.

Управлять всеми БП при помощи одной прикладной системы невозможно. Очень часто для этого требуется ряд прикладных систем для организации продаж, закупок, производства, учета и т. д. Например, общее управление БП осуществляет, как правило, отдельная система, называемая управлением потоками работ (workflow). Внедрение этой системы является явным признаком перехода на процессно-ориентированное управление предприятием. Системы класса workflow, например, в офисных процессах передают обрабатываемые объекты (документы) с одного рабочего места на другое. В идеале эта передача осуществляется электронными средствами – от компьютера, установленного на одном рабочем месте, к компьютеру, где выполняется следующая операция. Для этого требуется детальное описание процедур применительно к конкретному БП и указание на соответствующих исполнителей.

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

Существует четыре фазы оптимизации бизнес-процессов:

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

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

Анализ «как есть» начинается с «инвентаризации» бизнес-процессов. Создается описание инфраструктуры, где основные бизнес-процессы представляются в виде цепочек добавленной стоимости. Это представление служит основой для более подробного описания процессов с помощью событийных диаграмм процессов ЕРС.Текущие бизнес-процессы оцениваются с точки зрения их соответствия целям ОБП.

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

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

16. Моделирование БП “как есть”(краткое описание, назначение)

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

17. Моделирование БП «как должно быть» (краткое описание, назначение)

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

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

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

Основными компонентами диаграмм потоков данных являются:

- внешние сущности, представляющее собой источник или приемник информации;

- процессы преобразования входных данных в выходные в соответствии с определенным алгоритмом;

- накопители данных, в которые можно помещать и извлекать информацию;

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

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

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

19. STD (State Transition Diagrams) – диаграммы перехода состояний

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

С помощью STD можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования.

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

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

20. ERD (Entity-Relationship Diagrams) – диаграммы “сущность-связь”

ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

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

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

Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения типа "отец-сын" или производственные отношения типа "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи.

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

21. Структурные карты Джексона (и/или Константайна)

Структурные карты Константайна являются моделью отношений иерархии между программными модулями.

Любой модуль; Связь по данным; Связь по управлению; Поток – вызов модуля.

Техника структурных карт Джексона основана на методологии структурного программирования Джексона. Эта техника позволяет осуществлять проектирование нижнего уровня структуры ПО и на этом этапе является близкой к традиционным блок-схемам.

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

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

22. FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции

Диаграммы функциональной декомпозиции (FDD) детализируют представленные функции или процессы.

Декомпозиция - это процесс создания диаграммы, детализирующей определенный блок и связанные с ним дуги. Подлинная декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта. В процессе свободного объединения и введения новых управляющих дуг создается список функций для дальнейшей детализации. Например, указания и чертеж заставляют автора подумать о функциях, выбрать инструменты и подготовить рабочее место. Функции вносятся в список до тех пор, пока поток идей не иссякнет. Затем эти функциональные части объединяются в разумные (сбалансированные) наборы из 3-6 блоков. Когда декомпозиция выполнена, полученные блоки диаграммы активизируются главным образом благодаря дугам управления. Следовательно, дуги управления влияют на качество и обоснованность результирующей декомпозиции. Информация, содержащаяся в документах, связанных с очередным шагом рабочей инструкции, используется рабочим при выборе инструментов. Если бы это было не так, дуга очередной шаг рабочей инструкции могла бы не быть дугой управления, а действие выбрать инструменты могло бы не представлять функцию.

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

23. SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

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

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

IDEF создавалась в рамках программы компьютеризации промышленности (ICAM) и была направлена на конструирование и отображение бизнес-процессов. В основе технологии IDEFO лежит простой графический язык, включающий:

· функциональный блок (activity box), имеющий 4 элемента;

· интерфейсная дуга (arrow) отображает элемент системы, обрабатываемый блоком, (документы), потоки деталей, клиентов и т.д.;

· декомпозицию (decomposition), т.е. разделение блока на составляющие элементы;

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

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

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;

IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;

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

IDEF4 – методология построения объектно-ориентированных систем (выделения структуры объектов и их взаимодействий). Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 – методология онтологического исследования сложной системы (описание состояния, развития и оптимизация траектории движения системы).

В настоящий момент к семейству IDEF можно отнести и такие стандарты как:

IDEF6 – Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 - Information System Auditing – Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 – User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов).

IDEF9 – Scenario-Driven IS Design - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие.

IDEF10 – Implementation Architecture Modeling - Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 – Information Artifact Modeling.Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 – Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 – Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

25. IDEF0 – методология функционального моделирования

Методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique);

Описание IDEF0 модели построено в виде иерархической пирамиды, в вершине которой представляется самое общее описание системы, а основание представляет собой множество более детальных описаний.

IDEF0 методология построена на следующих принципах:

1. Графическое описание моделируемых процессов. Графический язык Блоков и Дуг IDEF0 Диаграмм отображает операции или функции в виде Блоков, а взаимодействие между входами/выходами операций, входящими в Блок или выходящими из него, Дугами.

2. Лаконичность. За счет использования графического языка описания процессов достигается с одной стороны точность описания, а с другой – краткость.

Необходимость соблюдения правил и точность передачи информации. При IDEF0 моделировании необходимо придерживаться следующих правил:

- На Диаграмме должно быть не менее 3-х и не более 6-и функциональных Блоков.

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

- Диаграммы должны иметь связанный интерфейс, когда номера Блоков, Дуги и ICOM коды имеют единую структуру.

- Уникальность имен функций Блоков и наименований Дуг.

- Четкое определение роли данных и разделение входов и управлений.

- Замечания для Дуг и имена функций Блоков должны быть краткими и лаконичными.

- Для каждого функционального Блока необходима как минимум одна управляющая Дуга.

- Модель всегда строится с определенной целью и с позиций конкретной точки зрения.

В процессе моделирования очень важным является четко определить направление разработки модели – ее контекст, точку зрения и цель.

Контекст модели очерчивает границы моделируемой системы и описывает ее взаимосвязи с внешней средой.

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

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

Цель отражает причину создания модели и определяет ее назначение. При этом, все взаимодействия в модели рассматриваются именно с точки зрения достижения поставленной цели.

В рамках методологии IDEF0 модель системы описывается при помощи Графических IDEF0 Диаграмм и уточняется за счет использования FEO, Текстовых и Диаграмм Глоссария. При этом модель включает в себя серию взаимосвязанных Диаграмм, разделяющих сложную систему на составные части. Диаграммы более высокого уровня (А-0, А0) – являются наиболее общим описанием системы, представленным в виде отдельных Блоков. Декомпозиция этих Блоков позволяет достигать требуемого уровня детализации описания системы.

26. IDEF1 – методология анализа и изучения взаимосвязей между информационными потоками

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

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

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

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

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

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