Описание бизнес процессов idef0

IDEF0 в моделировании бизнес-процессов управления

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

Прежде всего, необходимо заметить следующий факт. В настоящее время умственные ресурсы, вкладываемые в свою деятельность руководителем любого ранга, по своему эффекту во многом неудовлетворительны, что по большому счету является следствием слабой «вооруженности» руководителей. Наиболее частый выход из такого положения многие российские менеджеры видят в использовании общепринятых на Западе стандартов и концепций управления, а также реализующих эти стандарты IT. С другой стороны, в области моделирования бизнес-процессов, как одного из инструментов для поддержки деятельности руководителя, наиболее популярными являются стандарты описания семейства методологий IDEF (Integration definition for function modeling). Но вместе с тем, что данной методологией уже вряд ли кого-то удивишь, в ее применении остаются актуальными две проблемы, проблемы именно для руководителей.

Построение диаграммы IDEF0 в process modeler (bpwin)

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

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

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

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

Вторая проблема является следствием первой и связана с представлением разработанных моделей менеджерам компании. Дело в том, что полученные схемы и описания наиболее удобны разработчикам информационных систем и аналитикам, но не всегда выразительны и наглядны. Особенно если необходимо сделать презентацию сложного процесса с целью обсуждения возможных его улучшений и сравнить два варианта («as-is» и «to-be»). То есть проблема состоит не в какой-либо методологической сложности IDEF и не в том, что менеджеры не способны ее изучить (или не хотят этого делать), а именно в выразительности схем при обсуждении и принятии решений большим количеством участников в сжатые сроки (в объеме презентации).

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

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

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

отсутствие среди участников процесса себя, руководителей отделов, аналитиков, плановиков и т.п.,

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

В результате крайне трудно использовать данные схемы, например, при:

построении процессов стратегического планирования и бюджетирования;

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

построении контроля процесса и отчетности для руководителей;

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

Кроме того, становится невозможной реализация в деятельности руководителя (а значит и деятельности предприятия) свойства целостности, хотя при построении схем бизнес-процессов компании это является необходимым условием. Из имеющегося опыта можно сделать заключение, что данное свойство наиболее сложно реализуемо, так как можно представить следующую формализацию [1, 4]:

C = Целостность (П, И, Н, Д),

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

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

Рис. 1. Стандарт IDEF0.

Очевидно, чтобы получить схему, отвечающую обозначенным выше требованиям, необходимо сменить точку зрения (определяющую основное направление развития модели) при описании бизнес-процессов. И вот здесь возникает проблема в применении существующих и, главное, освоенных стандартов к описанию бизнес-процессов с целью управления организацией, с целью связать схемы текущей операционной деятельности с деятельностью руководителей, аналитиков и т.д. Это отсутствие при описании понимания компании как системы, сути процессного подхода (как следствие некорректная постановка задачи описания) и неэффективное использование самих моделей. В лучшем случае моделирование деятельности руководителя ограничивается одной функцией с множеством входов и выходов, что не помогает в преодолении трудности достижения целостности. К сказанному можно добавить слова американского исследователя М. Месаровича [2]:

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

Хотя об этом много говориться, но сегодня вряд ли многие понимают актуальность и необходимость поддержания целостности выстраиваемого объекта, деятельности. Второй момент, препятствующий достижению высокой результативности работы аналитика бизнес-процессов управления, состоит в многоцелевой, разнохарактерной по направлению и предметам деятельности руководителя, в результате чего складывается впечатление отсутствия «профессиональной» целостности (впрочем, отсутствие так таковой целостности — далеко не исключение), причем как в понимании аналитика, так и самого руководителя [3].

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

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

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

Рис. 2. Модель бизнес-процессов.

1. Цели.

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

формулируется востребованность организации так таковой и необходимость удовлетворения данной востребованности, другими словами следует ответ на вопрос «зачем» создается организация и «что» она должна делать;

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

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

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

