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

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

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

  • порядок
    управления процессом;

  • порядок
    выполнения процесса;

  • требования к
    ресурсам, необходимым для его выполнения.

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

При регламентации
процесса следует учитывать его основные
элементы:

• деятельность
по управлению процессом:

владелец процесса
и его полномочия;

технология
управления процессом (как минимум —
планирование и отчетность);

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

• входы
процесса, в том числе:

требования, к
входам;

события, инициирующие
начало процесса;

• выходы
процесса, в том числе:

требования к
выходам (результатам);

события, завершающие
процесс;

• деятельность
по преобразованию входов в выходы
(технология выполнения процесса):

ответственность
персонала;

выполнение
операций (структура и взаимосвязь
операций);

• ресурсы,
необходимые для выполнения процесса,
в том числе:

персонал;

инфраструктура;

оборудование;

информация;

прочие.

1. Базовые принципы регламентации процессов.

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

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

Принцип 2.
Стремиться к простоте.

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

Причины:

  1. те, кто пишет
    документы, сами их не исполняют;

  2. нехватка времени
    на подготовку хорошо проработанного
    документа;

  3. руководители не
    заинтересованы в реальных изменениях
    процессов;

  4. непонимание
    того, что действительно важно для
    регламентации деятельности.

Принцип
3.

Лучше
толще, но меньше.

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

Принцип 4 Учет
квалификации персонала и культуры
компании.

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

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

Принцип 5.
Перенесение акцента при детализации
процессов с описания управления на
детальное описание технологии выполнения
процесса.

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

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

  • детализация
    процесса может не требоваться*;

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

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

  • ответственность
    и полномочия руководителей;

  • технологию
    управления процессом (планирование,
    организацию, контроль и принятие
    решений по процессу);

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

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

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

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

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

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

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

Шаблон регламента
процесса представлен в приложении 1.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

Что такое бизнес-процесс? 

Существует много разных определений понятия «бизнес-процесс». Вот, некоторые из них:

Процесс – преобразование объекта труда, добавляющее его стоимость.  Э. Деминг

Процесс — это совокупность взаимосвязанных или взаимодействующих видов деятельности, которая преобразует входы в выходы. ИСО 9001

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

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

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

Функциональный и процессный подход

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

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

 Рис.1  Линейно-функциональная организационная структура

Рис. 1 Линейно-функциональная иерархическая структура.

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

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

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

 

 Рис. 3 Синие пунктирные линии – решение проблем через руководителя.

А что же процессный подход?

В процессном подходе взаимодействующие сотрудники – договариваются между собой. У процесса появляется свой горизонтальный «руководитель» (его ещё называют Владельцем процесса).

В результате применения процессного подхода, мы получаем:

— оптимизированные процессы

— сформулированные и согласованные всеми участниками процессов требования к качеству процессов и процедур.

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

Категории Бизнес-процессов

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

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

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

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

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

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

 При описании бизнес-процессов важно соблюсти следующие принципы:

1. Описанию подлежат те процессы, которые уже сложились(сформировались).

2. Описание процессов начинается с моделирования схем.

3. Моделировать процессы следует в соответствии с уровнями детализации.

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

  • Операция — минимальная часть дейтяльеости. Выполняется «автоматически» (переключить скорость в автомобиле, скопировать в Word и т.п.)
  • Действие — несколько последовательно выполняемых операций, требующие осознанного контроля (доехать из пункта А в пункт B, написать текст и т.п.)
  • Процедура — несколько последовательно выполняемых действий. У процедуры всегда есть результат (устное сообщение
  • Бизнес-процесс базового уровня — последовательность взаимосвязанных процедур, выполняемых несколькими исполнителями, приводящая к значимому для организации результату.
  • Направление деятельности — укрупнённая часть деятельности компании, состоящая из нескольких групп бизнес-процессов базового уровня

Процессы описываются на уровне Процедур, бизнес-процессов базового уровня и направлений деятельности.

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

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

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

Зачем моделировать и регламентировать процессы? Всем ли это нужно?

 Всем ли подходит Процессный подход? Процессный подход полезен практически для любй компании с устоявшимися процессами. Но есть категория, для которых возврат на вложенные ресурсы будет максимальный.  Это такие компании с достаточно большим количеством управленческих воздействий. По опыту консультантов, регламентация деятельности приносит наибольшую пользу там, где количество постоянных управленческих воздействий превышает 1000.  Где Управленческие воздействия (УВ) = правила х исполнители. 

 управление по отколнениям

Рис. 4  Регламентация деятельности  и управление по отклонениям.

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

Язык описания бизнес-процессов. Нотации.

Нотаций описывающих процессы много. Самые популярные нотации процессов:  eEPC, BPMN, Cross Functional Flowchart (Процедура), Flowchart, IDEF0,.

Что такое нотация ?

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

Как правило при описании процесса отражают, как минимум четыре сущности процесса:

  • вход процедуры (процесса)
  • исполнитель процедуры
  • сама процедура (текстовое обозначение- отглагольное существительное)
  • выход процедуры (результат процедуры/процесса)

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

 Каждая нотация имеет свои плюсы и минусы:

Диаграмма Cross-functional Flowchart  – не отображает исполнителей, EPC – наиболее подробная, но если процессы большие, то схема разрастётся до больших плохо читаемых размеров, BPMN – современная, наиболее развивающаяся нотация, но наиболее полезна, если в будущем вы планируете автоматизировать процессы.

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

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

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

Оптимизация процессов

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

группа 1. Методы оптимизации «здравого смысла»:
  • убрать избыточный контроль
  • избавиться от дублирования 
  • автоматизация часто повторяющихся операций
  • запараллеливание процессов
  • равномерное распределение ресурсов и т.п.

    Примеры оптимизаций из первой группы : 
    При описании взаимодействия между отделом бронирования заказов и отделом продаж туристической компании было замечено, что 80% всех причин отказов в бронировании вызвано всего пятью причинами. Стандартизовав эти 5 причин, ИТ-специалисты сделали 5 кнопок во внутренней ERP-системе, что позволило значительно сократить объём переписки между отделами, ускорило и упорядочило информирование менеджеров продаж.

группа 2. Методы бережливого производства

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

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

Метод согласования входов — выходов между на стыках процессов SIPOC.

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

Для решения проблем на таких стыках разработана методика SIPOC. SIPOC — акроним  от слов supplier, input, process, output, customer (поставщик, вход, процесс, выход, клиент).

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

 
Рис. 5 Методика согласования требований «клиент-поставщик» SIPOC.

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

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

Автоматизация бизнес-процессов

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

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

Категории процессов

Процессы принято делить на :

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

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

Мифы и заблуждения

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

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

P.S.  Если вас интересует повышение конкурентноспособности вашей организации через повышение операционной эффективности и процессный подход — мы готовы вам в этом помочь. Имеем большой опыт проектов в разных отраслях от промышленных производств до интернет-платформ. Подробнее..

Больше полезных материалов в моем Instagram

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

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

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

Принцип 3. Лучше толще, но меньше. Лучше сделать один толстый документ (с удобной навигацией), чем 20 тонких.

Принцип 4. Учет квалификации персонала и корпоративной культуры компании. Если в компании высококвалифицированные, ответственные сотрудники, то документы не потребуется слишком детализировать.

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

Назад

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

Содержание:

1. Определение бизнес-процесса

2. Базовая регламентация в проектной компании и основной бизнес-процесс

3. Второстепенные бизнес-процессы проектной компании

4. Участие программы Инициатор в основном бизнес-процессе проектной компании

4.1 Инициация

4.2. Выполнение

4.3.Изменение условий

4.4. Закрытие

1. Определение бизнес-процесса

Один из главных принципов научной организации труда — совершенствование основного бизнес-процесса.

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

Программа Инициатор помогает построить работу компании в соответствии с этапами бизнес-процесса проектной организации и создает возможности для постоянного совершенствования бизнес-процесса.

2. Базовая регламентация в проектной компании и основной бизнес-процесс проектной компании

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

Основной бизнес-процесс компании “СибТехПроект” состоит из следующих этапов:

  1. Формирование коммерческого предложения
  2. Ведение коммерческого предложения
  3. Назначение руководителя проекта
  4. Формирование Договора. Договор заказчика
  5. Формирование Договора. Договор проектировщика
  6. Формирование проектной группы
  7. Детализация объемов работ проекта
  8. Несущественные изменения в проекте (<10%)
  9. Существенные изменения в проекте (< 50%)
  10. Существенные изменения в проекте (> 50%)
  11. Закрытие проекта

Рис.1. Схема основного бизнес-процесса проектной компании

Рис.1. Схема основного бизнес-процесса проектной компании

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

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

3. Второстепенные бизнес-процессы проектной компании

Кроме основного, в компании может быть несколько второстепенных бизнес-процессов. 

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

Рис.3. Второстепенные бизнес-процессы относятся к разным, как правило, сервисным, направлениям работы компании

Рис.3. Второстепенные бизнес-процессы относятся к разным, как правило, сервисным, направлениям работы компании

4. Участие программы Инициатор в основном бизнес-процессе проектной компании

Программа Инициатор используется не на всех этапах основного бизнес-процесса компании. В рассматриваемом примере основного бизнес-процесса компании программа Инициатор начинает активно использоваться на этапе 1.3 — Формирование проектной группы. Программа Инициатор — это инструмент для управления производством, работами по проекту.

Рис.4 На этапе выполнения проекта программа Инициатор наиболее востребована.

Рис.4 На этапе выполнения проекта программа Инициатор наиболее востребована.

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

4.1. Инициация 

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

Основное содержание этапа:

  1. Получение от Заказчика первичной ИРД, формирование и согласование коммерческого предложения с учетом ориентировочных ТЭПов и ТЗ.
  2. Подтверждение договоренностей по цене и срокам, планирование объема трудозатрат по проекту (в Инициаторе нет функции CRM);
  3. Назначение руководителя проекта и формирование проектной группы;
  4. Детализация объемов работ и начало выполнения работ по Проекту.

4.2. Выполнение

На этом этапе Инициатор выступает основным инструментом контроля и оперативного планирования работ по проекту.

  1. Выполняются все операции, предусмотренные технологией проектирования и регламентированные технологическими картами. 

4.3. Изменение условий

Во время выполнения работа в проект могут быть внесены изменения как со стороны Заказчика, так и со стороны Проектировщика. Программа Инициатор помогает управлять этими изменениями.

Циклы изменений делятся на три типа:

Несущественные — затрагивают менее 10% трудозатрат, при этом договорные условия между Заказчиком и Исполнителем, а также Техническое задание остаются без изменений. Работы по проекту продолжаются в обычном режиме;

Существенные (< 50%) — затрагивают от 10% до 50% трудозатрат, при этом происходит изменение договорных условий и корректировка Технического задания. Работы по проекту останавливаются, изменения в проект в программе Инициатор вносятся с помощью создания дублирующей сущности (см. Алгоритм этапа ЦИ 1.2 Основного бизнес-процесса компании).

Существенные (> 50%) — затрагивают от 50% трудозатрат, при этом происходит изменение договорных условий и корректировка Технического задания. Работы по проекту останавливаются, изменения в проект в программе Инициатор вносятся с помощью создания клона проекта (см. Алгоритм этапа ЦИ 1.3 Основного бизнес-процесса компании).

4.4. Закрытие

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

На этом этапе все работы над проектом завершаются. Все задачи должны быть выполнены, все статусы задач (Запланировано — Выполнено-Проверено-Оплачено-Заактировано) должны быть закрыты. Все задачи готового к закрытию проекта находятся в статусе Заактировано. Отдел SRV закрывает договор. Идет архивирование проекта.

Владимир Репин

Член ABPMP Russia

Доцент

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрен один из возможных подходов к структурированию процессов управления, выполняемых руководителями организации. Представлен пример системы процессов управления Транспортным отделом торговой компании, схемы процессов управления в Business Studio. К статье прилагается xml-файл с шаблоном отчета, позволяющим выгружать из Business Studio регламент процесса управления на 3-х уровнях (контур управления — процесс управления — операции процесса управления).

Введение

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

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

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

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

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

  1. Годовой;
  2. Квартальный;
  3. Месячный;
  4. Недельный;
  5. Ежедневный.

Для руководителей верхнего уровня, отвечающих за принятие решений стратегического характера, дополнительно можно определить 3-летний или 5-летний контур управления.

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

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

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

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

  1. Контур управления:
    1. Процесс управления:
      1. Операция;
      2. Операция;
    2. Процесс управления:
      1. Операция;
      2. Операция;
    3. Процесс управления

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

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

  • Неукомплектованный штат организации (руководитель вынужден выполнять часть работы за отсутствующих сотрудников);
  • Неумение руководителя делегировать полномочия и организовывать работу подчиненных;
  • Желание руководителя путем личного «встраивания» в операционные процессы всё держать под контролем, быть «незаменимым» и т. п.

Пример. Руководитель некоторой компании проанализировал существующие подходы к структурированию управленческой деятельности и предложил использовать следующий перечень типовых действий по управлению:

  1. Сбор и анализ информации для выработки решения:
    1. Определение состава собираемой информации;
    2. Определение форм отчетности.
  2. Выработка решения:
    1. Анализ альтернатив;
    2. Подготовка вариантов решения;
    3. Принятие решения;
    4. Выработка критериев оценки достижения результата.
  3. Реализация решения:
    1. Планирование;
    2. Организация исполнения плана;
    3. Мотивация персонала;
    4. Координация.
  4. Учет результатов реализации решения:
    1. Учет результатов;
    2. Сравнение по принятым критериям.
  5. Оценка и контроль результатов реализации решения;
  6. Анализ и выявление существенных факторов, повлиявших на решение и результаты его реализации:
    1. Анализ дополнительной информации;
    2. Диагностика возможных причин отклонений.
  7. Регулирование существенных факторов доступными инструментами:
    1. Регулирование на уровне реализации (возврат к п. 3);
    2. Регулирование на уровне выработки решения (возврат к п. 1, 2).

Данный перечень можно использовать для:

  • Анализа полноты и качества выполнения конкретных процессов управления, осуществляемых руководителем;
  • Разработке предложений по оптимизации процессов управления.

Описание процессов управления в среде Business Studio

На Рис. 1. показана структура процессов управления, разработанная в рамках проекта, участником которого являлся автор статьи.

Рассмотрен процесс управления Транспортным отделом торговой компании «Оптима»*, г. Ижевск. Описание процессов выполнено в среде моделирования Business Studio 3.5. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках рассматриваемой задачи ее использование вполне адекватно.

Для описания процессов управления внутри контуров управления использована нотация «Процедура» (более подробно об этой нотации можно прочитать в статье «ARIS eEPC или „Процедура“ Business Studio?»). На Рис. 1. показана кросс-функциональная схема процесса «Корректировка потребности в а/транспорте на месяц/квартал». В рамках данной модели все процессы управления были описаны в виде подобных схем.

Для каждого процесса управления и для каждой операции процессы были заполнены текстовые атрибуты:

  1. Содержание деятельности;
  2. Начало процесса;
  3. Результат процесса.

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

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

Рис. 1. Структура процессов управления Транспортным отделом

Формирование отчета для выгрузки информации из Business Studio

Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на 3-х уровнях:

  1. Описание контура управления;
  2. Описание процесса в контуре управления;
  3. Описание операций процесса (в табличной форме) и схему процесса.

На Рис. 2. показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых «привязок» была сформирована необходимая структура отчета. Далее был создан и отредактирован (под формат, принятый в компании) шаблон отчета — регламент процесса управления на 3-х уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на исполнение для объекта «Управление ТО» (см. Рис. 3).

Рис. 2. Мастер отчетов Business Studio. Разработка регламента управления на 3-х уровнях

Рис. 3. Запуск отчета для объекта «Управление ТО»

Регламент процесса управления для 3-х уровней

Отчет, запущенный для объекта модели «Управление ТО» сгенерировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (см. Рис. 4.).

Рис. 4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio

На Рис. 5. в качестве примера показан вывод информации о контуре управления в отчете. Показано текстовое описание контура и состав процессов управления, которые в него входят (в виде таблицы).

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

Рис. 5. Вывод информации о контуре управления в отчете

На Рис. 6. показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе А4.

Рис. 6. Вывод информации о процессе управления в табличной и графической форме

На Рис. 6 видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы:

  1. Номер операции;
  2. Наименование операции;
  3. Исполнитель;
  4. Инициирующие события;
  5. Входящие документы;
  6. Описание операции;
  7. Завершающие события;
  8. Исходящие документы.

Графическая схема процесса представлена в кросс-функциональном виде.

Объем регламента процесса управления в целом составил для процесса «Управления ТО» около 70 страниц в MS Word, что немного для такого значительного количества процессов.

Заключение

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

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

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

* Компания «Оптима» — это сеть современных удобных и доступных каждому магазинов в формате «дрогери», т. е. «магазин самообслуживания у дома». На сегодня «Оптима» — крупнейшая сеть магазинов непродовольственной группы в Удмуртии. Также компания представлена в Перми и Пермском крае, Республиках Башкортостан и Татарстан. В данный момент компания «Оптима» насчитывает более 60 магазинов и продолжает уверенно и динамично развиваться.

Шаблон отчета в формате XML для загрузки в систему Business Studio

Сентябрь 2010 г.

Рекомендуемые материалы по тематике

Глоссарий. Регламент процесса

Методика описания бизнес-процессов банка. Версия 2.0

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

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

Понравилась статья? Поделить с друзьями:
  • Анализ стейкхолдеров на примере компании лукойл
  • Байкал сервис транспортная компания калькулятор
  • Анализ финансовых результатов компании курсовая
  • Байкальская горная компания оао удоканская медь
  • Анапская жилищная компания ооо официальный сайт