Схема бизнес процесса пример idef0

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

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

Сквозной пример в Process Modeler Часть1 idef0

Примитивы стандарта IDEF0

В стандарте IDEF0 существует два основных примитива.

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

Рис. 1.1. Пример функционала

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

Рис. 1.2. Пример ресурса

Виды ресурсов стандарта IDEF0 и их взаимосвязь

Существует четыре вида ресурсов, которые могут быть связаны с конкретным функционалом. Виды ресурсов отражены на рисунке:

Рис. 1.3. Виды ресурсов

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

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

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

IDEF0

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

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

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

Следует отметить, что стрелки ресурсов могут ветвиться, что приводит к следующим ситуациям:

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

2. Один и тот же ресурс в результате ветвления подходит к разным блокам.

3. Ресурс в результате ветвления может делиться на смысловые части. В этом случае необходимо обязательно назвать этот отделяемый ресурс (Например, если существует механизм «Персонал», от него можно ответвить ресурс «Директор», «Инженер», «Охранник» и т.д.).

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

Основные виды связей между блоками

Особенности построения моделей по стандарту IDEF0

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

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

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

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

Существует два вида схем IDEF0: «as is» и «to be». Первый вид применяется, когда процесс отражается без воздействия системы, автоматизирующей его, а второй – когда проектировщик представляет, что будет с процессом при условии его автоматизации, то есть присутствия системы.

Пример декомпозиции процесса

Для примера был взят процесс написания курсовой работы (КР). Сразу нужно отметить, что процесс упрощен для более быстрого понимания механизма построения моделей. Вначале для наглядности разобьем процесс на подпроцессы без использования диаграмм IDEF0 и представим его в виде диаграммы дерева узлов. Общая схема детализации процесса представлена на рисунке:

Рис. 1.4. Диаграмма дерева узлов для рассматриваемого процесса

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

Так как было произведено две детализации (для процессов «Работа над КР» и «Написание КР»), то модель представления процесса будет иметь три схемы: общую схему, описывающую процесс целиком, ее детализацию и схему, являющиеся результатом детализации второго процесса на втором уровне.

Пример построения диаграмм IDEF0

Общая схема, где показывается процесс целиком, по стандарту IDEF0 носит название контекстной диаграммы и обозначается «A-0». Схема А-0 представлена на рисунке:

Рис. 1.5. Контекстная диаграмма процесса «Работать над КР»

Весь процесс на схеме обозначен функционалом «Работать над КР».

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

КП будет оформляться с учетом ГОСТов, поэтому ресурс «ГОСТ» является управляющим для процесса «Работать над КР».

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

Результатом процесса «Работать над КР» является защищенная КР, являющаяся выходным ресурсом функционала «Работать над КР».

Детализация общего функционала «Работать над КР» дает новую схему, которая по стандарту IDEF0 обозначается «А0». Схема А0 представлена на рисунке. Как уже говорилось ранее, при детализации функционала все ресурсы, соприкасающиеся с этим процессом, переносятся на схему с детализированными подпроцессами. В данном случае были перенесены входной ресурс «Литература», управляющие ресурсы «ГОСТ» и «Задание», механизмы «Студент», «ПК», «Преподаватель», выходной ресурс «Защищенная КР». Остается определить принадлежность перенесенных ресурсов функционалам, являющимся продуктом детализации, и добавить новые ресурсы.

Рис. 1.6. Детализация процесса «Работать над КР»

Весь процесс работы над КР можно разбить на три этапа: изучение литературы, написание КР и защита КР. Соответственно, на схеме присутствуют три функционала. На схемах, соответствующих второму и более низким уровням детализации, блоки нумеруются по порядку слева-направо.

Рассмотрим ресурсы, относящиеся к каждому блоку.

КР пишется с использованием переработанного материала и литературы, которые перерабатываются и являются входными ресурсами для блока «Написать КР». Написание КР происходит на основании задания, являющегося управляющим ресурсом блока «Написать КР». Оформление КР осуществляется по ГОСТам, которые являются управляющим ресурсом блока «Написать КР».

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