миссия, видение, философия организации и кадровая политика,
направление развития бизнеса (стратегия),

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

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

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

2. Окружающая среда.

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

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

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

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

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

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

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

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

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

3. Внутренняя организация.

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

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

выявляются и формируются элементы организации,

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

выбираются способы реализации связей между элементами,

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

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

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

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

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

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

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

Для решения данной проблемы, связанной с недостатком выразительности методологии IDEF, предлагается разработать правила переноса схем процессов в другое представление, называемое «SWIM-LINE». Фактически внутри компании разрабатывается внутренний стандарт презентации процессов, который описывает, в том числе, и данные правила конвертирования из одного представления, удобного для разработчиков, в другое, удобное для менеджера.

Пример.

«Дорожка» может представлять собой однородные объекты: сотрудника, отдел, службу, внешнего контрагента и т.д.

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

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

На схему обязательно переносятся «Внешние источники данных».

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

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

Пример. На рис. 3 приводится упрощенная схема процесса продажи с участием руководителя службы (отдела) продаж.

Для изображения схем может использоваться, например, MS-Visio с шаблоном Cross-functional Flowchart. Таким образом, основная логика, понятная аналитику и применимая для построения любой алгоритмической модели процесса, остается та же, что используется в IDEF, а меняется лишь внешний вид представления на более удобный для руководителя и менеджера.

Рис. 3. Модель бизнес-процесса «Продажа».

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

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

Библиография

1. Садовский В.Н. Системные исследования: некоторые принципиальные проблемы построения общей теории систем, М.: Наука, 1971.

2. Месарович М. Теория иерархических многоуровневых систем, М.: Мир, 1973.

3. Мильнер .З. Системный подход к организации управления, М.: Экономика, 1983.

4. Авилов А.В. Рефлексивное управление. Методологические основания. М., 2003.

5. Котлер Ф. Основы маркетинга, СПб.: КОРУНА, 1994.

6. Друкер П.Ф. Задачи менеджмента в XXI веке, М., 2001.

Источник: hr-portal.ru

Блог о бизнес-процессах и BPMN

Блог о бизнес-процессах, BPMN и других нотациях автоматизации бизнес процессов.

Назначение и состав методологии IDEF0 в бизнес моделировании

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

Методология IDEF0 берет своё начало в 60-х годах. Разработана известным американским ученым Дуглас России в США. В настоящее время методология IDEF0 является фундаментальной, занимает ведущую позицию. Рассмотрим более подробно ее назначение и особенности.

Несколько слов о преимуществах графики

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

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

Изображение бизнес-процесса в графическом виде

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

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

Что такое нотация описания бизнес-процессов

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

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

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

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

Что такое IDEF0?

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

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

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

Idef0 блоки

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

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

Назначение и состав методологии

Методология IDEF0 получила свою популярность и широкое применение благодаря простому графическому исполнению и простоте восприятия.

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

Описание бизнеса-процессов происходит быстро и очень понятно. Главные составляющие — диаграммы.

Выделяют четыре типа диаграмм:

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

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

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

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

Диаграмма дерева узлов — выражает зависимость функций между собой.

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

Элементы графической нотации

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

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

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

  • Деятельность;
  • Процесс;
  • Операция;
  • Действие.

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

  • Вход;
  • Управление;
  • Механизм;
  • Выход;
  • Вызов.

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

Типы связей между функциями

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

Маркетолог предприниматель

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

Выделяют несколько типов связей:

  • Иерархическая
  • Регламентирующая связь
  • Функциональная
  • Потребительская
  • Логическая
  • Коллегиальная
  • Ресурсная
  • Информационная
  • Временная
  • Случайная.

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

Плюсы и минусы

  • Главным преимуществом методологии IDEF0 является полнота описания бизнес-процесса. Описание с помощью диаграмм (главных и второстепенных) позволяется точно описать все процессы, и указать множество взаимосвязей между ними и с внешней средой;
  • Жесткие требования к изложению информации. Это приводит к стандартизации бизнес-процессов.
  • К недостаткам можно отнести сложность восприятия такого бизнес-процесса, поскольку множество стрелочек рассеивают внимание и переключают его с основной функции и взаимосвязи на второстепенные.
  • Сложность прочтения, как для сотрудников организации, так и для руководителей. Однако, в этом случае следует отметить, что перед внедрением в деятельность любой методологии, сотрудники организации должны пройти обучение. В противном случае бизнес-процессы не будут эффективными.

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

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

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

Облегчить чтение модели возможно, если придерживаться определенны правил создания диаграмм IDEF0. Вот некоторые из них:

  • Первостепенно определить для себя цель бизнес-процесса. Необходимо определить тип формируемой модели, а также позицию, с точки зрения которой будет строиться модель.
  • При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
  • На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
  • Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6.
  • Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз.
  • Отсутствие у функции одновременно стрелок управления и входа не допускается.
  • Обеспечить каждому блоку свой вход.
  • Постараться как можно меньше допустить поворотов в диаграмме и петель.
  • Используйте обратные дуги для изображения обратных связей.
  • Поименуйте каждый элемент диаграммы.
  • Использовать туннелирование стрелок.
  • Объединить стрелки, проходящие параллельно и дать им единое имя.
  • Нумерация блоков.

Читать: Что такое ЕРС- нотация в бизнес моделировании. Алгоритм построения диаграмм в методологии

Типичные ошибки

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

Рассмотрим типичные ошибки:

  1. Использование различных цветов — не стоит пытать выделить отдельные элементы цветами, чтобы повысить наглядность. Все элементы одинаково важны.
  2. Слишком большое количество блоков — нельзя изобразить все нюансы процесса на одном листе. Для конкретизации деятельности необходимо применить детализацию каждого блока.
  3. Нарушение структуры при внесении корректировок — при внесении каких-либо изменений, например смены точки зрения, следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.
  4. Правила названия управляющих элементов и блоков — называйте стрелки именами, а блоки глаголами.

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

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

К сегодняшнему дню создано не мало программ для создания диаграмм IDEF0. Вот некоторые из них:

  • ERWin 3.5.2;
  • Design/ IDEF;
  • Dia;
  • IDEF0/EMTool;
  • BPwin.

Пример создания функциональной модели IDEF0

Рассмотрим процесс написания статьи для наглядного описания создания функциональной модели IDEF0

Пример создания функциональной модели IDEF0

Основной блок называется «Написать статью».

Взаимодействие с внешней средой обозначены на схеме входящими стрелками – «Знания в области написания статьи», «Опыт», «Информация из сторонних источников». Основы, которые необходимы для описания.

Управляющие в данном случае – это «План публикации», «Требования издателя», «Правила русского языка».

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

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

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать.

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

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

Читать также:

  1. Для чего проводится описание бизнес процессов. Основные инструменты и правила моделирования
  2. Для чего проводится анализ бизнес процессов на предприятии, какие методы и виды оценки эффективности подразделений применяются на практике
  3. Основные показатели эффективности бизнес-процессов на предприятии.
  4. Основные нотации моделирования бизнес процессов и их применение

Источник: bpmn.pro

IDEF0. Знакомство с нотацией и пример использования

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

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

Несколько слов о преимуществах графики

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

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

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

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

И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно. Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании.

На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены.

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

Почему это важно для моей работы

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

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

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

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

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

Что такое нотация описания бизнес-процессов

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

Что такое IDEF0?

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временнаL9;я последовательность (поток работ). Википедия

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

Функциональная модель компании

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

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

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

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

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

Пример создания функциональной модели IDEF0

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

Основной блок – «Написать статью».

Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

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

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

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

