Мифы управления бизнес процессами. Разработка и внедрение информационной системы Система управления бизнес процессами организации

Сергей Рубцов.

PC Week/RE, № 46, 47, 48

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

Функциональность, методология и самоорганизация

Культура организации концентрированно выражается в способе ее
самоорганизации. Чем совершеннее этот способ, тем больше шансов у организации на
выживание. Одним из возможных взглядов на организацию является представление ее
в виде системы бизнес-процессов (БП). Именно проблема выживания такой системы
определяет пути развития корпоративных информационных систем (КИС) управления.
Класс КИС, ориентированных на управление БП, будем относить к автоматизированным
системам управления бизнес-процессами (АСУ БП). Граница между КИС,
ориентированными и не ориентированными на управление БП, определяется
функциональной возможностью КИС поддерживать реинжиниринг БП и настраиваться на
созданные проектировщиком организации модели БП. Например, все КИС, обладающие
закрытой архитектурой и ориентированные на решение функциональных, а не
процессных задач, не могут быть отнесены к АСУ БП.

Сразу отметим, что совершенно бессмысленно, опираясь на
функциональный анализ, сравнивать влияние на культуру организации конкурирующих
КИС управления (зарубежные - SAP R/3, Baan, Oracle Application и др. или
отечественные - отечественные системы «Парус», «Галактика»,
«Фобос» «Фигаро-ERP» и др.). Очевидно, функциональность КИС управления постоянно
развивается в направлении АСУ БП. Преимущества одной системы над другой быстро
нивелируются. Более того, наблюдаются случаи временного разделения труда
разработчиков (например, интеграция модулей CRM (Управление Работой с Клиентами)
Интернет-приложения пакета Oracle Applications с продуктом R/3 компании SAP).

Связать задачи АСУ БП с задачей выживания организации нам
помогают классики кибернетики организаций. Прежде всего вспомним фразу С. Бира:
«…прилагательные “хороший” или “плохой” в большей мере относится к
пользователям, чем к используемой ими технике», акцентировавшего внимание на то,
что потребности заказчика разнообразны и не всегда обоснованы, а технологии
служат достижению целей конкретной методологии . Именно, принятая методология
управления ограничивает выбор способа самоорганизации БП. К сожалению,
вопросы управленческой методологии, лежащей в
основе той или иной АСУ БП, освещаются скудно. И это понятно. Ведь
методологический уровень восприятия у потенциального потребителя, а иногда и
разработчика АСУ БП крайне низок.

Печальная статистика внедрения АСУ БП известна. По данным
компании Price Waterhouse Coopers на 2001 г. на западе число неудачных внедрений
систем класса ERP достигает 28%. В России точной статистики в этой области не
ведется, но летом 2001, например, у SAP из 200
инсталляций программы R/3 работало, по подсчетам самого разработчика, 110. У
фирмы Baan, другого лидера рынка, это соотношение составляло 44 к 21 .
Очевидно, понятие «работало» нам никак не говорит о степени решения реальных
производственных задач.

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

Жизнеспособная организация и АСУ БП

Глубинные же причины неадекватности «коробочной» культуры и
культуры организации лежит в плоскости методологических конструкций. Пожалуй,
основной признак методологической классификации - это отношение АСУ БП к
организации, а более конкретно – ответ на вопрос: «Является ли организация
составной частью АСУ БП, или АСУ БП является составной частью организации?»
Здесь мы имеем в виду то, что по С. Биру жизнеспособная система должна всегда в
себе содержать модель самой себя . А это есть требование к способности АСУ БП
поддерживать рефлексию организации. Разъяснение этого положения можно встретить
у основоположников кибернетики организации.

Например, методология концептуального проектирования,
разработанная отечественным гуру автоматизации С. Никаноровым , доказывает
существование инвариантов управления в виде абстракций называемых
«конструктами». Им же с учетом вывода И. С. Ладенко о рефлексивной сущности
деятельности было постулировано положение о том, что организация – это клубок
процессов рефлексии, моделируемое множеством процессов принятия решений. Отсюда
следует вывод, согласующийся с основным положением теории оптимального
регулирования. А именно, базовым конструктом «модельера» БП должен являться
рефлексивный контур, состоящий из операций: (1) анализ результата воздействия
(например, поставки продукта), (2) моделирование объекта воздействия (например,
потребителя продукта), (3) собственно, регулирование (например, поставка
продукта). Эта тройка процессов может служить инвариантом для описания любой
деятельности или взаимодействия БП любого уровня. Моделирование организационной
рефлексии в динамике согласно Дж. Форрестеру и есть моделирование
организации. Грамотно организованная рефлексия согласно С. Биру есть условие
выживания организации. Здесь мы видим, что рефлексивный контур является ядром
разнообразных концепций научного управления организациями. Потребность
следования такому мета-стандарту выдвигает специфические требования к АСУ БП.
Взгляд С. Бира на компании будущего как на интеллектуальные, гибкие и
мобильные организации, чутко реагирующие на непрерывно изменяющиеся потребности
рынка, в начале XXI века концентрированно выражается в следующих требованиях.

Во-первых, важнейшим требованием к АСУ БП является наличие в
ней «инструмента-дизайнера», позволяющего представлять БП в виде рефлексного
контура. К сожалению, как специальные «бизнес - органайзеры», так и средства
реинжиниринга БП, которыми оснащены современные АСУ БП (например, SAP R/3, Baan,
Oracle Application), очень трудно использовать для
моделирования организационной рефлексии. Модели же стандартных БП, хранящихся в
библиотеках этих систем, не удовлетворяют этому требованию.

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

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

Особенности систем, ориентированных на знания

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

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

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

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

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

При такой формализации бизнес – логики возникают
дополнительные удобства для пользователей и разработчиков АСУ БП: (1)
пользователи более оперативно могут реагировать на флуктуации рынка и изменения
нормативной базы; (2) разработчики могут легко локализовать и модифицировать
правила, когда необходимы изменения политики без необходимости компиляции кода.

Такой гибкий подход контрастирует с общей практикой
разработки АСУ БП, которая представляет БП в виде программных объектов, подобных
COM, JavaBeans, прикладным классам или запросам к базам данных.

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

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

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

Объектно-ориентированное проектирование бессильно помочь,
когда пользователь желает изменить бизнес – логику. Для ее изменения
объектно-ориентированная АСУ БП потребует неадекватно большого времени. Смешение
правил и объектов рассеивает логику по приложениям, затрудняя ее локализацию и
увеличивая затраты на реакцию на изменения рынка.

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

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

Когда организация ищет новые пути разработки и внедрения
приложений, автоматизирующих деятельность, возникает особый интерес к гибкости и
оперативности АСУ БП, ориентированных на знания. Такие АСУ БП особенно
необходимы там, где: (1) пользователи нуждаются в
быстрых и нетрудоемких изменениях декларативных организационных знаний; (2)
приложения управляются событиями и должны реагировать на комбинации событий; (3)
причинно-следственные связи БП сложны и пока до конца не исследованы или не
описаны; (4) не существует алгоритмических (математических) алгоритмов решения
проблемы.

Для разных отраслей могут выполняться одно или несколько из
перечисленных условий. Независимо от того выпускает ли компания строительные
материалы, использует ли электронные или обычные каналы сбыта, могут быть
разработаны правила для управления транзакциями, оценки сценариев и принятия
решений. Сегодня наиболее известным и мощным пакетом, используемым для
разработки АСУ БП на основе знаний, является продукт компании ILOG. Приложения
ILOG активно используются сейчас в ERP-системах, а
пакет оптимизации ILOG де-факто стал стандартом для таких разработчиков ERP -
систем, как Adonix, Baan, i2 Technologies, J.D. Edwards, Oracle, PeopleSoft и
SAP.

