Регламентация бизнес процессов реферат

Обновлено: 08.07.2024

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

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

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

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

• Функции – обособленные повторяющиеся виды деятельности компании, выполняемые на постоянной основе.

Рис. 7.0.1. Схематичное представление бизнес-процесса деятельности компании 7.1. Корпоративная архитектура – структурированноеописание организации деятельности компании

Рис. 7.1.1. Пирамида регламентов компании в области представления бизнес-процессов

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

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

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

Модель бизнес-процесса – прикладное представление (в заданной нотации) исполняемых компанией работ.

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

• модель бизнес-процессов верхнего уровня – агрегированная, наиболее общая модель БП компании;

• модель бизнес-процесса алгоритмическая – модель БП компании, отражающая состав и логику исполнения компанией работ при его реализации;

• модель бизнес-процесса потоковая – модель БП компании, отражающая материальные, финансовые и информационные потоки объектов;

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

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

7.2. Нормативно-методические документы для регламентациибизнес-процессов в стандартах ISO 9000:2000

Рис. 7.2.1. Пирамида регламентирующей документации организации (компании) в международных стандартах ISO 9000:2000 Надо признать, что на современную практику и типологию регламентирующих документов БП в существенной мере влияют подходы стандартов ISO (рис. 7.2.1). Назидательные с этой точки зрения выдержки из стандартов приведены в табл. 7.2.1.

7.3. Политики в области регламентации бизнес-процессов

Рис. 7.3.1. Основные характеристики политик компании в области регламентации бизнес-процессов (пример) Таблица 7.3.1

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

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

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

Стандарты ISO 9000:2000 предполагают разработку и применение отдельного документа в области политики и целей качества (табл. 7.3.2).

Рис. 7.3.2. Основные характеристики политик по направлению деятельности (пример) Таблица 7.3.2

7.4. Порядок регламентации бизнес-процесса

Рис. 7.4.1. Характеристики порядков по направлению деятельности Порядок регламентации бизнес-процесса – нормативно-методический документ (раздел нормативно-методического документа), отражающий процедуру взаимодействия участников в рамках одного из бизнес-процессов; может содержать детализацию описания бизнес-процесса с указанием процедуры его исполнения, исполнителей (подразделения, уполномоченные лица), их прав и ответственности; в качестве входящей и исходящей информации – документов (табл. 7.4.1 и рис. 7.4.1). Глубина описания порядка регламентации может увеличиваться за счет включения дополнительных характеристик бизнес-процессов.

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

Рис. 7.4.2. Пример табличного представления бизнес-процесса

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

Для составления алгоритмических схем используют специальные графические элементы (см. рис. 7.4.4), совокупность которых определяет нотацию моделирования. Наиболее популярны для описания бизнес-процессов – алгоритмическая блок-схема, Basic Flowchart, Cross-Functional Flowchart, Event-driven Process Chain, IDEF0, IDEF3, Data Flow Diagrams, Work Flow Diagram. Выбор нотации моделирования зависит от его целей и от программного продукта, применяемого для этого. Обычно используют 3–4 и более нотаций (для различных уровней декомпозиции процессов) (рис. 7.4.3).

Рис. 7.4.3. Пирамида описаний бизнес-процессов (пример)

Рис. 7.4.4. Пример обозначений, используемых при представлении БП в форме алгоритма

Рис. 7.4.5. Пример представления бизнес-процесса в форме алгоритма

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

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

Если используешь модель, то, значит, используешь и методологию построения и применения модели.

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

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

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

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

• уточнять требования к регламентирующим документам;

• корректировать документы в соответствии с изменившимися требованиями;

• создавать информационные системы (для доведения регламентов до исполнителей) с заданными параметрами.

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

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

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

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

3. Поддержание управленческой документации в актуальном состоянии.

4. Обеспечение возможности коллективной работы с электронной моделью компании.

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

Рис. 7.5.2. Ключевые возможности электронных моделей бизнес-процессов

