что такое описание информационных потоков

Информационные потоки в организации

Нестеров А.К. Информационные потоки в организации // Энциклопедия Нестеровых

Понятие и виды информационных потоков в организации

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

Информационные потоки в организации

Содержание потока определяется передаваемой информацией:

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

Схема информационных потоков в организации

Рассмотрим организацию информационных потоков на практическом примере. Допустим, есть молодое предприятие ООО «И-Мет», численность работников небольшая, основная сфера деятельности – проектирование зданий и сооружений из металлоконструкций.

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

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

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

Схема информационных потоков организации ООО «И-Мет» представлена на диаграмме.

Схема информационных потоков организации

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

Информационные потоки, связанные с внешним окружением ООО «И-Мет», делятся на четыре вида, за каждый из которых отвечает, помимо генерального директора, соответствующий руководитель компании (на рисунке выделено цветом). Особенность, существующая в компании заключается в большой нагрузке главного инженера при взаимодействии с внешним окружением ООО «И-Мет». Это связано, прежде всего, с деятельностью организации. Проектирование как вид деятельности согласно законодательству РФ подлежит лицензированию, соответственно решение вопросов связанных с получением лицензии, её оформлением помимо директора по общим вопросам должен решать, в том числе, и главный инженер. Большое значение имеет программное обеспечение, оборудование, на котором работают проектировщики, следовательно, и эти вопросы невозможно решить без согласования с главным инженером. Естественно, что в ходе непосредственно проектирования возникают различного рода технологические проблемы, которые требуют оперативного решения, а также взаимодействия с инженерами строительно-монтажных организаций, это также информация для главного инженера. Очевидно, что и взаимодействие с заводами изготовителями металлоконструкций по оперативным вопросам, не касающихся организации этого взаимодействия, а также финансовой стороны, целиком и полностью относятся в ведение главного инженера.

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

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

Средства передачи информации по информационных потокам организации:

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

Источник

Что такое DFD (диаграммы потоков данных)

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

DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия

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

Для себя я вывел следующую формулировку:

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.

Зачем нужна нотация DFD?

Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:

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

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

Как создавать нотации DFD

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

Последовательность получается такая:

С точки зрения DFD у нас имеются:

И декомпозиция основного элемента нашей диаграммы:

Где используются DFD нотации

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

Например, для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе, очень удобно создать отдельно – описание бизнес-процесса, а потом к нему – DFD-нотацию. Либо наоборот, предварительно для понимания основ работы бизнеса и особенностей реализации документооборота создается DFD-нотация. Она помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. А потом уже строится оптимизированный бизнес-процесс с учетом выявленных нюансов документооборота.

DFD нотации – это просто!

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

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

Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.

Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.

Вопросы и ответы

В чем разница между DFD и UML?

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

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

При этом не стоит рассматривать DFD как упрощенный вариант UML. Не смотря на схожесть в подходе, это — разные инструменты, предназначенные для разных целей.

Какое количество элементов может использоваться в DFD?

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

Можно ли использовать нотации DFD для работы с клиентами?

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

Источник

Информационные потоки – понятие, типы, примеры

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

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

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

Можно выделить два основных типа потока информации

Горизонтальные

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

Вертикальные

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

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

Подробности

Эффект испорченного телефона

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

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

— вызывают у сотрудников чувство своей «незначительности» и неудовлетворенности,

— порождает домыслы (ими компенсируется нехватка информации),

— вызывает чувство неуверенности в будущем,

— приводит к снижению мотивации своей деятельности.

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

Неформальный характер данных

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

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

Условия

То есть, для успешного управления нужно применять следующие условия:

Внешние потоки

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

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

Итоги

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

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

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

Источник

Описание информационных потоков

Типовые задачи описания бизнес-процессов. Системы, которые позволяют создавать описания (модели) бизнес-процессов предприятий. Нотации AR, ARIS eEPC, ARIS Organizational Chart, поддерживаемые BPwin 4.0. Функциональные возможности продуктов ARIS и BPwin.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ВЛАДИМИРСКИЙ ИНСТИТУТ БИЗНЕСА»

Кафедра Прикладной информатики и математики

Студент заочной формы обучения

1 курса группы ЗМ 05-13

Проверил: к.т.н., доцент кафедры ПИиМ

Введение. Типовые задачи описания бизнес-процессов

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

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

2. какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);

3. как моделировать процессы с использованием продукта «Х»;

4. как проводить анализ и выявлять проблемы при помощи продукта «Х»;

5. какую методологию использовать для описания процессов;

6. что делать дальше с полученными моделями бизнес-процессов.

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

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

3. возможностей CASE-систем по описанию процессов с учетом требований п. 2;

4. особенностей разрабатываемой/внедряемой информационной системы.

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

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

1. какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;

2. в какой последовательности выполняются эти процедуры;

3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;

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

6. какие исходящие документы/информацию генерирует процедура процесса;

7. какие ресурсы необходимы для выполнения каждой процедуры процесса;

8. какие документация/условия регламентируют выполнение процедуры;

9. какие параметры характеризуют выполнение процедур и процесса в целом;

10. существует ли последовательность процессов, минимизирующая затраты (в том числе стоимость, время и т.д.);

11. насколько процесс поддерживается/будет поддерживаться информационной системой.

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

бизнес модель нотация

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

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

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

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

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

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

Стрелка связи между объектами

Объект описывает тип отношений между другими объектами, например активацию выполнения функции некоторым событием

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

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

Логическое исключающее «ИЛИ»

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

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

Рис. 1. Пример модели в нотации eEPC

На рис. 1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

1. каждая функция должна быть инициирована событием и должна завершаться событием;

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рис. 2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Рис. 2. Пример применения объектов ARIS для описания бизнес-процессов

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

Из рис. 1 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC не может быть отражена визуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено одновременное выполнение двух задач. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе Microsoft Project.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Примеры моделей, сформированных с использованием ARIS eEPC, показаны на рис. 3 и 4.

Рис. 3. Описание процесса обслуживания клиента процесса

Рис. 4. Описание процесса анализа и согласования заявки клиента

Нотация ARIS Organizational Chart

Нотация Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 5.

Рис. 5. Модель организационной структуры предприятия

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

Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рис. 6.

Рис. 6. Фрагмент диаграммы ARIS Information Flow

Рис. 7. Нотация ARIS Information Flow

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. IDEF0 получила чрезвычайно широкое распространение и является, в частности, стандартом в таких международных организациях, как НАТО и МВФ. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Workflow), для которых важно отразить логическую последовательность выполнения процедур. Объекты нотаций IDEF0 и IDEF3 показаны в табл. 2 и 3.

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

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

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

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

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

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

Объект ссылки (Referent)

Объект, используемый 1) для описания ссылок на другие диаграммы; 2) ссылок на другие работы; 3) ссылок на объекты; 4) для пояснения логики ветвления стрелок на перекрестках; 5) различных комментариев к функциям и перекресткам

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

Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Полное описание стандартов IDEF можно найти на сайте http://www.idef.com/.

Пример описания бизнес-процесса в нотации IDEF0 показан на рис. 8 (соответствует процессу, показанному на рис. 3).

Рис. 8. Пример описания бизнес-процесса в нотации IDEF0

На рис. 9 показан пример описания бизнес-процесса в нотации IDEF3 (соответствует процессу, показанному на рис. 4).

Рис. 9. Пример описания бизнес-процесса в нотации IDEF3

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

Нотация DFD предназначена для описания информационных потоков в обследуемой организации. Объекты нотации DFD показаны в табл. 4. Наличие объектов «хранилище данных» и двунаправленных стрелок позволяет наиболее эффективно описать документооборот и требования к информационной системе.

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

Объект ссылки моделирует объект, воздействующий на систему извне

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

На рис. 10 показан пример диаграммы DFD.

Рис. 10. Пример описания документооборота в нотации DFD

Организационные диаграммы (Organizational Chart) в BPwin 4.0

Организационные диаграммы BPwin (рис. 11) являются аналогом организационных диаграмм ARIs и так же, как и в ARIS, предназначены для описания иерархии подчинения в организациях.

Рис. 11. Пример организационной диаграммы в BPwin

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

Сравнительный анализ нотаций ARIS и IDEF приводится в табл. 5.

Принцип построения диаграммы/логика процесса

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

Принцип доминирования (см. стандарт IDEF0)

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

Описание процедуры процесса

Объект на диаграмме

Объект на диаграмме

Объект на диаграмме

Используется отдельный объект для описания («документ»)

Стрелка входа, стрелка управления

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

Используется отдельный объект для описания («кластер», «технический термин»)

Стрелка входа, стрелка управления

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

Используется отдельный объект для описания («документ»)

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

Используется отдельный объект для описания («кластер», «технический термин»)

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

Используется отдельный объект для описания («позиция», «организационная единица»)

Нет (может быть отражен в модели только привязкой объекта ссылки)

Используется отдельный объект для описания

Нет (может быть отражен в модели только привязкой объекта ссылки)

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

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

Контроль выполнения процедуры

Нет. Может быть отражен указанием входящих документов

Нет (может быть отражен в модели только привязкой объекта ссылки).

Обратная связь по управлению/контролю

Нет. Может быть отражена только символами логики (последовательность выполнения процедур)

Обратная связь по входу

Нет. Может быть отражена только символами логики (последовательность выполнения процедур)

