Вы перешли к этапу разработки процессной модели организации с чего вы начнете

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

Часть 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ана-
лиз

Ана-
лиз

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

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

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

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

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

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

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

Рис.1. Карта бизнес-процессов, спроектированная по «принципу Деминга»

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

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

Стр.
1 из 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Отличительные особенности и основные этапы внедрения процессного управления

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

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

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

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

Ключевой особенностью процессного управления является совершенствование основных видов деятельности, повышение качества выходов и квалификации сотрудников. Циклы непрерывного совершенствования, изложенные Эдвардсом Демингом (PDCA) или к концепции six sigma (DMAIC) должны быть реализованы в компании, которая внедряет процессное управления.

Как внедрять процессное управление у себя в компании? Для того, чтобы внедрить процессное управления необходимо ПОСЛЕДОВАТЕЛЬНО пройти четыре основных этапа: бессистемный, системный, измеряемый и совершенствуемый. Давайте рассмотрим характерискики каждого из этапов.

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

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

Обеспечивающие (вспомогательные) процессы.

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

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

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

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

Минимально возможное количество.

На совершенствуемом этапе, когда вы знаете как работает ваша система процессов компании, когда вы провели измерения и выявили уязвимые, не устраивающие вас участки процессов, пора приступать к мероприятиям по оптимизации бизнес-процессов. Для этого необходимо четко сформулировать видение развития компании (стратегия развития, система сбалансированных показателей и т.д.) и донести ее до сотрудников. Также основными инструментами по оптимизации бизнес-процессов выступают: цикл Деминга (цикл PDCA «Plan-Do-Check-Act») или методология DMAIC («Define-Measure-Analyze-Improve-Control»). Цикл PDCA представляет собой алгоритм последовательности действий, необходимых для повышения качества бизнес-процесса: планирование, реализация, контроль и реагирование (корректировка). Методология DMAIC основана на цикле Деминга и представляет собой алгоритм с более расширенной последовательностью действий, нежели PDCA: определение, измерение, анализ, совершенствование и контроль.

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

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

Стандартизация работы процесса (сокращение ошибок в работе сотрудников).

Контроль выполнения эффективности операций.

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

Внутренний аудит компании.

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

Источник