Процессная модель организации с чего начать

Технологии процессного управления

Шесть основных шагов

Технологии процессного управления

Шесть основных шагов

Процессная модель организации с чего начать

Сергей Ковалев — руководитель и ведущий консультант консалтинговой компании БИТЕК (Бизнес-инжиниринговые технологии). Имеет 20-летний опыт организационного проектирования и управления бизнес-процессами. Автор публикаций, семинаров и книг по стратегическому и процессному управлению и развитию.

Классика построения организации

Можно сказать, что построение организации состоит из трех основных фаз: разработка стратегии, разработка бизнес-процессов и проектирование на их основе организационной структуры (рис. 1).

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

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

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

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

Процессная модель организации с чего начать

Рис. 1. Классика построения организации

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

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

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

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

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

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

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

Процессная модель организации с чего начать

Рис. 2. Система процессного управления

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

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

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

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

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

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

Задачи, которое решает процессное управление

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

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

Источник

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

Часть 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. Каркас технологии проектирования бизнес модели предприятия

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

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

Ана-
лиз

Ана-
лиз

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

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

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

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

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

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

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

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

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

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

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

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

Стр.
1 из 2

Ред. 1.1Изм.
Дата: XX.XX.XXг.

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

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

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

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

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

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

1. Общие сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *