Организация и поддержка бизнес-процессов управления

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

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

Первая заключается в использовании данных стандартов и получаемых моделей для организации поддержки бизнес-процессов. Первоначальное использование 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". Фактически внутри организации разрабатывается внутренний стандарт презентации бизнес-процессов, который описывает, в том числе, и данные правила конвертирования из одного представления, удобного для разработчиков, в другое, удобное для менеджера.

Пример.

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

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

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

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

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

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

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

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