7.6. Корневая модель бизнес-процессов

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

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

Деятельность компании удобно сгруппировать по основным областям. Пример подобной группировки приведен в табл. 7.6.1.

А. Область управления компанией в целом (объектом управления являются бизнес-процессы сфер Б, В и Г).

Б. Область развития (объекты развития находятся в областях А, Б и Г).

Г. Область поддерживающей деятельности (входящие в эту область БП верхнего уровня заканчиваются в областях А, Б и В).

Применяется представление модели в виде классификатора (рис. 7.6.1) и в виде диаграммы (рис. 7.6.2). Классификатор БП показывает их состав и типологию, диаграмма БП визуально отображает их состав, логику исполнения и типологию.

Могут применяться те или иные договоренности о кодифицировании БП. Например, первый разряд – буквенный код типа процесса (область управления компанией в целом – А, область развития – Б, область основной деятельности – В, область поддерживающей деятельности – Г), второй разряд – цифровой код функциональной области (например, В3 – топливо), последние четыре разряда – цифровой код процесса:

где M – буквенный код типа процесса;

N – цифровой код функциональной области согласно списку (см. рис. 7.6.2);

XXXX – цифровой код процесса в порядке иерархии функций.

Рис. 7.6.1. Перечень бизнес-процессов верхнего уровня энергетической компании (пример)

Рис. 7.6.2. Диаграмма корневой модели бизнес-процессов ОГК-3 (пример)

7.7. Способы детализации описания бизнес-процессов верхнего уровня

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

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

13. Описание и моделирование бизнес-процессов проектно-ориентированной компании

13. Описание и моделирование бизнес-процессов проектно-ориентированной компании Бизнес-процесс – преобразование входа в полезный выход.Декомпозиция бизнес-процесса – детализация описания, осуществляемая с прикладной целью (рис. 13.0.1).Модель бизнес-процесса –

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

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

10. Практикум. Создание комплексной системы моделирования и регламентации деятельности компании в целях развития ее корпоративной архитектуры и СМК

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

Глава 11 Основы выбора ценовой политики ритейловой компании

Глава 11 Основы выбора ценовой политики ритейловой компании 11.1. Место ценообразования в системе управления торговыми операциями:что определяет границы ценового маневра в рознице;почему с ценой надо быть столь осторожным.11.2. Цели фирмы и их влияние на управление

8.2. Построение и развитие политики в области управления персоналом

1.1. Зрелость компании в области процессного управления

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

2.6. Сквозные процессы в системе процессов компании

2.6. Сквозные процессы в системе процессов компании Как показывать сквозные процессы в системе процессов компании?[64] Для ответа на этот вопрос рассмотрим несколько примеров. Пример. Сквозные процессы в области продаж Компания оказывает логистические услуги. В рамках

3.3.4. Система процессов компании по методу CBM IBM

3.3.4. Система процессов компании по методу CBM IBM Подход CBM (Component Business Model) компании IBM довольно интересен (табл. 3.3.2). Этот метод пока мало распространен в России, но некоторые крупные компании уже используют его для построения процессной модели бизнеса.Таблица 3.3.2.

5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития

5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития В ряде компаний регламентация процессов производства достигает 90–100 %, то есть регламентирована почти вся деятельность. Внешние требования (ограничения)

5.2. Минусы регламентации бизнес-процессов

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

5.3. Плюсы регламентации бизнес-процессов

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

6.1.1. Процессы управления в системе процессов компании

6.1.1. Процессы управления в системе процессов компании С практической точки зрения важен вопрос определения и описания процессов управления. В качестве примера рассмотрим модель APQC, версия 5[118]. Содержит ли она процессы управления? В определенном смысле – да. Перечислю

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

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

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

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

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

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

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

Поэтому регламентация бизнес-процессов совершенно необходима для любого бизнеса.

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

Систему контроля с использованием показателей.
Систему внесения изменений и модернизации.

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