Успех ILOG на рынке свидетельствует не только о
перспективности технологий, основанных на управлении знаниями и осознании
разработчиками элементов ERP систем этого факта, но и о некоторой
неповоротливости их генеральных конструкторов, нерешающихся на признание
технологии управления знаниями в качестве базовой для разработки ERP-систем в
целом. Здесь нельзя не отметить революционной заслуги отечественной компании
Эллай, разработавшей КИС «Ресурс» целиком на технологиях управления знаниями, но
не нашедшей пока широкого признания.

Способность управлять знаниями – условие сохранения
иразвития культуры организации

Различные авторы предпринимали попытки дать классификацию
организационных знаний. Наиболее известными в области управления знаниями
являются классические работы японского исследователя И. Нонака. Именно его
определения относительно двух форм знания - скрытой и явной - упоминаются
наиболее часто . Р. Санчез считал, что по крайней мере, три категории знания
имеют место на фирме: «знать как» (практическое знание), «знать почему»
(теоретическое знание) и «знать что» (стратегическое знание) . М. Уайтхил в
качестве типологии знания выбрал такую классификацию: «знать что»
(закодированное), «знать как» (привычное), «знать почему» (научное) и т.д. .
М. Димарест заострил внимание на коммерческом знании, которое является явно
развитой и управляемой сетью императивов, образцов, правил и сценариев,
включенных в некоторые аспекты фирмы, и распределенных повсюду на фирме, что
обеспечивает результативность ее действий фирмы на рынке . При всей
разнообразности трактовок, очевидно, что организационное знание формирует базу
для развития отличительных способностей и деятельности, увеличивающей стоимость
организации.

Известно, что хранилища информации о предметной области
бизнеса существуют уже давно и компании накопили существенный опыт по их
организации и использованию. Они стали основой такого интеллектуального бизнеса
как управленческий консалтинг (McKenzie, Boston Consulting Group),
аудит и РБП (компании большой пятерки) или высокие
технологии (Hewlett Packard, Cisco).
Некоторые хранилища информации существуют на рынке как отдельный брэнд и
обладают высокой стоимостью: Global Best Practices (Arthur Andersen), Knowledge
Links (Hewlett Packard).

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

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

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

Следуя Р. Куинну, наиболее успешные организации сегодня могут
рассматриваться как интеллектуальные предприятия, способные развивать у себя
базовые способности, основанные на знаниях. . Управление знаниями связано с
генерацией знаний (как у отдельных сотрудников, так и у организации в целом),
формализацией и сохранением знаний, распространением знаний, их координацией и
контролем. Эффективное управление знаниями зависит от организационной структуры,
инфраструктуры и коммуникаций и, следовательно, является производной культуры
организации. Гуру в области КИС К Дж.. Дэйт писал: «Бизнес-правила можно назвать
следующим (и гигантским) шагом в эволюции исходного относительного видения»
. П. Друкер определил знания, как ключевой ресурс мировой экономики.
«Традиционные составляющие производства – земля, труд и капитал – пишет он –
становятся ограничивающими факторами, нежели движущей силой… Знания становятся
основной составляющей производственного процесса» . Накопление знаний в
современном производстве уже не считается «издержкой», а является неотъемлемой
его частью. Иначе говоря, обучение становится новой формой производственного
процесса. По мнению аналитической компании Gartner Group, к 2003 году
предприятия, которые не перешли к модели управления, основанной на знаниях,
будут испытывать серьезные затруднения на рынке из-за резкой потери
конкурентоспособности с вероятностью 70%.

Явное знание – это знание, содержание которого выражено
четко, детали которого могут быть записаны и сохранены. Неявное знание чаще
всего не выражается и основывается на индивидуальном опыте, что делает его
трудным для записи и хранения . Обе формы знания возникают изначально как
индивидуальное знание, но для того, чтобы быть использованными для существенного
улучшения деятельности организации, они должны быть преобразованы в
организационное знание. Практически глобальное распространение в мире с конца
1970-х получила форма представления знаний в виде
правил продукции «ЕСЛИ…, ТО…». Обратный логический вывод позволяет на основе
таких правил получать знания «знать как», «знать почему», «знать что». Однако,
самое важное, это то, что «продукционные знания» идеально выполняет функцию
информационного обеспечения систем ситуационного управления (ССУ). В силу своих
функциональных свойств ССУ помимо поддержки принятия управленческих решений
обеспечивает превращение индивидуальных знаний в знание организационное.

Знания и система ситуационного управления

Модельная теория мышления, развитая в работах В.Н. Пушкина,
послужила основой для разработки метода ситуационного управления большими
системами. Этот метод, возникший во второй половине 60-х годов , во многом
предвосхитил технологию решения задач в системах, опирающихся на знания. ССУ
позволяют накапливать знания о поведении и структурировать знания на ключевые
составляющие без нарушения целостности базы знаний. Пока ССУ находят применение
только в среде, связанной с возможными угрозами обществу (федеральные
ситуационные центры, военные организации, атомная энергетика, железнодорожные
перевозки и т.п.), или, где бессилие человека очевидно (системы управления
автоматами в среде, неприспособленной для жизни человека). Важным преимуществом
ССУ является естественная инструментальная
поддержка описаний БП в виде рефлексных контуров, которые в ССУ представляются
уже упоминаемой триадой - конструктом: (1) процессом наблюдения
(протоколирование ситуаций по формальным правилам); (2) процессом моделирования
(управление базой знаний в виде правил (правил логического вывода) «ЕСЛИ…, ТО…»)
и (3) процессом логического вывода (регулированием).

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

В этом случае представление механизма саморегулирования
организации в виде ССУ обладает рядом преимуществ:

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

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

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

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

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

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

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

ССУ, работающие на основе «аналитических» и лингвистических
правил, относят к классу гибридных экспертных систем . Например, средства
разработки правил и оптимизации в ERP-системах формируют основу такой гибридной
системы. Гибридные системы признаются наиболее перспективными с точки зрения
современной концепции управления знаниями. Именно, осознание возможностей ССУ
позволяет видеть основной недостаток MRP II \ ERP систем начала XXI века в
ограниченности использованием принципов построения хранилищ данных (а не знаний)
как технологии информационного обеспечения этих систем.

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

Кибернетикам известно, что невозможно управлять тем, что
нельзя измерить. Также бессмысленно говорить об управлении неформальным знанием.
Наличие мысли в глазах не означает способности человека воспроизвести эту мысль
даже на словах. Неявное знание принципиально не может закрепиться в организации,
быть товаром, а тем более капиталом организации. Ведь носителем неявных знаний
является персонал, а организации персоналом, как правило, не торгуют!
Статистика, в частности, говорит о том, что в США в среднем 40% сотрудников
компаний проработали в своей организации меньше года, еще 40% собираются
уходить. Вклад "новобранцев" в работу фирмы обычно невелик. Т.е. уходящие
предпочитают уносить информацию с собой. В результате 80% информации компании
остается неосвоенными .

От абстрактному к конкретному

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

На рисунке качественно изображена последовательность развития
представлений о предметной области АСУ БП, которая должна реализоваться в
сознании участников рынка АСУ БП, чтобы цель синергетического единства АСУ БП и
организации была достигнута. Эта последовательность определяется возможностью и
необходимости аналитического расчленения процесса создания АСУ БП на
относительно изолированные абстрактные аспекты . Считается, что впервые такой
метод исследования, исходя из диалектики Гегеля, предложил и отчасти реализовал
К. Маркс в 1857 г. Он назвал его «методом восхождения от абстрактного к
конкретному» . Согласно ОПР - теории каждый уровень развития представлений
описывается своей триадой рефлексии, где Р – регулятор, М – моделятор, А –
анализатор . Взаимодействие между уровнями
осуществляется воздействием регулятора одного уровня на анализатор другого
уровня.

Области 1 и 2 относятся к фундаментальным исследованиям
организационной деятельности и находятся в сфере деятельности интеллектуальной
элиты. С.П. Никаноров пишет об этом так: «Для эффективного применения этого
метода в любой предметной области помимо квалифицированного знания этой области
необходима высокая культура работы с понятиями, понимание роли абстракций,
способность создавать, удерживать и изменять обширные понятийные системы, быть в
состоянии синтезировать абстракции, получая более конкретные понятия,
обеспечивать интерпретацию понятийных схем в эмпирически заданных предметных
областях. … можно утверждать, что неинструментальная работа этого типа со
сложными предметными областями невозможна или доступна лицам, наделенным
феноменальными способностями».

Основными продуктами областей 1 и 2 являются, соответственно,
инструменты моделирования предметной области бизнеса и управления знаниями об
этой области. Продуктом уровня 3, на котором позиционируются внешние и
внутренние бизнес - консультанты, а также конструкторы АСУ БП, являются знания о
БП организации. Они могут быть сформированы в виде моделей БП. Выше говорилось о
том, что единственным способом передачи этих знаний на более высокий уровень
представлений, является их "форматирование" в виде правил. Уровень 4 (уровень
системных аналитиков и технологов БП организации) отвечает за формирование
проектов управленческих решений и, в частности, за внедрение, сопровождение и
развитие спроектированных на предыдущем уровне правил исполнения БП. Высшим
уровнем такого внедрения является внедрение АСУ БП. Уровень 5 - уровень высшего
и операционного менеджмента, анализирующий проекты предлагаемых управленческих
решений, осуществляющий эксплуатацию интеллектуального капитала организации и
непосредственное воздействие на исполнительский уровень 6 выбором конкретного
решения.

Основной недостаток существующей методологии разработки АСУ
БП видится в отсутствии явной взаимосвязи между методологическими уровнями 2 и
3, либо в отсутствии уровней 1 и 2 в цикле разработки АСУ БП. Собственно этот
недостаток является корневой причиной негативных выводов относительно
технологических особенностей современных АСУ БП. В контексте общей для
организаций проблемы выживаемости они состоят в следующем.

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

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

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

    Анализ функциональных особенностей современных АСУ БП
    показывает, что наиболее «продвинутые» MRP\ERP системы включают ключевые
    компоненты, использующие правила, и поэтому находятся в движении от
    объектно-ориентированных систем к системам, ориентированным на знания.
    Скорость движения в этом направлении в большей степени зависит не от
    конструкторов АСУ БП, а от требований потребителей. Однако, факт остается
    фактом. Объектная ориентация АСУ БП еще очень продолжительное время не будет
    решать задач, которая должна ставить перед собой динамично развивающаяся
    организация.

Литература

    1 Бир С. Мозг фирмы. -
    Москва: Радио и связь, 1993.- 416.

    3. Никаноров С. П.
    Характеристика и область применения метода концептуального проектирования
    систем организационного управления. // Концептуальное проектирование систем
    организационного управления (КП СОУ) и его применение в капитальном
    строительстве: Сб. науч. тр.. - Москва: ЦНИИЭУС Госстроя СССР, 1989.- 8-29.

    4 Ладенко И. С. Методология
    и методы организации интеллектуальных систем. - Новосибирск: ИИФФ СО АН
    СССР, 1987.- 66.

    5 Форрестер Д. У. Основы
    кибернетики предприятия. - Москва: Прогресс, 1971.- 340.

    6. Скобелев П. О..
    Виртуальные миры и интеллектуальные агенты для моделирования деятельности
    компании. – Труды VI Национальной конференции по искусственному интеллекту,
    т. 2, г. Пущино, 5 - 7 ноября 1998 г. C. 714 - 719.

    7.
    Справочник. Искусственный интеллект: В 3 кн.
    Кн. 1. Системы общения и экспертные системы /Ред. Попов Э. В. - Москва:
    Радио и связь, 1990.- 464.

    8.
    Фролов Ю. В. Интеллектуальные системы и
    управленческие решения. - Москва: МГПУ, 2000.- 294.

    9.
    Рубцов С.В. Если мы так хорошо образованы, то
    почему мы так неэффективны? // Новые рынки, 2001, 2, 7-13.

    10. Рубцов
    С.В. Основные противоречия современных взглядов на управление бизнесом и
    возможности их разрешения // Управление компанией, 2001, 5

    11. Nonaka I., Teece D. J. Managing
    industrial knowledge: creation, transfer and utilization. - London ;
    Thousand Oaks, Calif.: Sage Publications, 2001.- 344.

    12. Sanchez R., Heene A. Strategic
    learning and knowledge management. - Chichester: J. Wiley and Sons, 1998.-
    235.

    13. Whitehill M. Knowledge-based
    Strategy to Deliver Sustained Competitive Advantage. // Long Range Planning,
    1997, 30, N 4, 621-627.

    14. Demarest M. Understanding Knowledge
    Management. // Long Range Planning, 1997, 30, N 3, 374-384.

    15.
    Зырянов М. Инструментарий для управления знаниями. // ComputerWorld Россия,
    1999, N 7, 15-17.

    16. Foote N. W., Matson E. W., Rudd N.
    W. Managing the Knowledge Manager. // The McKinsey Quarterly, 2001, N 3,
    120-129.

    17. Davenport T. H. Process innovation
    : reengineering work through information technology. - Boston, Mass.:
    Harvard Business School Press, 1993.- 337.

    18. Quinn J. B. Intelligent enterprise
    : a knowledge and service based paradigm for industry. - New York: Free
    Press, 1992.- 473.

    19. Date C. J. What not how: the
    business rules approach to application development. - Reading, Mass.:
    Addison-Wesley Publishing Co., 2000.- 131.

    20. Drucker P. F. Next Information
    Revolution. // Forbes ASAP, 1998, 24 - 33.

    21. Пушкин
    В. Н. Оперативное мышление в больших системах. - Москва, Ленинград: Энергия,
    1965.- 255.

    22.
    Геловани В. А. и др. Интеллектуальные системы поддержки принятия решений в
    нештатных ситуациях с использованием современной информационной технологии.
    - Москва: Эдиториал УРСС, 2000.- 356.

    23. Mavrinac S. C., Siesfeld A. G. An
    Exploratory Investigation of Investors" Information Needs and Value
    Priorities. In "Enterprise Value in the Knowledge Economy: Measuring
    Performance in the Age of Intangibles". - New York: OECD/Ernst and Young
    Center for Business Innovation, 1998.- 49-72.

    24.
    Соловьева Г. В. Учет нематериальных активов. - Москва: Финансы и статистика,
    2001.- 176.

    25.
    Калятин В. О. Интеллектуальная собственность (Исключительные права). -
    Москва: ИНФРА-М, 2000.- 480.

    26. Goonatilake S., Khebbal S.
    Intelligent hybrid systems. - Chichester ; New York: Wiley, 1995.- 325.

    27. Senge P. M., et al . M. The Fifth
    discipline field book: strategies and tools for building a learning
    organization. - New York: Currency, 1994.- 593.

    28. Скотт
    Р. Управление знаниями глазами тех, кто его развивает. // ComputerWorld
    Россия, 1999, N 7, 25-27.

    29. Маркс
    К., Энгельс Ф. Метод политической экономии. В “ПСС. 2-е изд., т. 46, ч. 1”.
    - Москва: Политиздат, 1968.- 17-48.

    30. Рубцов
    С. В. К вопросу о построении общей теории менеджмента. // Менеджмент в
    России и за рубежом, 2000e, 19, N 6, 14-21.

Владимир Мальзам Бизнес-аналитик

Роль методов анализа в управлении процессами

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

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

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

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

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

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

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

Функциональный анализ процессов

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

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

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

  • Прием звонков покупателей, консультирование их, согласование содержания сделки и ее реквизитов;
  • Подготовку пакета документов по сделке;
  • Координацию работы курьеров по доставке документов и товаров, приему наличной оплаты и проведению регистрационных действий в налоговых инспекциях;
Формальное нарушение "принципа разделения труда" в данном случае было уместным и эффективным решением. В период максимального потока звонков, подготовка документов откладывалась, и приемом звонков занимался весь отдел продаж. Когда звонков становилось меньше, высвободившиеся менеджеры работали над подготовкой документов для сопровождения сделок, согласованных по телефону.
В зависимости от набора услуг, для каждой сделки готовилось до 22 документов. В существующей информационной системе для этого требовалось 350 кликов мышью и 25 минут рабочего времени. Разработка модуля информационной системы, позволяющего формировать весь пакет, снизила трудозатраты на эту операцию в 8 раз.
В исходном виде процесса, подготовку части документов менеджерам приходилось откладывать на конец рабочего дня, нередко задерживаясь на работе до 20:00. Далее, курьер доставлял документы клиенту на подпись и оплату. Документы, подготовленные до 17:00 текущего дня, доставлялись клиенту на следующий день. Документы, подготовленные позже, доставлялись "через день". При такой организации, от устного согласования сделки до ее подтверждения подписью клиента и оплатой проходило 2-3 дня.
Доработка информационной системы, помимо снижения себестоимости процесса, легла в основу ряда мер, снизивших в 24 раза время от звонка до фиксации сделки подписью клиента. С 2-3 дней до 2-3 часов. Такая организация снизила риск отказа клиента от устного соглашения и косвенно увеличила объем продаж.

План-факторный анализ показателей

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

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

Пример: предприятие ЖКХ столкнулось с проблемой собираемости платежей.

Исходная задача была поставлена так: бухгалтер по начислению коммунальных услуг, льгот и субсидий не справляется с объемом работы. В начислениях есть ошибки, результаты расчетов хранятся в бумажном виде. При обслуживании очереди плательщиков и возникновении спорных ситуаций, невозможно быстро отследить и обосновать историю формирования суммы к оплате. Это провоцирует подозрения клиентов в злоупотреблениях и конфликтные ситуации, приводящие к отказу плательщиков от погашения задолженности.
Автоматизация начисления платежей позволила исключить ошибки в расчетах. При общении с клиентом, бухгалтер мог за 8 секунд отследить и объяснить историю формирования любой цифры. Прозрачность начисления принесла в работу ряд положительных следствий. Конфликты исчезли, но собираемость увеличилась лишь на 3-5%.
Далее, фокус внимания был перенесен с оптимизации существующих процессов, дающих 80% собираемости, на выявление факторов, обуславливающих отказ от оплаты оставшихся 20%. План-факторный анализ выявил причины отказа от погашения задолженности и позволил найти решения по устранению или сглаживанию их негативного влияния:

Фактор №1 - плательщик имеет низкий доход и не может выплачивать полную сумму самостоятельно. По закону, плательщик имеет право платить за услуги ЖКХ сумму, не превышающую 20% дохода семьи. Разница субсидируется государством. Для реализации права на субсидию, плательщик должен ежеквартально предоставлять утвержденный пакет документов. Плательщик часто не знает о своем праве на субсидию, либо не знает, как его реализовать.
Решение: сделать все, чтобы плательщик, имеющий право на субсидию, ее получал. Консультировать по порядку оформления, обеспечить необходимыми справками со своей стороны. Далее, требовать самостоятельной оплаты оставшихся двадцати процентов.

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

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

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

1. Невозможно повысить результативность, анализируя процесс

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

2. Между негативными факторами взаимосвязей не существует

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

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

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

Структурный анализ процессов

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

Структурный анализ выявляет два типа ошибок:

  1. Ошибки целеполагания;
  2. Несоответствия между полномочиями и ответственностью;

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

Вне зависимости от причин возникновения, эти ошибки ведут к некорректному выбору KPI. Мотивация на достижение некорректного KPI несет ряд крайне негативных последствий:

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

О технологии анализа

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

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

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

Пример №1

На одном из проектов была поставлена задача - повысить показатели отдела продаж. Изначально этому отделу был назначен KPI "объем продаж", что на первый взгляд логично. На объем продаж была ориентирована и жесткая система мотивации - полностью отсутствовала окладная часть зарплаты, только процент с продаж.

Исходный KPI "объем продаж", диктовал нечеткий способ достижения - "больше и лучше работать". К такой цели невозможно было применить план-факторный анализ. Замена KPI на "процент обращений, завершенных сделками" открыл план-факторной разрез - "что повлияло на отказ клиентов от сделки". Далее, план-факторный анализ выявил 12 факторов (!), повышающих риск отказа клиента от сделки. Были внесены изменения в процесс, исключающие саму возможность проявления многих факторов и существенно сглаживающие негативные эффекты от оставшихся.

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

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

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

Пример №2

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

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

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

Декомпозиция стратегии на целевые показатели

Суть управления организацией состоит в увязке содержания деятельности с меняющимися внешними условиями:

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

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

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

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

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

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

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

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

Обзор классических инструментов управления и систем BI

Влияние качества инструментов управления на эффективность методов анализа

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

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

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

Чем обусловлена такая ситуация

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

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

Какие риски она привносит

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

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

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

Регламентация

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

Работа юридических инструментов основывается на следующей логике:

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

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

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

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

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

Типичные недостатки регламентации

  1. Требования к компетенциям Применение юридических инструментов требует понимания принципов их работы всеми сторонами, включая исполнителей. В ВУЗах преподают такие знания студентам, обучающимся по специальности "Менеджмент организации". На управленческих же должностях, как правило, лучше себя проявляют не выпускники кафедр абстрактного менеджмента, а руководители с профильным образованием в той области, которой они руководят. Это провоцирует отношение к регламентации как к самоцели, использование НРД часто вырождается из системного проектирования в бесцельную ритуальную рутину.
    Если подготовкой регламента занимается не руководитель, а выделенный специалист, даже понимающий суть своей деятельности, он все равно опасается негативной оценки вышестоящим руководством степени псевдонаучности своей работы. Такие опасения могут быть мнимыми или обоснованными, результат будет одинаков - документ осознанно будет подготовлен в нечитаемом, канцелярском стиле, с целью не обеспечить эффективность процесса, а получить подпись директора.
  2. Некритичность к ошибкам Юридический инструмент некритичен к ошибкам, у исполнителя всегда есть возможность проигнорировать некорректное требование и выполнить задачу "по ситуации". Это еще один фактор, который не мотивирует разработчика к качественной проработке регламентов. Дефекты проработки могут сколь угодно снижать эффективность деятельности, об этом никто никогда не узнает. Выявлены будут лишь те ошибки, которые провоцируют серьезные конфликты между участниками процесса.
  3. Отсутствие обратной связи с исполнителями Легкость обхода требований регламента и формальный риск наказания, мотивируют исполнителя замалчивать информацию о потере регламентом актуальности. В итоге "инструмент управления" превращается в "инструмент догоняющего документирования" - он не решает никаких задач и поддерживается из принципа "так принято, все так делают". С потерей актуальности, система НРД превращается либо в библиотеку ни к чему не обязывающей макулатуры, либо в фактор, вызывающий деструктивное психологическое давление на ответственных и эффективных исполнителей, из-за потенциальной ответственности за вынужденные нарушения.

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

Системный недостаток регламентации

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

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

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

Автоматизация

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

Автоматизация имеет два недостатка:

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

Информационные системы класса BPMS предназначены для совмещения автоматизации, электронной регламентации и сквозного контроля исполнения процессов.

Системы BI (отступление)

Прежде чем описать третий тип инструментов (BPMS), раскрою термин BI, поскольку в дальнейшем придется его использовать.

Аббревиатура BI расшифровывается как "бизнес-интеллект". В период зарождения термина, предполагалось, что главным преимуществом этого инструмента станет "data mining" – алгоритмы "искусственного интеллекта", способные находить в данных компании неочевидные закономерности, полезные для управления бизнесом. Впоследствии, производители BI-систем не смогли выработать действительно полезных алгоритмов и "бизнес-интеллект" стал маркетинговым ярлыком, за которым стоит очередное поколение OLAP-систем.

BI-система представляет собой связку из:

  • Отдельной базы данных;
  • Инструментов анализа многомерного массива данных и наглядного отображения результатов;
  • Инструментов интеграции, для загрузки исходных данных из внешних систем;

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

  • Не перегружать поисковыми запросами исходные информационные системы (ИС);
  • Одновременно использовать, для анализа, данные, загруженные из функционально разных ИС;
  • Консолидировать данные из одинаковых систем, использующих для работы отдельные экземпляры баз данных. К примеру, данные региональных филиалов.

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

BI-системы позволяют без привлечения ИТ-специалистов:

  • Выполнять произвольные поисковые запросы и анализировать результаты в различных срезах;
  • Создавать периодические отчеты и автоматизировать их рассылку заданным пользователям;
  • Выводить результаты запросов в виде панелей индикаторов и назначать пользователям (менеджерам) права доступа к ним;
  • Предоставлять доступ к отчетам и панелям индикаторов через смартфоны и планшеты;

Примеры управленческих панелей индикаторов:


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

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

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

BPMS. Принципы работы, преимущества и ограничения

Информационные системы класса BPMS созданы для замещения большей части регламентов, классических информационных систем (ИС) и сбора управленческой аналитики. Расшифровывается BPMS, как "Business Process Management Suite" и в переводе означает "набор инструментов управления бизнес-процессами".

BPMS представляет собой сплав классической информационной системы и "Workflow engine" - "движка" рассылки пользовательских задач. "Workflow engine" имеет много общего с электронной почтой, но есть и отличия:

Workflow и E-mail - отличие №1

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

Скриншот 1 - Рабочее место Исполнителя

Workflow и E-mail - отличие №2

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

Скриншот 2 - Интерфейс Разработчика процессов

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

  1. В окно модели, для каждого исполнителя, мышью переносятся "области ответственности". На скриншоте №2 они отображены в виде вертикальных полей с наименованиями:
    • "Администратор продающего подразделения";
    • "Работник операционной поддержки";
    • "Андеррайтер";
  2. В областях ответственности размещаются "Задачи";
  3. Порядок исполнения Задач задается "стрелками";
  4. В "шлюзах" настраивается логика ветвления;

Шлюз на скриншоте №2, реализует следующую логику:

  • Если группа риска профессии страхователя пятая или выше - сформировать для андеррайтера Задачу "Рассчитать и утвердить андеррайтерский коэффициент";
  • Иначе, если группа риска ниже пятой, исполнить Задачу-скрипт "Рассчитать страховую премию и сформировать маску полиса";

Workflow и E-mail - отличие №3

В электронной почте есть одно основное поле, в которое помещается вся информация, в неструктурированном виде.

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

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

В workflow-модуле работнику приходит Задача, с интерфейсом, настроенным только под ее решение. Нет лишних элементов. Потребность в обучении отсутствует, риск ошибки снижается на порядки.

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

Обычно интерфейс содержит:

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

Интерфейс Задачи создается в два этапа

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

Скриншот 3 - Табличная регистрация типов данных процесса

Второй этап: разработчик открывает свойства каждой Задачи и переносит мышью необходимые поля из "списка данных" на макет пользовательского интерфейса.

Скриншот 4 - Перенос полей из списка данных в макет интерфейса Задачи

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

Прочие компоненты BPMS

Кроме workflow-модуля, BPMS включает стандартные возможности классической информационной системы:

  1. Автоматизацию математических и логических вычислений;
  2. Формирование отчетов и управленческих панелей индикаторов;
  3. Подготовку форм для печати на принтере;
  4. Некоторые BPMS содержат модули интеграции с внешними системами: IP-телефонией, 1С-бухгалтерией, корпоративным сайтом, сервисами SMS-информирования и т.п.

Для автоматизации вычислений, в модель процесса помещается Задача типа "скрипт", в ее свойства вписывается алгоритм обработки. На скриншоте №2 вы можете увидеть такую Задачу с наименованием "Рассчитать страховую премию и сформировать маску полиса". В системах разных производителей используют разные языки программирования скриптов – C# (СиШарп), Java или JavaScript.

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

В итоге, разработка исполняемых процессов содержит шесть этапов:

  1. Создать модель процесса;
  2. Создать список данных;
  3. Создать индивидуальный пользовательский интерфейс для каждой Задачи;
  4. Настроить логику шлюзов;
  5. Прописать скрипты автоматизации;
  6. При необходимости, обеспечить интеграцию с внешними системами (если нет готового модуля интеграции, потребуется привлечение ИТ-специалиста);
  7. Увязать пользовательские учетные записи с ролями в процессе;

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

Преимущества BPMS

Внедрение BPMS позволяет решить следующие задачи:

  1. Снизить стоимость и длительность разработки программного обеспечения в 10-30 раз Разработка процессного приложения занимает 5-30 дней, корректировка (акт управления процессом) - от 10 минут до 4 дней. 90% трудозатрат реализуется подготовленным бизнес-пользователем, без привлечения ИТ-специалистов.
    Разработка организована по принципу переноса мышью объектов и заполнения таблиц. Бизнес-пользователь может создать более качественный продукт, сосредоточившись на решении задач организации, вместо "борьбы с техническими трудностями", обусловленными избыточной сложностью классических языков программирования;
  2. Сократить до нескольких минут длительность внедрения актуальных версий процесса Глубокие изменения в компании, путем регламентации, занимают 1-2 месяца, с множеством непреднамеренных ошибок работников и их исправлением, в период адаптации. Внесенные в регламенты несущественные изменения, нередко игнорируется работниками.
    Процесс в BPMS, "публикуется на сервер" в горячем режиме и не требует приостановки работы исполнителей. Сразу после "публикации" все филиалы начинают работать по новой версии.
  3. В разы снизить временные затраты на переобучение работников Система позволяет отказаться от заучивания большой части документации. При внесении изменений в процесс, в большинстве случаев, исполнителей не потребуется об этом даже уведомлять. Логика взаимодействия администрируется без их участия. А содержание Задачи, при необходимости, прописывается в ее интерфейсе. Работнику остается делать то, что от него требует логика и описание интерфейса;
  4. Свести к нулю затраты на поддержку в актуальном состоянии моделей процессов и перенесенных в систему регламентов Модели процессов пригодны для функционального и структурного анализа в любой момент времени. Исключается необходимость начинать каждую итерацию анализа с проекта по повторному описанию (актуализации) процессов.
    Электронные регламенты (процессные приложения) также актуальны в любой момент времени. Обойти большинство требований электронных регламентов нет технической возможности. Если работник обнаружил необходимость в актуализации, ему придется эскалировать эту проблему руководству. В течение 1-4 дней процесс будет доработан и исполнитель сможет решить возникшую проблему.
  5. В разы снизить стоимость контроля показателей процессов При бумажной регламентации, учет многих показателей не ведется, поскольку стоимость его реализации неоправданно высока. Это отражается в качестве управленческих решений. В системах BPMS временные затраты на исполнение Задач не требуют организации учета - эта функция вшита в систему. Сбор статистики по отклонениям от оптимального хода процесса - тоже базовая функция.
    Интегрированный BI-инструментарий позволяет, без привлечения ИТ-специалистов, организовать контроль любых показателей процесса. Выигрыш, по сравнению с внешними BI-системами, в том что, при корректировке процесса, часто требуется корректировка и системы его контроля. Встроенный BI-инструментарий требует на настройку несколько десятков минут, вместо нескольких дней/недель, характерных для перенастройки интеграции с внешними BI-системами.

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

Ограничения BPMS

В наибольшей степени BPMS проявляют свои преимущества, если характер деятельности укладывается в некоторые ограничения:

  1. Исполнитель имеет на рабочем месте компьютер, планшет или смартфон с подключенным интернетом или локальной сетью организации. С распространением смартфонов и планшетов это ограничение становится все менее актуальным.
  2. Требуется координация работы нескольких исполнителей;
  3. Характер процесса подразумевает, что его корректное исполнение гарантирует получение требуемого результата;

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

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

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

Может ли BPMS полностью заменить ИТ-системы?

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

Может ли BPMS полностью заменить распорядительную документацию?

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

Выгоды от BPMS пропорциональны:

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

Этим объясняется востребованность систем BPMS в страховой, банковской и некоторых других сферах услуг.

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

Заключение

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

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

  1. Специализированные ИС

В этом блоке останутся:

  • Сервисы, предоставляемые другими организациями: интернет-эквайринг, sms-информирование, ip-телефония, расчет маршрутов в яндекс-картах и т.п.
  • Частично, функционал уже используемых в организации информационных систем. Та часть, которую проще интегрировать с BPMS, чем переносить в формат скриптов.
  1. Скрипты процессов - алгоритмы обработки информации, которых нет в старых информационных системах или которые дешевле прописать заново, чем реализовывать путем интеграции. В дальнейшем, в рамках управления процессами, их будет проще и быстрее корректировать, чем связку из функций старой системы и функций интеграции с ней;
  2. Электронные регламенты (Workflow)

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

  1. Юридические регламенты

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

Системы управления бизнес-процессами пришли в Россию с Запада, где этот класс решений называют BPM-системами или BPMS (Business Process Management System). Их основная цель - осуществлять программную поддержку процессного управления в организациях.

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

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

Основные стадии внедрения процессов

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

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

ELMA BPM обладает широким количеством возможностей, которые обеспечивают выполнение и поддержание бизнес-процессов. При этом все функции системы можно условно разделить на 4 группы в соответствии со стадиями жизненного цикла процесса PDCA (цикл Деминга) - планирование (plan), выполнение (do), контроль (check), улучшение (act).

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

ELMA BPM позволяет автоматизировать:

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

Узнайте подробнее о том, какие бывают процессы в организации. Смотрите универсальную классификацию бизнес-процессов APQC PCF (Process Classification Framework)

Проектирование (моделирование) бизнес-процессов

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

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


Моделирование бизнес-процессов

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

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

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

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


Внутри бизнес-процесса двигаются данные

Исполнение бизнес-процессов

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

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

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


Карточка задачи в системе ELMA
Все входящие и исходящие задачи в одном месте

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

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

Контроль и мониторинг бизнес-процессов

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

Организация бизнес-процессов в системе ELMA открывает широкие возможности мониторинга их выполнения. В распоряжении пользователей есть несколько инструментов:

  • Страница «Мои процессы» содержит список всех экземпляров бизнес-процессов, в которых сотрудник является инициатором, ответственным или исполнителем. Есть удобный фильтр для поиска. Выбрав определенный экземпляр процесса из списка, можно перейти на его карточку в системе.
  • Страница «Монитор процессов» позволяет анализировать работу по процессам, в которых пользователь выступает в роли владельца, куратора или информируемого. На этой стадии управления сотруднику не обязательно являться исполнителем какой-либо из операций. Со страницы «Монитор процессов» можно перейти на карточку любого из отображаемых процессов, чтобы получить подробную информацию.
  • Карта процесса - еще один удобный способ мониторинга. Она выглядит так же, как и графическая модель процесса в Дизайнере ELMA. При этом на карте отображается уже запущенный в системе экземпляр конкретного бизнес-процесса, что позволяет отслеживать дополнительные метки. Здесь обозначаются уже выполненные операции и текущая стадия работы. Открыть карту процесса можно из его карточки в системе.

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


Монитор бизнес-процессов показывает ситуацию в целом
Отображение хода работы на Карте процесса

Оптимизация бизнес-процессов

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


Бизнес-процессы изменяются вместе с компанией

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

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

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

Размещено на сайте 07.05.2009

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

В.А. Лопатин, Внешэкономбанк

Введение

Словосочетание «управление бизнес-процессами» (УБП) стало активно использоваться в литературе относительно недавно, с середины 90-х годов прошлого столетия, практически одновременно с английским аналогом Business Process Management (BPM).

В свою очередь, BPM появился в противовес BPR (Business Process Reengineering), что означает реинжиниринг бизнес-процессов, или «принципиальное переосмысление и радикальная перестройка бизнес-процессов для достижения кардинальных улучшений критических современных показателей эффективности: стоимости, качества, сервиса и оперативности» 2 .

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

С момента своего появления BPM редко рассматривался только как направление менеджмента. В частности, среди его определений можно встретить следующие:

Достижение целей организации посредством совершенствования, управления и контроля основных бизнес-процессов 3 ;

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

Концепции, методы и технологии для поддержки проектирования, администрирования, конфигурирования, исполнения и анализа бизнес-процессов 5 ;

Метод эффективного выстраивания организации в соответствии с пожеланиями и нуждами клиентов 6 .

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

В современном варианте BPM и УБП являются развитием идей процессного подхода, получившего распространение в многочисленных системах менеджмента качества и в методах проектирования и реинжиниринга процессов. Они интегрируют наиболее адекватные, результативные и эффективные методы всеобщего контроля качества TQC (Total Quality Control), всеобщего менеджмента качества TQM (Total Quality Management), реинжиниринга бизнес-процессов BPR, непрерывного совершенствования Kaizen, производства «шесть сигм» Six Sigma, «бережливого производства» Lean Production и т.д.

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

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

— специалисты на личном опыте убедились, что использование концепции бизнес-процессов позволяет создавать более эффективные инструменты управленческого планирования, учета и контроля;

— на рынке появился новый тип программного обеспечения — BPMS (Business Process Management System), который позволяет организациям разрабатывать процессно-ориентированные решения, способные объединять людей, системы и данные 7 ;

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

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

1. Основные понятия

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

На рисунке 1 показана структурная схема системы управления бизнес-процессами (СУБП), причем стрелками обозначено ее взаимодействие с внешней средой.

Обсуждение СУБП логично построить вокруг изучения следующих вопросов:

В какую систему СУБП входит как часть?

Какую функцию выполняет СУБП?

Какова внутренняя структура СУБП?

Что представляют собой элементы структуры СУБП?

Что представляет собой СУБП как система управления?

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

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

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

1.1. Процесс

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

Слово «процесс» произошло от латинского слова processus (продвижение) и означает 9:

1) ход какого-либо явления, последовательную смену состояний, стадий развития и т.д.;

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

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

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

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

На самом деле речь идет не о двух видах процесса, а о двух представлениях (аспектах) одного процесса:

— объектно-центрированном представлении или представлении, ориентированном на состояния объектов, задействованных в процессе;

— субъектно-центрированном представлении или представлении, ориентированном на действия субъектов, участвующих в процессе.

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

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

Фактически мы вынуждены рассматривать не реальные процессы, а их модели, то есть их описания на каком-либо формализованном языке. Например, описания действий и состояний субъектов и объектов в виде текстов на русском, английском и других языках. Или диаграммы представлений процессов, например объектно-центрированные Object-Centered View и субъектно-центрированные Process-Centered View в нотации IDEF3 11 .

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

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

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

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

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

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

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

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

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

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

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

1) даже очень сложные шаблоны не могут предусмотреть все ситуации;

2) чем сложнее шаблон, тем больше ошибок моделирования;

3) чем сложнее шаблон, тем сложнее находить и исправлять дефекты модели.

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

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

1.2. Идентификация процессов

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

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

а) существует ограниченное время (процесс имеет начало и окончание);

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

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

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

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

При выделении процессов возникают две проблемы.

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

Например, выдачу кредита можно представить в виде шести действий:

1) получение документов заемщика;

2) проверка документов;

3) анализ документов;

4) получение согласия кредитного комитета;

5) заключение договоров;

6) предоставление средств в распоряжение заемщика.

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

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

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

Внесение изменений в проект договора можно включить как в совокупность действий по подготовке проекта договора, так и в совокупность действий по согласованию договора.

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

1.3. Система процессов

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

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

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

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

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

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

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

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

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

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

— входы, выходы, ресурсы и продукты каждого процесса;

— совокупность действий, составляющих процесс и логику осуществления действий;

— временные характеристики процесса и т.д.

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

Знание структуры системы процессов позволяет осуществить классификацию процессов.

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

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

Например, в соответствии со стандартом функционального моделирования IDEF0 (стандартизован Национальным институтом по стандартизации США и в 2001 г. рекомендован Госстандартом России 14) все процессы группируются по четырем уровням иерархии («деятельность», «процесс», «операция» и «действие»), к которым при необходимости могут быть добавлены еще два («субдеятельность» и «субпроцесс»).

А в соответствии с классификацией PCF (Process Classification Framework) 15 , созданной и обновляемой Американским центром производительности и качества APQC (American Productivity & Quality Center), процессы группируются по четырем уровням иерархии («категории», «группы процессов», «процессы» и «виды деятельности») и по группам в пределах каждого уровня (12 категорий, 63 группы процессов, 229 процессов и 646 видов деятельности).

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

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

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

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

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

1.4. Система бизнес-процессов

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

Прежде чем перейти к правилам выделения СБП, остановимся на центральном понятии настоящей статьи — термине «бизнес-процесс».

Трудно сказать, кто автор словосочетания «бизнес-процесс», но активно оно стало использоваться с начала 90-х годов прошлого столетия основателями реинжиниринга бизнес-процессов Дэвенпортом, Хаммером, Чампи и др. До этого для тех же целей употреблялся термин «процесс» (в основном в системах менеджмента качества).

Существует огромное количество определений терминов «процесс» и «бизнес-процесс».

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

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

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

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

С появлением реинжиниринга и термина «бизнес-процесс» специалисты стали чаще анализировать процессы с точки зрения бизнеса.

Чтобы осознать разнообразие терминов «процесс» и «бизнес-процесс», приведем семь наиболее известных определений:

1) «процесс — завершенная с точки зрения содержания, временной и логической очередности последовательность операций, необходимых для обработки экономически значимого объекта» 17 ;

2) «процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы» 18 ;

3) «процесс — последовательность взаимосвязанных работ, имеющих своей целью потребление входов процесса и их преобразование в выходы, требующиеся внутренним или внешним потребителям, сопровождаемое созданием добавленной стоимости» 19 ;

4) «бизнес-процесс — это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя» 20 ;

5) «бизнес-процесс — комплекс действий, в котором на основе одного или более видов исходных данных создается ценный для клиента результат» 21 ;

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

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

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

— в первом случае термины «процесс» и «бизнес-процесс» считаются эквивалентными и взаимозаменяемыми (как это и делают многие специалисты по бизнес-процессам);

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

В данной статье используется второй вариант:

а) считается, что существует много видов процесса, отличающихся масштабом и названием, причем бизнес-процесс является одним из таких видов;

б) определение видов процесса осуществляется на этапе идентификации процессов;

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

Можно привести несколько правил, которыми можно руководствоваться при выделении СБП из СП:

— желательно ограничить СБП двумя уровнями вертикальной структуры СП, назвав их, например, «бизнес-процессы» и «виды деятельности» 24 ;

— выбор уровней желательно осуществлять с учетом полномочий владельца СБП. Например, СУБП руководителя банка и СУБП руководителя департамента банка будут иметь существенно различные СБП;

— желательно ограничить СБП размером не более 20 бизнес-процессов. Оптимальным, по мнению автора, является число от 7 до 15 бизнес-процессов;

— размер каждого бизнес-процесса в рамках СБП желательно ограничить размером не более 50 видов деятельности. Оптимальным, по мнению автора, является число от 15 до 30 видов деятельности (хотя, надо сказать, автор встречал бизнес-процесс, построенный из 230 видов деятельности 25).

2. Управление бизнес-процессами

Как известно, под управлением может пониматься:

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

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

б) система управления, которая включает процесс управления и объект управления. При этом объектом управления является некоторый процесс или система процессов.

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

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

2.1. Управление системой бизнес-процессов

Система управления бизнес-процессами (СУБП) является подсистемой системы управления организацией в целом. Как правило, при выделении СУБП в отдельное направление менеджмента перед СУБП ставят две основные цели:

1) обеспечить конкурентоспособность бизнес-процессов;

2) обеспечить бесперебойную работу бизнес-процессов.

Для достижения первой цели СУБП должна решать задачи перспективного совершенствования бизнес-процессов и развития средств совершенствования бизнес-процессов.

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

Чтобы понять, каким образом СУБП решает поставленные задачи, вспомним, что объект управления — СБП — имеет две грани: шаблон СБП и экземпляр СБП. Шаблон СБП, как обычно, представляет собой модель используемой СБП, а экземпляр СБП — реальную СБП, управление которой осуществляет владелец СБП.

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

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

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

Заметим, что управление экземпляром СБП также включает два направления:

1) управление каждым бизнес-процессом в отдельности;

2) управление связями между отдельными бизнес-процессами.

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

В заключение приведем определение термина «управление системой бизнес-процессов» (точнее «система управления бизнес-процессами», или СУБП), соответствующее вышеприведенным рассуждениям:

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

Если частично пожертвовать строгостью, можно дать более короткое определение:

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

2.2. Управление отдельным бизнес-процессом

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

Управление отдельным бизнес-процессом включает:

а) управление шаблоном бизнес-процесса;

б) управление совокупностью экземпляров бизнес-процесса.

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

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

Может возникнуть вопрос: каким образом автоматизация бизнес-процесса изменяет шаблон бизнес-процесса?

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

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

Управление шаблоном бизнес-процесса направлено на изменение параметров шаблона и осуществляется:

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

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

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

Управление совокупностью экземпляров бизнес-процессов (или управление текущим функционированием бизнес-процесса) включает (рис. 7):

— управление каждым экземпляром бизнес-процесса в отдельности;

— управление взаимодействием между экземплярами бизнес-процесса.

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

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

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

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

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

Перечислим возможные дефекты алгоритма управления функционированием:

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

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

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

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

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

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

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

Управление автоматизацией включает автоматизацию самого бизнес-процесса и автоматизацию средств проектирования, развертывания, мониторинга, анализа и оценки бизнес-процесса.

Автоматизация бизнес-процессов осуществляется с использованием огромного числа систем, включая системы класса АБС, ERP, CRM и т.д. При этом современные тенденции автоматизации нацелены на широкую интеграцию систем разного класса с использованием средств интеграции приложений EAI (Enterprise Application Integration), сервис-ориентированной архитектуры SOA (Service-Oriented Architecture), сервисной шины предприятия ESB (Enterprise Service Bus) и др.

Автоматизацию средств проектирования, развертывания и мониторинга может обеспечить внедрение системы класса BPMS (Business Process Management System), которая, как правило, включает модуль проектирования бизнес-процессов BPD (Business Process Design), развертывания бизнес-процессов BPE (Business Process Engine) и мониторинга бизнес-процессов BAM (Business Activity Monitoring).

Наконец, автоматизацию средств анализа и оценки бизнес-процесса можно осуществить с помощью аналитической системы класса BI (Business Intelligence).

2.3. Управление совершенствованием бизнес-процесса

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

Рис. 8. Совершенствование бизнес-процесса

Как правило, решение проблемы состоит из трех этапов:

1) выявление и анализ проблемы;

2) конструирование решения;

3) реализация решения.

Рассмотрим более подробно эти этапы.

Выявление и анализ проблемы включает следующие шаги:

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

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

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

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

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

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

определение дефектных элементов существующей системы. На данном этапе осуществляется оценка структурных элементов процесса путем использования различных методов анализа, включая стратегический анализ, финансовый анализ, анализ рисков и т.д. В частности, на этом этапе может использоваться анализ бизнес-процесса с точки зрения сбалансированной системы показателей BSC (Balance Score Card) и калькуляции затрат по направлениям деятельности ABC (Activity Based Costing);

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

Конструирование решения включает:

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

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

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

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

Наконец, реализация решения включает:

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

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

реализация решения. Осуществляется замена старого шаблона процесса на новый. С этого момента реализация новых экземпляров процесса идет по новому шаблону.

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

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

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

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

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

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

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

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

3.1. Недостатки функционально-организационной структуры

В основе функционального подхода лежат следующие базовые принципы:

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

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

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

4) исходя из установленных целей и задач, организация разрабатывает технологические инструкции, в которых регламентирует действия, необходимые для достижения заданных результатов;

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

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

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

Рассмотрим, например, процедуру принятия решения о внесении изменений в одну из технологических инструкций.

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

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

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

3.2. Недостатки процессно-организационной структуры

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

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

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

3.3. Цепочка «функции—процессы—результаты»

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

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

Слово «функция» произошло от латинского слова function (исполнение) и означает «обязанность, круг деятельности; назначение, роль» 27 . То есть содержанием термина «функция» является не столько действие, сколько потенциальная возможность осуществления действия 28 .

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

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

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

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

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

3.4. Функционально-процессный подход

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

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

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

1 - ГОСТ Р ИСО 9000. Системы менеджмента качества. Основные положения и словарь.

2 - Хаммер М., Чампи Дж. Реинжиниринг корпорации. Манифест революции в бизнесе. — М.: Манн, Иванов и Фербер, 2006.

3 - Джестон Дж., Нелис Й. Управление бизнес-процессами. Практическое руководство по успешной реализации проектов. — СПб.-М.: Символ-Плюс, 2008.

4 - Chang James F. Business Process Management Systems. Auerbach Publications, 2006.

5 - Mathias Weske. Business Process Management. Concepts, Languages, Architechures. Springer, 2007.

6 - http://en.wikipedia.org/wiki/Business_Process_Management

7 - Chang James F., op. cit.

8 - Розенблют А., Винер Н. Бигелоу Дж. Поведение, целенаправленность и телеология. / В кн.: Винер Н. Кибернетика, или управление и связь в животном и машине. — М.: Наука, 1983.

9 - Словарь иностранных слов. — М.: Русский язык, 1988.

10 - Например, иногда в процессах выделяют действия типа system-to-system, которые выполняют компьютеры.

11 - Стандарт описания процессов IDEF3 Process Description Capture Method (http://www.idef.com/pdf/Idef3_fn.pdf).

12 - Никаноров С.П. Системный анализ: этап развития методологии решения проблем в США / В кн.: Оптнер Ст. Л. Системный анализ для решения проблем бизнеса и промышленности. — М.: Советское радио, 1969.

13 - Эмерджентность — не

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

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

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

    Что дает процессный подход крупному бизнесу?

    С чего начать построение системы управления бизнес-процессами?

Для чего строить систему управления бизнес-процессами?

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

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

Взгляд на процессы позволяет:

Уровни зрелости бизнес-процессов

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

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

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

Основные процессы – суть деятельности компании. Процессы, которые приносят деньги.

Сервисные процессы – съедают деньги компании, при этом обеспечивают стабильное функционирование основных бизнес-процессов.

Кроме этого, важно понимать, что у каждого процесса существуют уровни зрелости:

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

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

    Уровень 3 (автоматизированный, измеримый). Процесс, либо его часть, автоматизирован в ИТ-системе (SAP, 1С, Oracle, Axapta, Галактика, Парус и т.д.)

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

    Уровень 5. Развитие процессов связано со стратегией компании.

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

Уровень зрелости 2

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


Уровень зрелости 3

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

На этом этапе компания может столкнуться с рядом сложностей:

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

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

    Метрики процесса остаются за рамками проекта внедрения.

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

    В автоматизированной системе процесс «цементируется» и не меняется годами.

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

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

С каких процессов начать?

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

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

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

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

Система управления бизнес-процессами концентрируется именно на 4 и 5 уровнях зрелости. Если в компании есть ERP либо учетная система, это хорошо, но это только часть управления процессами предприятия. Основная задача системы управления бизнес-процессами – развитие процессов, которое позволяет увеличить экономический потенциал с операционной и стратегической точек зрения.

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

Система управления бизнес-процессами должна охватывать 4 уровня работы компании. Только в этом случае она будет работать.

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

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

    Разумеется, процессы должны исполняться.

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

Уровень управления процессами

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

Например, в процессе «Обработка заказа клиента» можно выделить следующие метрики и показатели:

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

В крупных компаниях это выглядит следующим образом:

Показатели деятельности – то, что видят топ-менеджеры компаний на своих мониторах в рамках отчетности, инфопанелей в SAP, Oracle, Axapta и других подобных системах.

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

Таким образом, развитие процессов до 4 и 5 уровней зрелости, на которое ориентирована система управления бизнес-процессами – не просто автоматизация исполнения. Нам нужно знать текущие метрики и KPI бизнес-процессов, чтобы понимать, как развивать процессы для достижения стратегических целей компании. Оперативно вносить изменения и отслеживать результаты.

Уровень исполнения процессов (автоматизация)

На уровне исполнения бизнес-процессов встречаются три возможных сценария развития событий:


Для чего устранять лоскутную автоматизацию и переводить процесс в BPMS?

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

Когда высшее руководство ставит задачу по совершенствованию работы компании – например, снизить количество брака, владелец процесса транслирует эту задачу ниже:

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

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

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

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

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

Похожие публикации