Процессное управление компанией

Бубнов Сергей АндреевичК.э.н., управляющий партнер, консалтинговая компания Bestlog
Статья из цикла «Процессное управление, или как научиться управлять компанией горизонтально»

Часть 2

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

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

Теория процессного подхода

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

Цель настоящей статьи — представить авторский подход к проектированию простой процессной системы управления в компании. Поэтому для начала обратимся к вопросу: какие существуют модели управления предприятием?

Выделяют следующие виды моделей управления компанией

1. Инновационная — характеризуется минимальным количеством, каких-либо формальных правил, инструкций, и присуща творческим небольшим компаниям.

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

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

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

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

Что такое бизнес-процесс и процессная модель компании?

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

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

Какие средства проектирования и изменения системы управления бывают?

Средства проектирования системы управления бывают двух видов:

• Ручные — использование простых офисных программ, типа (MS Office, MS Visio)
• Автоматизированные — использование прикладных программных комплексов, типа (IDEF, All Fusion, ARIS).

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

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

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

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

Практика процессного подхода

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

Самой первой проблемой обычно решаемой в компании является решение вопроса: Как лучше разрабатывать систему управления: самим или с помощью консультантов?

Ответ на этот вопрос каждая компания решает по-своему, давайте рассмотрим последовательно оба подхода:

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

Отсюда возникает множество других вопросов, например:

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

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

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

   a. из расчета суммы, единовременно выплаченной консультантам (порядка €50–100 тыс.);

   b. из расчета суммы, ежедневного обслуживание и сопровождение процессной системы управления — фонд оплаты труда отдела развития (порядка €7–10 тыс. ежемесячно);

2. Необходимо осуществить переговоры с консалтинговыми компаниями, и выбрать методику проведения разработки системы управления;
3. Создать отдел развития, и определить менеджера проекта со стороны клиента;
4. Сформировать рабочую группу со стороны клиента и консультантов;
5. Провести внутреннее обучение участников рабочей группы клиента;
6. Определить порядок взаимодействия: разработки, анализа, утверждения документов;
7. Приступить к проектированию системы управления.

Как вы думаете, стоит ли выбрать вариант, когда консультанты полностью выполняют проект самостоятельно?

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

На самом деле, невозможно получить эффективное «шаблонное» решение (ведь, как правило, оно представляет собой «отраслевое» решение, сформированное на основе 2–3 выполненных проектов). Тиражирование подобных решений возможно, но оно лишает клиента конкурентных преимуществ и делает неотличимым от других компаний отрасли…

Стоит ли бояться консультантов, у которых нет отраслевого решения?

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

Вывод:

В среднем, стоимость самостоятельного проектирования системы управления будет дешевле, чем у консультантов в 3–5 раз, но срок разработки будет минимум в три раза дольше, а качество разработки (в силу отсутствия опыта, навыков, противодействия со стороны внутренней среды компании) будет хуже на 25–40%.

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

Что нужно, чтобы разработать простую систему процессного управления?

Из ресурсов потребуется персонал в составе руководителя проекта и двух аналитиков, а также IT-инструменты: MS Office, MS Visio.

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

Описание технологии разработки простой процессной системы управления (ППСУ)

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

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

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

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

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

Порядок подготовки к проектированию ППСУ

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

Разработка технологии управления

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

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

Рассмотрим вариант технологии проектирования модели управления на основе принципа «цикл Деминга» (цикл PDCA — plan, do, check, act — планирование, выполнение, контроль и анализ). Данная технология проектирования является наиболее простой и понятной. Пример структуры технологии управления представлен ниже (табл.1):

Таблица 1. Каркас технологии проектирования бизнес модели предприятия

Стратеги-
ческий уровень

Планиро-
вание

Выполнение

Конт-
роль

Ана-
лиз

Средне-
срочный уровень

Планиро-
вание

Выполнение

Кон-
троль

Ана-
лиз