Когда КР успешно защищена, то преподаватель ставит на титульном листе и листе задания пометки о защите. Поэтому входным ресурсом блока «Защитить КР» является проверенная КР, а выходным – защищенная КР. Защита проходит с ориентировкой на задание, поэтому ресурс «Задание» является управляющим ресурсом блока «Защитить КР».

При выставлении оценки учитываются требования ГОСТ, поэтому ресурс «ГОСТ» является управляющим ресурсом блока «Защитить КР». Защищается студент, а контролирует его преподаватель, причем часто с использованием ПК. Поэтому ресурсы «Студент», «ПК» и «Преподаватель» являются механизмами блока «Защитить КР».

Неудавшуюся защиту учитывает ресурс «Неудача», являющийся результатом процесса защиты и относящийся к выходным ресурсам. «Неудача» включает инструкции преподавателя по исправлению КР. Они будут учтены при переработке материала и являются входным ресурсом блока «Изучить литературу».

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

Рис. 1.7. Детализация процесса «Написать КР»

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

Когда студент работает над КР, у него могут появиться ряд вопросов к материалу, поэтому кроме ресурса «Часть КР» выходным для функционала «Реализовать часть КР» также является ресурс «Непонятный студенту материал». Студент пишет главы КР на ПК, поэтому механизмами функционала «Реализовать часть КР» являются ресурсы «Студент» и «ПК». Студент пишет КР, ориентируясь на ГОСТы и задание, поэтому для функционала «Реализовать часть КР» управляющими являются ресурсы «Задание» и «ГОСТ». Студент пишет КР, используя литературу и переработанный материал, поэтому для функционала «Реализовать часть КР» входными являются ресурсы «Литература» и «Переработанный материал».

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

То есть от непонятного студенту материала зависит дальнейший процесс написания КР. Поэтому ресурсы «Непонятный студенту материал» и «Часть КР» являются входными для функционала «Проконсультироваться у преподавателя», а ресурс «Непонятный студенту материал» одновременно входным и управляющим.

Исходя из вышеизложенного, ресурс «Переработанный фрагмент КР» является выходным для функционала «Проконсультироваться у преподавателя». Когда после консультации студент продолжает дописывать КР, то он может создавать другие главы на основе материала из проверенной КР.

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

После ряда консультаций студент собирает готовую, с его точки зрения, КР из переработанных фрагментов, поэтому ресурс «Переработанный фрагмент КР» является входным для функционала «Собрать готовую КР», а ресурс «КР для проверки» — выходным. Студент дописывает КР на ПК, поэтому ресурсы «Студент» и «ПК» являются механизмами для функционала «Собрать готовую КР». Студент дописывает работу, опираясь на задание и ГОСТы, поэтому ресурсы «ГОСТ» и «Задание» являются управляющими для функционала «Собрать готовую КР».

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

Если преподаватель поручил студенту дописать КР, то он дает инструкции, как это сделать, причем студент после этого может дополнительно консультироваться. Поэтому ресурс «Некорректная КР» также является входным и управляющим для функционала «Реализовать часть КР». Итоговая проверка КР проводится на основе задания и ГОСТов, поэтому ресурсы «Задание» и «ГОСТ» являются управляющими для функционала «Провести итоговую проверку». В процессе проверки преподаватель может уточнять некоторые вопросы у студента с использованием ПК, поэтому ресурсы «Студент», «ПК» и «Преподаватель» являются механизмами для функционала «Провести итоговую проверку».

Из схем видно, что блоки, которые не детализируются, имеют «уголок» в левой верхней части, а детализируемые «уголка» не имеют.

Работа с тоннелями

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

Рис. 1.8. Пример тоннеля

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

Источник: lektsia.com

Пример построения модели по методологии IDEF0

На рынке существует достаточно большое количество программных средств, автоматизирующих процесс построения моделей с использованием CASE-технологий. Все они различаются поддерживаемыми методологиями, широтой применения и различными специализированными средствами. В описанном далее примере для разработки модели по методологии IDEF0 использовался программный комплекс «Design/IDEF 3.5» Meta Software Corporation.

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

