Моделирование бизнес процессов управления: IDEF (Integration definition for function modeling)

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

1. Цели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

1. "Дорожка" может представлять собой однородные объекты: сотрудника, отдел, службу, внешнего контрагента и т.д.
2. Каждая функция обязательно размещается на "дорожке".
3. Для каждой функции обязательны три дуги: вход, выход, управление.
4. "Дорожки" определяется из множества IDEF-дуг "Механизм".
5. IDEF-дуга "Механизм" заменяется на дополнительную исходящую дугу функции.
6. Группировка функций в фазы процесса производится по основным функциям менеджмента, и являются отражением уровней вложения IDEF-схемы.
7. На схему обязательно переносятся "Внешние источники данных".
8. Процесс изображается в естественном его направлении сверху вниз, при этом всегда имеет начало и конец, и т.д.

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

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

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

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

www.gaap.ru