В нашем случае работа делится на 4 основных этапа:

  1. Подготовить аудио.
  2. Подготовить текст
  3. Подготовить текст к публикации.
  4. Разместить статью в издании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования стандарта IDEF0

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

  1. В левом верхнем углу всегда – главный элемент.
  2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
  3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
  4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
  5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

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

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

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

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

Нарушение структуры при внесении корректировок

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

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

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

Правила названия управляющих элементов и блоков

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

  • Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
  • Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
  • Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
  • Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

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

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

Методология IDEF0

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

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

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

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

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

Типы стрелок

В IDEF0 различают пять типов стрелок.

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

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

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

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

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

Статья 17 - Картинка 1

Рис. 2.1Типы стрелок

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

Статья 17 - Картинка 2

Рис. 2.2. Связь по выходу

Рис. 2.3. Связь по управлению

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

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

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

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

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

Статья 17 - Картинка 5

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

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

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

  • непомеченные ветви содержат вес объекты, указанные в метке дугиперед разветвлением;
  • ветви, помеченные после точки разветвления, содержат все объектыили их часть, указанные в метке дуги перед разветвлением.

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

Статья 17 - Картинка 6

Рис. 2.6. Связь выход-механизм

  • непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
  • помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

  • количество блоков на диаграмме — N;
  • уровень декомпозиции диаграммы — L;
  • сбалансированность диаграммы — В;
  • число стрелок, соединяющихся с блоком, — А

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

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

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

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

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

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

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).

Статья 17 - Картинка 9

Рис.2.8 Диалог создания модели

BPWin поддерживает три методологии — IDEF0, IDEF3 и DFD. В BPWin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

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

Пример

Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы «Назначение разработки», «Цели и задачи системы» и «Функциональные характеристики системы » .

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

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

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

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

Контекстная диаграмма

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Статья 17 - Картинка 10

Рис 2.9.Контекстная диаграмма системы

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

  • Определение уровня доступа в систему.
  • Выбор подсистемы.
  • Обращение к подсистеме.
  • Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Статья 17 - Картинка 11

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

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

Статья 17 - Картинка 12

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

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

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

  • Открытие БД.
  • Выполнение запроса.
  • Генерация отчетов.

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

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

Рис. 2.12. Декомпозиция работы «Обработка запроса клиента»

Корректировка диаграммы

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

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

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 — 2.15).

Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Статья 17 - Картинка 15

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Статья 17 - Картинка 16

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

  • БД пользователей,
  • БД студентов,(вариант 2)
  • БД вакансий,
  • БД успеваемости,
  • БД тестов,
  • БД экспертных оценок,
  • БД резюме.

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

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

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

Статья 17 - Картинка 17

Рис. 2.16. Декомпозиция работы «Изменение БД»

Статья 17 - Картинка 18

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

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

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента Кb у двух вариантов моделей.

для второго варианта

Коэффициент Кb не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

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

Контрольные вопросы

Список Контрольных вопросов:

  1. Что представляет собой модель в нотации IDEF0?
  2. Что обозначают работы в IDEF0?
  3. Назовите порядок наименования работ?
  4. Какое количество работ должно присутствовать на одной диаграмме?
  5. Что называется порядком доминирования?
  6. Как располагаются работы по принципу доминирования?
  7. Каково назначение сторон прямоугольников работ на диаграммах?
  8. Перечислите типы стрелок.
  9. Назовите виды взаимосвязей.
  10. Что называется граничными стрелками?
  11. Объясните принцип именования разветвляющихся и сливающихся стрелок.
  12. Какие методологии поддерживаются BPWin?
  13. Перечислите основные элементы главного окна BPWin.
  14. Опишите процесс создания новой модели в BPWin.
  15. Как провести связь между работами?
  16. Как задать имя работы.
  17. Опишите процесс декомпозиции работы.
  18. Как добавить работу на диаграмму?
  19. Как разрешить туннелированные стрелки?
  20. Может ли модель BPWin содержать диаграммы нескольких методологий?

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

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин