Системы управления бизнес-процессами. Управление бизнес процессами Первый этап построения системы управления бизнес процессами

BPMS (Business Process Management Suite ) – это класс программного обеспечения для управления бизнес-процессами и административными регламентами (употребляются также термины BPM-система и просто BPM). Использование BPMS позволяет организовать эффектинное взаимодействие между управленцами и ИТ-специалистами, лучше использовать существующие и ускорить разработку новых информационных систем. Основные функции BPMS - моделирование, исполнение и мониторинг бизнес-процессов. Основываясь на данных мониторинга, организации выявляют узкие места и усовершенствуют свои бизнес-процессы. Цикл управления замыкается, когда при помощи BPMS измененные бизнес-процессы оперативно внедряются в эксплуатацию.

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

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

Рисунок 8.5 – Бизнес-схема предприятия

Основная идея BPM-системы предельно проста.

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

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

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

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

Проектирование. Под проектированием понимается разработка схемы бизнес-процесса. В состав BPM-системы обычно входят:

1. Графический дизайнер для рисования схемы бизнес-процесса
2. Репозиторий для ее хранения и организации совместного доступа

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

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

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

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

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

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

Рисунок 8.6

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

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

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

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

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

Мониторинг. BPM-система осуществляет контроль бизнес-процессов двумя путями:

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

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

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

BPM-системы, как правило, предоставляют базовый набор отчетов по показателям бизнес-процессов. На их основе могут быть сконструированы т.н. «ключевые показатели эффективности» (KPI, Key Performance Indicators), которые, в свою очередь, могут быть увязаны с «системой сбалансированных показателей» (BSC, Balanced Scoreсard).

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

Рисунок 8.7

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

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

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

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

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

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

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

2. Организационная концепция

Организационная концепция включает пять элементов:

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

Определив процессы верхнего уровня, составляем их концептуальное описание. Описание включает следующие элементы:

  1. Клиенты процесса.
  2. Цели процесса.
  3. Результаты процесса.
  4. Ресурсы процесса.
  5. Поставщики процесса.
  6. Исполнители процесса.
  7. Владелец процесса.
  8. Показатели процесса.
  9. Содержание (краткое описание) процесса.
  10. Состав процесса (перечень процессов нижележащего уровня).

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

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

3. Организационная структура

Главное назначение организационной структуры – обслуживание бизнес-процессов.

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

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

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

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

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

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

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

1. Название процесса

2. Краткое описание процесса

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

3. Клиент процесса

Клиенты процесса – это лица или организации, получающие выгоду от выполнения процесса, пользующиеся его результатами.

4. Цели процесса

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

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

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

5. Результат процесса

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

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

6. Показатели процесса

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

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

Такая последовательность шагов позволяет прийти к правильным показателям процесса.

7. Ресурсы процесса

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

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

8. Поставщики процесса

9. Исполнители процесса

10. Владелец процесса

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

5. Описание должностных обязанностей сотрудников

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

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

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

6. Определение состава компетенций специалистов

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

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

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

Нам будут нужны первая и вторая колонка этой таблицы. Вместо остальных колонок добавим три новые: «Знания», «Навыки», «Личные качества». Таким образом, у нас есть список процессов, в которых участвует сотрудник, краткое описание этих процессов и три колонки, которые нужно заполнить, последовательно рассматривая каждый процесс.

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

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

7. Определение профиля должности

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

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

Документ «Профиль должности» имеет следующую структуру:

  • Общие знания,
  • Предметные знания,
  • Навыки,
  • Личные качества,
  • Ценности,
  • Функциональные обязанности,
  • Области ответственности.

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

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

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

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

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

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

Неохваченными в рамках статьи остались следующие задачи:

  • Определение показателей деятельности (KPI).
  • Установление правил вознаграждения за результат.

Этим вопросам посвящен вебинар «Как разработать систему KPI. Применение показателей деятельности для мотивации сотрудников».

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

Партнерский материал.

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

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.

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

Определение по версии EABPM (Европейская ассоциация BPM) этого термина звучит следующим образом:

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

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

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

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

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

Как появилось BPM

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

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

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

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

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

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

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

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

Определение от меня:

Управление бизнес-процессами (BPM) – это управление действиями (автоматизированными и неавтоматизирвоанными) в коллективе посредством бизнес-процессов.
Чтобы управлять любыми бизнес процессами необходимо:
  1. Описать сами бизнес-процессы.
  2. Внедрить в работу коллектива описанный бизнес процесс
  3. Назначить людей, ответственных за бизнес-процессы, так называемых, стек-холдеров или владельцев бизнес-процессов.
Важно понимать, что бизнес-процесс может выполняться как человеком, так и быть частично автоматизированным. Аналогично и стек-холдером может быть и человек, и программа (автоматическое выполнение операций и автоматизированный контроль).

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

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

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

  • BPM – это методология. т.е. набор основных принципов и подходов к построению нотаций и самой организации работы при помощи бизнес-процессов.
  • BPMN – нотация(язык), в которой строятся нотации, в том числе, исполняемые
  • BPMS – IT система исполнения, построенная по определенным правилам, заданных в методологии
Если проводить аналогию с наукой, то BPM - это прежде всего подход, своего рода мировозрение. BPMN - это методы и алгоритмы решения конкретных задач. Например, доказательства для теорем или набор методов для создания проекта обеспечения электричеством объекта (производства, многоквартирного дома). А, в свою очередь, BPMS- это уже готовые прикладные решения, которые можно “включить” и они уже будут работать. Для математики это - готовые решения задач, имеющих практическое значение. Для физики - непосредственное реализации той самой электропроводки и подключение объектов. Для сферы айти - готовый программный код.

Исполняемые и неисполняемые бизнес процессы

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

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

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

Отличия процессного и функционального подходов

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

При этом также необходимо знать:

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

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

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

Необходимо понимать:

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

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

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

При процессном подходе мы получаем ответ на вопрос «как это лучше выполнить», т.е. концентрируемся на тактическом, оперативном управлении. А потому здесь при изменении отдельных элементов между «входом и «выходом» меняется весь процесс.

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

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

Описание работы с BPM

Для лучшего понимания того, что такое BPM (управление бизнес-процессами), я приведу пример последовательности действий бизнес-аналитика в рамках этой методологии:

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

Документирование бизнес-процесса на основе полученных данных. На этом этапе аналитик получает описание бизнес-процесса «как есть».

Изучение полученного бизнес-процесса с точки зрения слабых мест и возможности оптимизации:

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

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

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

Жизненный цикл процесса в BPM

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

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

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

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

К числу преимуществ использования BPM относятся:
  • Возможность максимально детализировать действия людей и систем, необходимые для получения результата.
  • Графические нотации – наглядны, что позволяет понять особенности процессов в компании и увидеть их слабые места.
  • Нотации прекрасно подходят в качестве инструкции исполнителю, который получит четкую и однозначную последовательность действий. При этом она будет оформлена графически – наиболее удобным для восприятия человеком образом.
  • При использовании процессного подхода результат выполнения процесса будет стандартизирован и соответствовать ожидаемому. Это позволит снизить влияние человеческого фактора на уровень сервиса или выполнения любых других видов работы.
  • Методология BPM – прекрасно проработана и стандартизирована благодаря BPMN. При этом инструменты (нотации BPMN) интуитивно понятны даже для людей, не изучавших управление бизнес-процессами вообще. С другой стороны, наличие стандартов и правил позволяет избегать ошибок при разработке и создавать в системе BPMS исполняемые нотации (готовые элементы автоматизации бизнеса).

Минусы BPM, как это часто бывает, находятся там же, где и преимущества:

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

Каким компаниям подходит BPM

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

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

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

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

Вопросы и ответы

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

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

Какие понятия входят в BPMN?

В первую очередь, это непосредственно система BPMN, а также описание нотаций BPMS. О них я писал в этой статье, и подробно - в предыдущих статьях (см. рекомендуемые ссылки в конце публикации). Кроме того, не так давно появились новые понятия - DMN и CMMN. На них я сейчас подробно останавливаться не буду. Постараюсь описать новые понятия и их особенности в будущих публикациях.

Зачем нужно в построении нотаций столько сложностей и разные подходы?

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

С чего начать работу с BPM?

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

Можно ли использовать BPM для неавтоматизированных систем?

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

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

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

В сегодняшней статье мы ответим на 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-м вебинаре серии «Бизнес-процессы для больших».

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

Новые статьи

Популярные статьи

© 2024 minbanktelebank.ru
Бизнес. Заработок. Кредит. Криптовалюта