Для открытия счета депо, депонент предоставляет в депозитарий заявление на открытие счета депо со следующими приложениями:

— Нотариально заверенную карточку с образцами подписей и оттиска печати по счету депо;

— Заверенные копии уставных документов;

— Доверенность на получение отчетов.

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

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

— Извещение об открытии счета депо (в случае выполнения операции);

— Заявление на открытие счета депо с отметкой о причинах неисполнения (в случае невыполнения операции).

Определив входы и выходы модели, необходимо определить ограничения:

— Во-первых, так как выполнение данной операции лежит целиком на депозитарии, то и исполнителем будет депозитарий.

— Во-вторых, управляющим инструментом (а попросту — «руководством к действию») является Регламент совершения депозитарных операций, то есть внутренний документ депозитария, в котором описывается порядок и сроки совершения всех операций. Этот документ должен определять правила выполнения операции на всех этапах, поэтому целесообразно представить его в виде туннельной дуги.

Рис.2.29. Общее представление модели операции открытия счета депо депонента

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

Рис.2.30. Открытие счета депо депонента (детализация основного блока)

Как видно из рисунка 2.30., входными данными дочерней диаграммы являются дуги, входящие в блок Р.2, а выходными — исходящие. Сама операция состоит из трех основных функций:

— Обработка поступивших документов;

— Непосредственное исполнение операции;

Процесс выполнения операции базируется на использовании некоторой автоматизированной депозитарной системы (АС) и в связи с этим блок «Исполнение» выполняется без участия человека.

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

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

— Депозитарная система обрабатывает введенное на первом этапе электронное поручение. В депозитарной системе открывается счет депо и выдается оператору извещение об открытии счета. Если поручение, по каким-либо причинам, в данный момент исполнить нельзя, то депозитарная система должна выдать соответствующее уведомление и оператор повторно инициирует операцию. В случае невозможности исполнения поручения депозитарной системой выдается отчет о неисполнении поручения депо (заявления);

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

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

Рис.2.31. Ввод заявлений и приложений

Рис.2.32. Подготовка к вводу поручений и приложений

Рис.2.33. Формирование электронного поручения и приложений

На рисунке 2.34. представлена детализация функции «Исполнение». Исполнение введенного оператором на первом этапе поручения депо на открытие счета депо осуществляется автоматически в депозитарной системе.

Механизм исполнения операции в системе представляет собой следующую последовательность действий:

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

— Анализ условий исполнения поручения. Система проверяет возможность исполнения поручения, т.е. соответствие процедуры регламенту совершения операций (рис. 2.36.);

— Операционные записи. На этом этапе в депозитарной системе формируется запись об открытии счета депо с одновременным внесением изменений в соответствующие картотеки (2.37., 2.38.);

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

Рис.2.35. Проверка полномочий

Рис.2.36. Анализ условий исполнения поручений

Рис.2.37. Проверка даты и времени исполнения поручения

Рис.2.38. Операционные записи

Завершающим этапом технологического процесса исполнения операции является выдача клиенту отчета об исполнении операции. В этом случае возможны два варианта действий (рис. 2.39.).

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

— В случае получения исходного заявления на открытие счета с отметкой о неисполнении и/или электронного отчета о неисполнении операции, исполнитель подписывает заявление и отправляет его депоненту с указанием причин неисполнения.

Рис.2.39. Выдача отчета

Для удобства ориентирования в IDEF, каждой диаграмме присваивается свой уникальный номер (рис. 2.40).

Рис.2.40. Дерево узлов

Номер начинается с буквы А (Activity) и включает в себя порядковый номер родительской диаграммы. Полученную иерархию диаграмм модели, можно отобразить в виде дерева узлов (node tree).

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

Преимущества методологию IDEF0:

— модели позволяют упорядочить и оптимизировать процесс документооборота в депозитарии;

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

— модели позволяют на бумаге проверить и отследить предстоящую схему работы;

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

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

IDEF1

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: mydocx.ru