Типичные ошибки при регламентации бизнес-процессов

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

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

После того, как регламентация бизнес-процессов выполнена, можно приступать к их формализации с помощью систем класса BPM или Low-code. Системы Low-code, например, платформа Comindware Business Application Platform, имеют столь же большое количество возможностей, как и BPMS, и смещают центр тяжести усилий по разработке бизнес-приложений и дальнейшей их адаптации к новым требованиям бизнеса с программистов на аналитиков. Цифровая трансформация с их помощью позволяет перейти на новые принципы работы более плавно и принести хорошие результаты – но только если регламентация была проведена грамотно и с учётом всех нюансов.

Закажите демонстрацию Comindware Business Application Platform и объективно оцените её преимущества для решения ваших задач.

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

10 чел. помогло.

^ Регламентация бизнес-процессов.

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

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

• делегирование полномочий руководителей сотрудникам, выполняющим процесс;

• перераспределение функций между процессами;

• кардинальное перепроектирование процессов. Кардинальное перепроектирование процессов - очень сложный и многообразный инструмент реструктуризации. Перепроектирование любого процесса - это уникальный проект, в котором трудно давать конкретные советы, и, тем не менее, существуют общие закономерности, которые очень хорошо изложены в известной книге М. Хаммера и Дж. Чампи [2]. Краткое изложение этих закономерностей приведено в разделе 3 данного учебного блока.

2. Примеры проведения реструктуризации

Мы будем рассматривать указанные выше изменения на условных примерах, которые, основаны на практическом опыте реорганизации бизнес-процессов [3].

^ Делегирование полномочий руководителей сотрудникам, выполняющим процесс

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

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

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

Рис. 3.3.3 Шаг 1. Исключаем функции владельца процесса из процесса.

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

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

Рис. 3.3.4 Шаг 2. Делегирование полномочий вниз.

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

2.2 Перераспределение работ и функций между процессами

Рис. 3.3.5 Исходная ситуация для перераспределения функций между процессами.

Рис. 3.3.5 Анализ процесса.

Рис. 3.3.6 Регламентация взаимодействия.

Рис. 3.3.7 Передача функций в процесс.

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

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

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

2. Не сосредоточивайте внимание на бизнес-процессах.

3. Игнорируйте все, кроме перепроектирования процессов.

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

4. Пренебрегайте ценностями и убеждениями людей.

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

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

5. Старайтесь довольствоваться незначительными результатами.

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

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

6. Прекращайте изменения как можно раньше.

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

7. Заранее сужайте проблемы и ограничивайте масштаб реинжениринговых мероприятий.

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

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

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

8. Позвольте существующей корпоративной культуре и стилю руководства предотвратить реинжениринг.

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

9. Попытайтесь осуществить реинжениринг "снизу вверх".

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

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

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

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

11. Урежьте ресурсы, выделенные на реинжиниринг.

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

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

12. Похороните реинжиниринг среди приоритетов корпорации.

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

13. Рассредоточьте энергию по многочисленным реинжиниринговым проектам.

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

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

15. Сконцентрируйте внимание исключительно на перепроектировании.

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

16. Постарайтесь осуществить реинжиниринг безболезненно для всех.

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

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

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

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

18. Растягивайте реинжиниринговые мероприятия.

Безусловно, помимо тех направлений действий, которые мы только что перечислили, существуют и другие, ведущие к неудачам в реинжиниринге. Люди удивительно неистощимы в поисках новых способов провала реинжиниринга. Однако одно обстоятельство предопределяет все отмеченные нами трудности. Это — роль высшего руководства в осуществлении реинжиниринга. Если реинжиниринг терпит неудачу, безразлично, что является непосредственным поводом для этого, поскольку к определяющей причине может быть неизменно отнесено неадекватное понимание высшими менеджерами сущности реинжиниринга или неумелое руководство им. Реинжиниринг всегда рождается в костюме управляющего и слишком часто в нем же умирает.

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

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

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