Оператив-
ный уровень

Планиро-
вание

Выполн-
ение

Конт-
роль

Ана-
лиз

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

Представленная модель описывает постепенное осветление «черного ящика» процессов организации:

Стратегически уровень — процессы планирования, контроля, анализа, процесс выполнение на стратегическом уровне подразумевает его среднесрочное выполнение:

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

Описанный принцип технологии проектирования системы управления мы называем «принципом вложенной матрешки».

После определения каркаса системы управления следует перейти к проектированию системы управления.

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

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

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

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

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

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

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

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

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

Пример формы описания регламента приведен в табл. 2.

Таблица 2. Пример формы регламента

РИТ-..
Регламент процесса
«Внедрение информационной системы»

Стр.
1 из 2

Ред. 1.1 Изм. Дата: XX.XX.XXг. 1. Общие сведения

Группа процессов

Процессы развития (информационное развитие)

Цель процесса

Добиться надежности и работоспособности программного обеспечения

KOI — ключевые операционные показатели

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

Ответственный за регламент

Руководитель отдела информационных технологий

Начало процесса

Составлен план-график модернизации ИТ-системы предприятия

Окончание процесса

Программный продукт внедрен и передан на поддержку

2. Текстовое описание бизнес-процесса

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

3. Перечень участников процесса

Подразделения, участвующие в процессе

Должности в рамках подразделения

1.

Отдел информационных технологий

1.1

Руководитель отдела ИТ

1.2

Системный администратор

1.3

Инженер-программист

1.4

Специалист по поддержке

2

Подрядчик по внедрению ИТ-системы

2.1

Руководитель проекта

2.2

Консультант

3.

Все подразделения предприятия

3.1

Сотрудник подразделения

4. Перечень операций в рамках процесса

№

Наименование

Комментарий

Подразделение

Исполнитель

OI — операционные показатели

1.

Обучиться работе с новым программным продуктом (оборудованием).

Отдел информационных технологий

Руководитель отдела ИТ

Время обучения работе с программным продуктом, час

Отдел информационных технологий

Инженер-программист

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

Отдел информационных технологий

Специалист по поддержке

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

2.

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

Подрядчик по внедрению ИТ-системы

Руководитель проекта

Вероятность сбоев в главной ИТ-системе, %

Подрядчик по внедрению ИТ-системы

Консультант

Время установки и запуска системы, час

3.

Тестировать работу программного обеспечения (оборудования) и выявлять ошибки.

Отдел информационных технологий

Руководитель отдела ИТ

Время тестирования программного обеспечения, час

Отдел информационных технологий

Инженер-программист

Серьезность выявленных ошибок, балл

Отдел информационных технологий

Специалист по поддержке

Серьезность выявленных ошибок, балл

Отдел информационных технологий

Системный администратор

Серьезность выявленных ошибок, балл

Все подразделения предприятия

Сотрудник подразделения

Серьезность выявленных ошибок, балл

4.

Регулировать работу программного обеспечения

Исправлять ошибки

Отдел информационных технологий

Руководитель отдела ИТ

Время корректировки работы программного обеспечения, час

Подрядчик по внедрению ИТ-системы

Консультант подрядчика

Эффективность корректировки программного обеспечения, % повторных ошибок

5.

Готовить для инструкции администратора и пользователей программного продукта (оборудования).

Отдел информационных технологий

Инженер-программист

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

Отдел информационных технологий

Специалист по поддержке

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

6.

Проводить первоначальное обучение пользователей.

Подрядчик по внедрению ИТ-системы

Консультант

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

Отдел информационных технологий

Руководитель отдела ИТ

Эффективность обучения, % понимания работы

7.

Вводить программный продукт в эксплуатацию.

Отдел информационных технологий

Руководитель отдела ИТ

Время эксплуатации программного продукта, дней

Отдел информационных технологий

Инженер-программист

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

8.

Передать программный продукт на поддержку

Отдел информационных технологий

Руководитель отдела ИТ

Уровень надежности программного обеспечения, %

5. Перечень формируемых в процессе документов

№

Наименование

Тип

Описание

1.

Программа обучения новому продукту

Бумажный документ

-

2.

Инструкция администратора

Бумажный документ

-

3.

Инструкция пользователей

Бумажный документ

-

4.

Акт передачи программного продукта в эксплуатацию

Бумажный документ

Разработал

Проверил

Согласовал

Утвердил

Руководитель отдела развития

Директор по качеству

Руководитель отдела ИТ

Генеральный директор

«__»_________ 2008г.

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

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

Где взять примеры показателей? Показатели обычно систематизированы по различным бизнес-моделям, например, наиболее распространенной версией модели логистических процессов является SCOR-модель, насчитывающая более 700 показателей2.

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

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

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

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

Таблица 3. Взаимосвязь показателей и системы мотивации

Наименование группы должностных лиц

Основной показатель премирования

Дополнительный показатель премирования

Бонус (квартал)

Премия (год)

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

PKPI

Бюджеты доходов и расходов

Рост нормы прибыли

Чистая прибыль

Ответственный за регламент

PI

PKPI

Бюджеты доходов и расходов

Рост нормы прибыли

Исполнитель

KOI

PI

PKPI

Рост нормы прибыли

где

PKPI — process key performance indicators — ключевые процессные показатели.

PI — process indicators — процессные показатели.

KOI — key operational indicators — ключевые показатели оперативной деятельности.

После разработки системы показателей, требуется провести изменения в системе мотивации персонала.

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

Типичная структура положения по мотивации включает:

1. общие сведения;
2. схему материального стимулирования;
3. виды материального и нематериального поощрения;
4. порядок предоставления, обсуждения и подведения итогов работы предприятия;

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

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

Схема материального стимулирования

Наименование должности сотрудника: категорийный менеджер
должность

Таблица 5.

Основной показатель премирования

Дополнительный показатель премирования

Бонус

Премия

Наименование

Вес

Наименование

Вес

Наименование

Вес

Наименование

Вес

Уровень выполнения плана закупок:

Уровень улучшения розничных продаж, руб

20%

Средний уровень выполнения плана закупок в натуральном и стоимостном выражении, %

15%

Увеличение прибыли предприятия

50%

в натуральном выражении, %

15%

Уровень улучшения продаж дополнительных услуг, руб.

10%

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

30%

Сокращение затрат предприятия

50%

в стоимостном выражении, %

15%

Эффект от реализации новых схем работы с поставщиками, руб

15%

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

25%

Рентабельность розничных продаж:

Уровень улучшения закупок, руб.

20%

Вероятность продаж спекулятивных закупок, %

10%

новинок, %

9%

Эффективность мероприятий по улучшению системы продвижения товаров, балл

12%

Эффективность участия поставщиков в рекламной компании, % по затратам

10%

основной группы товаров, %

12%

Выполнение бюджета структурного подразделения, %

23%

Точность планирования поступления ДС из розничного канала продаж, %

10%

вспомогательной группы товаров, %

6%

распродаваемых товаров, %

6%

Уровень выполнения плана продаж:

в натуральном выражении, %

11%

в стоимостном выражении, %

15%

Фактические остатки товара на конец периода, % от нормативного

11%

ИТОГО 100,00% 100,00% 100,00% 100,00%

Согласовано: ___________________
Директор по качеству

Ознакомлен: ___________________
Категорийный менеджер

Согласовано: ___________________
Коммерческий директор

Согласовано: ___________________
Главный бухгалтер

Согласовано: ___________________
Исполнительный директор

Согласовано: ___________________
Финансовый директор

Заключение

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

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

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

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

2 Одну из версий можно бесплатно загрузить по адресу http://www.bestlog.su/public/scor_public_db.zip