На рис. 12 функция 4 является контрольной и служит для проверки результатов работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:

1. каким образом осуществляется управляющее воздействие на функции 2 и 3? Показан только тот факт, что по ходу процесса возможен возврат и повторное выполнение функций 2 и 3; информация об этой обратной связи может быть

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

Рис. 12. Недостатки описания бизнес-процесса в ARIS eEPC

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

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

Функциональные возможности продуктов ARIS и BPwin

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

Возможности/ Инструментальная среда

Система хранения данных модели

Объектная база данных

Модели хранятся в файлах. Возможно создание репозитария на основе реляционной СУБД с помощью ModelMart

Ограничение на размер базы данных

Нет. Размер базы данных ограничивается вычислительными ресурсами

Нет. Размер базы данных ограничивается вычислительными ресурсами

Возможность групповой работы

Есть. Используется ARIS Server

Есть. Используется ModelMart

Ограничение на количество объектов на диаграмме

Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей

Неограниченная декомпозиция. Возможен переход на другую нотацию в процессе декомпозиции

Формат представления моделей

Стандартный бланк (каркас) IDEF с возможностью его отключения

Удобство работы по созданию моделей

Сложная панель управления, есть выравнивание объектов, есть undo

Простая панель управления, нет выравнивания объектов, нет undo

Большое, но ограниченное количество свойств; количество типов ограничено

Количество UDP не ограничено. Количество типов ограничено (18)

Возможность анализа стоимости процессов

Есть. Возможность использовать ARIS ABC

Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic

RPTwin, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP

Сложность разработки нестандартных отчетов

Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML

Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML

Связь с моделью данных

Возможность построения ERD-диаграмм, для экспорта необходимо дополнительное программное обеспечение

Реализована связь с моделью данных ERwin. Каждой стрелке может быть поставлен в соответствие набор сущностей и атрибутов

Описание доступа к данным

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

Описание сопутствующей документации

Есть, поддержка OLE

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

Выводы. Рекомендации по применению систем в зависимости от типовых задач

Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по 5-балльной шкале показаны в табл. 7.

Таблица 7. Оценка применимости ARIS Toolset 5.0 и BPwin 4.0 для задач моделирования бизнес-процессов

Разовый проект по описанию бизнес-процессов, например:

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

описание функциональных возможностей новой системы управления на верхнем уровне

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

Разработка системы автоматизации:

описание функциональных возможностей системы;

создание логической модели данных;

связь модели процессов и модели данных;

создание физической модели данных;

генерация кода приложения.

5 BPwin + ERwin + Paradigm Plus

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (рис. 13).

Рис. 13. Оценка эффективности ARIS Toolset и BPwin

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человек в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, таких как внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. Следует отметить, в что системе ARIS Toolset неудобно создавать информационные модели, а проектирование и настройка баз данных не предусмотрена. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

1. Интернет-сайт http://www.finexpert.ru/tags/opisanie_biznes_protsessov

2. Интернет-сайт http://www.interface.ru/home.asp?artId=22559

3. Интернет-сайт http://www.kbsi.com/solutions-and-services/idef-methods-and-standards

4. С.В.Маклаков. BPwin и ERwin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000, 256с.

5. Д.А. Марка, К. МакГоуэн Методология структурного анализа и проектирования. Москва, 1993.

6. «Методы ARIS». Файл pdf, более 1000 стр. Поставляется вместе с демо-версией системы ARIS Toolset.

7. Август-Вильгельм Шеер. Бизнес-процессы: основные понятия, теории, методы. Москва: Просветитель, 1999.

Размещено на Allbest.ru

Подобные документы

Предназначение и методология системы ARIS, преимущества использования скриптов. Сравнительный анализ CASE–средств. Моделирование процессов управления средствами ARIS. Разработка алгоритма, описание работы и листинг программы, инструкция пользователя.

дипломная работа [4,5 M], добавлен 10.06.2011

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

курсовая работа [2,2 M], добавлен 19.06.2015

контрольная работа [119,9 K], добавлен 04.06.2011

Создание алгоритма, включающего процессы аренды помещения под тренажерный зал, обустройство и закупку, получения нужных документов на открытие зала, найма персонала. Моделирование бизнес-процесса в нотации IDEF0, IDEF3, DFD в BPwin и EPC в Aris.

курсовая работа [496,9 K], добавлен 16.05.2016

Создание моделей процесса в BPwin, Aris Express, MS Visio, IBM Rational Rose и в соответствии с требованиями ГОСТ 19.701-90. Создание данных в Erwin и базы данных в MS Access. Расчет экономической эффективности реинжиниринга данного процесса в BPwin.

курсовая работа [2,3 M], добавлен 12.07.2015

Источник