Мы редко встречаем специалистов, которые разбираются в терминологии управления бизнес процессами. В этом нет ничего удивительного — понятие управления бизнес процессами не так давно стало широко распространяться в России. Но у путаницы в терминологии есть существенное последствие — разность понимания. А разность понимания приводит к разным результатам. Разность приводит к диалогам наподобие:

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

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

Описание бизнес процессов

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

Вроде бы все понятно, но все же стоит отметить:

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

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

Стандартизация бизнес процессов

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

Именно поэтому, говоря о стандартизации, многие авторы говорят о том, что стандартизация, это, в том числе, процесс приведения в соответствие стандарта (описания) и реального выполнения процессов в жизни.

Процесс разработки стандарта достаточно обширен. Он имеет явно выраженные входы и продукты, а также события начала и окончания. Продукт процесса имеет ценность сам по себе. Имеется ввиду, что стандарт, это законченный продукт. Который может использоваться далее, а может и нет. Проще говоря — процесс стандартизации имеет четкие границы, которые говорят о нем, как о законченном и самостоятельном процессе.
Управление разрывами, это процесс, который на входе использует продукты двух процессов: Описание бизнес процессов и Стандартизация бизнес процессов. Собственно, Управление разрывами направлено на… Устранение разрывов между тем, как есть и тем, как мы хотим, чтобы было. Т.е. Это тоже самостоятельный процесс, с четкими границами.

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

Понятное дело, что очень часто нормирование используется в качестве кнута — не вложился в норму, вот тебе орех. Точнее по ореху. Это крайне неправильно. Норма, в бизнес процессах, нужна для того, чтобы можно было выявлять отклонения, анализировать их и улучшать процесс. Если норма указана не верно, это не означает, что ее нельзя изменить. Более того, она должна меняться. В определенной степени и условиях. Поэтому — нормирование, это процесс выявления нормальных значений. Которые, тем не менее, всегда будут иметь отклонения. Нормальным, мы считаем значение, которое будет принимать параметр процесса чаще всего. И да, нормирование должно основываться и на расчетах (теории), и на практически полученных измерениях. Нормирование только на основании расчетов не учитывает реальность. Нормирование только на основании реальности, не включает в себя возможность развития.

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

Но давайте разберемся, а что, собственно, подлежит стандартизации, с точки зрения процесса? Итак, что должен включать в себя хороший стандарт:

Состав подпроцессов и операций процесса. Т.е. Стандартом является ответ на вопрос — что должно быть обязательно сделано? И это уже не мало.
Порядок выполнения подпроцессов и операций процесса. Чтобы процесс получал на выходе определенный продукт, должна быть определенная последовательность действий. Именно об этом говорят, имея ввиду описание технологии — описание состава и последовательности действий, которая описывается в стандарте. Ответ на вопрос — в каком порядке нужно выполнять действия?
Распределение подпроцессов и операций по исполнителям. Все просто — в стандарте указывается кто должен выполнять действия в процессе.
Состав ресурсов. Ресурсы — все, что необходимо, для выполнения процесса. Люди, инструменты, материалы, сырье, программное обеспечение и так далее. В стандарте должен быть описан не только состав, но и качество, свойства, ресурсов.
Нормативные значения использования ресурсов. Вот это уже про нормирование. В стандарте описывается сколько и каких ресурсов, необходимо для выполнения каждой операции.
Нормативные значения операций. Это тоже вопрос нормирования. В стандарте указывается сколько времени должны выполняться операции или процесс. Зачем? Затем, что это может иметь ключевое значение для результата процесса. Например, если не соблюсти нормативные значения времени при приготовлении блюда, то результат может выйти так себе.
Стандарты документов. Стандарт может содержать в себе формы документов, которые должны использоваться в процессе. Ну тут, думаю, все понятно.

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

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

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

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

Что еще нужно знать о стандартизации процессов:

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

Регламентация бизнес процессов

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

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

Вот, пожалуй, и все.

Читайте также: