Методологии и стандарты семейства IDEF

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

Министерство науки и образования, молодежи и спорта Украины

Харьковский Торгово-экономический институт КНТЭУ

Кафедра менеджмента

Реферат

По дисциплине: "Реинжиниринг в торговле и сфере услуг"

на тему: " Методологии и стандарты семейства IDEF"

Выполнила: ст. гр. МА-09

Тур О.Ю.

Проверил: преподаватель

Мирошниченко Ю.В.

Харьков 2013

Содержание

Введение

1. Методологии и стандарты семейства IDEF

2. История возникновения IDEF0

3. Функциональный блок

Вывод

Список литературы

Введение

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

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

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

1. Методологии и стандарты семейства IDEF

бизнес компания моделирование конкурентоспособность

В настоящее время в Украине резко возрос интерес к общепринятым на Западе стандартам менеджмента, однако, в реальной практике управления существует один очень показательный момент. Многих руководителей до сих пор можно поставить в тупик прямым вопросом об организационной структуре компании или о схеме существующих бизнес-процессов. Наиболее продвинутые и регулярно читающие экономическую периодику менеджеры, как правило, начинают чертить понятные только им одним иерархические диаграммы, но и в этом процессе обычно быстро заходят в тупик. То же самое касается сотрудников и руководителей различных служб и функциональных подразделений. В большинстве случаев, единственным набором изложенных правил, в соответствии с которыми должно функционировать предприятие, является набор отдельных положений и должностных инструкций. Чаще всего эти документы составлялись не один год назад, слабо структурированы и не взаимосвязаны между собой и, вследствие этого, просто пылятся на полках. До поры до времени подобный подход был оправдан, так как во время становления российской рыночной экономики понятие конкуренции практически отсутствовало, да и затраты считать не было особой необходимости - прибыль была гигантской. В результате этого, мы видим в течение последних двух лет вполне объяснимую картину: крупные компании, выросшие в начале 90-х годов, постепенно сдают свои позиции, вплоть до полного ухода с рынка. Отчасти это обусловлено тем, что на предприятии не были внедрены стандарты управления, полностью отсутствовало понятие функциональной модели деятельности и миссии. С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать "узкие места" в управлении и оптимизировать общую схему бизнеса. Но, как известно, на любом предприятии высший приоритет имеют только те проекты, которые непосредственно приносят прибыль, поэтому речь об обследовании деятельности и ее реорганизации обычно идет только во время ощутимого кризиса в управлении компанией.

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

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

DEF - методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF другой вариант - Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методолoгии --SADT) и связано возникновение основных идей популярного ныне понятия --BPR (бизнес-процесс реинжиниринг).

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

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

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

§ IDEF1X (IDEF1 Extended) - Data Modeling - методология построения реляционных структур (баз данных), относится к типу методологий "Сущность-взаимосвязь" (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

§ IDEF2 - Simulation Model Design - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);

§ IDEF3 - Process Description Capture - Документирование технологических процессов,

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

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

§ IDEF5 - Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

§ IDEF6 - Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпретируются как ответ на вопрос: "почему модель получилась такой, какой получилась?" Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

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

§ IDEF8 - User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интефейсов в большей степени создают внешний вид интефейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфес для выполнения операции);

§ IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

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

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

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

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

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

2. История возникновения IDEF0

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

Стандарт IDEF0 был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing), предложенной департаментом Военно-Воздушных Сил США. Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF - ICAM DEFinition).

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

C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера. Последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST).

3. Функциональный блок

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия, первое из которых - понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1), и, по требованиям стандарта, его название должно содержать глагольную форму ("производить услуги", а не "производство услуг").

Каждая из четырех сторон функционального блока имеет своё значение: верхняя сторона - "Управление" (Control), левая сторона - "Вход" (Input), правая - "Выход" (Output), нижняя сторона - "Механизм" (Mechanism). Каждому функциональному блоку в рамках системы присваивается уникальный идентификационный номер.

Рисунок 1. Функциональный блок

4. Интерфейсная дуга

Вторым "китом" методологии IDEF0 является понятие интерфейсной дуги (Arrow), которую также нередко называют потоком или стрелкой. Интерфейсная дуга изображается в виде однонаправленной стрелки и имеет свое уникальное наименование (Arrow Label), содержащее, по требованию стандарта, оборот с существительным.

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

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

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

Рисунок 2. Функциональный блок "Обработать заготовку"

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

Рисунок 3.

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Вывод

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

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

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

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

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

Список литературы

1. Войнов И.В., Пудовкина С.Г., Телегин А.И. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография. - Челябинск: Изд. ЮУрГУ, 2002. - 392 с.

2. Волков О. Стандарты и методологии моделирования бизнес-процессов. Режим доступа: http://www.connect.ru/article.asp?id=5710. - Загл. с экрана.

3. Григорьев Д. Моделирование бизнес-процессов предприятия. Режим доступа: http://www.valex.net/articles/process.html. - - Загл. с экрана.

4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов // М.: Финансы и статистика, 2006.

5. Менеджмент процессов / Под ред. Й. Беккера, Л. Вилкова, В. Таратухина, М. Кугелера, М. Роземанна; [пер. с нем.]. - М.: Эксмо, 2007. - 384 с. - (Качественный менеджмент).

6. Пинаев Д., Веретенников Д. Моделирование бизнес-процессов: доступно о сложном / Д. Пинаев // 2003.

7. Сергей Ковалев, Валерий Ковалев, Журнал "Консультант директора", № 12, Июнь, 2004 г.

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