Обычно это происходит, когда сквозной процесс определяют как целенаправленную последовательность операций (работ, процедур), приводящую к заданному конечному результату — выходу процесса. При использовании данного определения описание процесса представляет собой описание последовательности функций (работ), выполняемых поочередно в различных подразделениях предприятия (часто из разных функциональных направлений), исполнителей, входящих и исходящих документов и т.п.
Работы в рамках функциональных подразделений
- работы, не попавшие
ни в один из процессов
-работы, включенные
в «сквозные» процессы 1и 2
→ сквозной процесс ---→ сквозной процесс 2
Рис. 4.Выделение «сквозных» процессов организации
При использовании такого подхода в организации может быть выделено столько процессов, сколько смогут субъективно обосновать руководители и специалисты. Часто при этом возникает ситуация, когда часть деятельности организации рассматривается как процессы, а часть — нет. Так, на рисунке 4 при выделении сквозных процессов в виде цепочки отдельных работ в подразделениях 1, 2 и 3 из описания «пропали» в общей сложности 4 функции (А, Б, В и Г). Далее на основе такого выделения процессов со стороны внешнего консультанта можно сделать ошибочный вывод о том, что эти функции для выполнения процессов не нужны, и что их можно упразднить. Является ли такое решение корректным? Ответить на этот вопрос без углубленного анализа назначения этих функций невозможно. Чаще всего при таком выделении процессов, когда акцент сделан на преобразование материальных потоков, из рассмотрения выпадают функции учета, отчетности, анализа информации, которые не связаны напрямую с материальными потоками, но абсолютно необходимы для построения системы управления. Тем не менее, эти функции существуют, они необходимы для организации. Производить увольнения, работников, занятых выполнением этих функций (А, Б, В и Г), вряд ли целесообразно. Поэтому руководитель, получив такую модель процессов с выделенными ключевыми, сквозными процессами и не обнаружив в ней функций, выполняемых некоторыми подчиненными, вынужден будет повторно выяснять, в каких процессах участвуют данные сотрудники. Модель сквозных процессов будет усложняться и, все равно, в нее придется постепенно включить деятельность всех сотрудников подразделения, т.е. учесть не только ключевые, но и все остальные процессы организации.
На практике при описании сквозных процессов часто дело доходит до анекдотичной ситуации. Современные нотации моделирования позволяют быстро создать сложную и красивую модель, но в этой модели отсутствует управленческая деятельность самого руководителя подразделения или владельца процесса. Как правило, нотации для описания процессов не имеют жестких требований по правилам построения замкнутых циклов управления. В нотации IDEF0 управление можно описать «туннельной» стрелкой сверху, которая ниоткуда не берется и нигде не регламентирована. Руководитель получает нарисованную схему технологической цепочки выполнения работ и операций, но не видит себя и свои функции на этой схеме, потому что рабочая группа «постеснялась» взять у него интервью и разместить его управленческие функции на модели процессов. Из такой формальной и «ущербной» схемы можно сделать только абсолютно «ущербные» выводы:
• нарисованная система управления процессами не содержит самого управления — только технологическую цепочку функций и работ;
• поскольку процесс функционирует без управления, лишним звеном, которое в него не попало и подлежит увольнению, ЯВЛЯЕТСЯ РУКОВОДИТЕЛЬ.
Такие выводы делать на основании некорректных схем, конечно, нельзя.
Далее на основе такого выделения сквозных процессов развивают целые школы реорганизации управления предприятием. Наибольшее распространение получил подход при котором:
1) создаются описания процессов (модели) «как есть»;
2) проводится анализ моделей «как есть»;
3) разрабатываются модели «как должно быть»;
4) проводится реорганизация реальной деятельности на основе моделей «как должно быть».
В данном случае очевидно, что вопрос построения системы управления в принципе не ставится — фактически выполняется разовый проект улучшения операционных цепочек внутри организации (мы сознательно не касаемся в данном разделе принципов, которые обычно пытаются применять, создавая модель «как должно быть»).
Некоторые специалисты развивают данный подход далее и вводят понятия владельца процесса и владельца ресурса. Для сквозного процесса определяется так называемый владелец, т.е. сотрудник, который отвечает за результат процесса, его эффективность и удовлетворенность клиентов. Назначенный таким образом владелец процесса отвечает за налаживание межфункциональных связей, оптимизацию выполняемых в ходе процесса работ и т.д. При этом реально ресурсами распоряжаются руководители функциональных подразделений. По мнению Т. Конти, владелец процесса должен назначаться из числа руководителей верхнего уровня, например заместителей генерального директора. В любом случае, при таком определении процесса и владельца процесса необходимо четко регламентировать взаимодействие владельца с руководителями функциональных подразделений (владельцами ресурсов). Такая регламентация фактически означает изменение системы управления предприятием, осуществляется переход на матричную или проектную структуру. На практике в большинстве случаев вопрос об изменении системы управления не ставится, но владельцы процессов назначаются. Руководство требует с них результат — повышение эффективности процессов. Но владельцы процессов, не имеющие в своем распоряжении реальных ресурсов и административных полномочий, не могут обеспечить улучшение процессов, возникают конфликты с руководителями функциональных подразделений и т.п. (Представьте себе ситуацию, когда к руководителю функционального подразделения, через которое проходят три сквозных процесса, приходят три владельца этих процессов и требуют в первую очередь выполнить и оптимизировать работы «своего процесса». Конфликт в такой ситуации неизбежен.) Поэтому использование сквозных процессов без значительного изменения принципов управления предприятием, как правило, не приносит желаемых результатов. Кроме того, само определение процесса как последовательности операций не позволяет применять к нему принципы управления, на основе обратной связи, заложенные в концептуальной схеме.
На рисунке 4 отображена еще одна проблема, с которой придется встретиться при описании сквозных процессов. В подразделении 4 одна и та же работа попала в два различных сквозных процесса. Два разных процесса буду претендовать на то, чтобы данная работа выполнялась в их интересах, которые могут не учитывать интересы начальника подразделения 4 или всей организации в целом. Кроме того, может возникнуть ситуация, когда при появлении нового, третьего сквозного процесса, конфликт интересов в борьбе за ресурсы возникнет с новой силой.
Декомпозиция процессов
На следующем рисунке 5 представлена декомпозиция одного из процессов верхнего уровня на более детальный процесс (подпроцесс, функцию). Если рассматривать деятельность организации в целом, то для ее описания используются укрупненные процессы. Примером процесса верхнего уровня может быть процесс закупок сырья и материалов для производства, который включает такие функции, как: планирование закупок, заключение договоров, оформление заказов, получение ТМЦ (товарно-материальных ценностей), оплата ТМЦ, отпуск ТМЦ в производство. Число уровней декомпозиции процессов определяется задачами проекта, и не должно быть слишком большим — более 6—8 уровней. При определении бизнес-процессов, существующих в организации, целесообразно начинать описание процессов с верхнего уровня.
Процессы верхнего уровня
Декомпозиция процесса на подпроцессы нижн
Рис. 5.Декомпозиция процесса на подпроцессы (функции)
До какой глубины описания целесообразно опускаться?
1. Уровень предприятия в целом — владельцы процессов — заместители директора
2-3. Уровень управлений — процессы, в которых по-крупному описаны функции управлений
3-4. Уровень отделов — детальные процессы (описаны функции отделов)
4-6. Уровень рабочих мест – детальные процессы (описаны функции, выполняемые на рабочих местах)
6-8. Уровень описания операций, выполняемых на рабочих местах (должностные и рабочие инструкции)
Рис. 6. Степень детальности описания процесса
Одним из важнейших вопросов, возникающих при моделировании бизнес-процессов, является определение необходимой глубины описания. При проведении декомпозиции моделей количество объектов на диаграмме растет в геометрической прогрессии. Поэтому всегда очень важно изначально определить практически целесообразную степень детальности описания, как показано на рисунке 6.
Верхний уровень описания бизнес-процессов соответствует процессам, которыми управляют топ-менеджеры уровня заместителей генерального директора. Второй уровень процессов, как правило, рассматривается на уровне крупных функциональных подразделений предприятия. Третий уровень — уровень функций подразделений и отделов. Четвертый уровень — функции, выполняемые на рабочих местах, и т.д. Следует обратить внимание, что число объектов модели при декомпозиции может стать очень большим.
1.3. Процессная и функциональная системы управления:
Возможно ли совмещение?
Подавляющее большинство организаций в современном мире устроено по функционально-иерархическому принципу, подразумевающему наличие нескольких (3—12) уровней управления — от генерального директора (президента) до простого рабочего. Звенья иерархической системы (подразделения организации) часто сгруппированы по функциональному признаку, т.е. по видам деятельность внутри организации, например: управление сбыта, финансовый отдел, бухгалтерия и т.д. Внутри каждого такого звена существует функциональная иерархия от начальника верхнего уровня — к простому исполнителю. Очевидно, что внутри звеньев функциональной иерархии существуют потоки информации, направленные сверху вниз и снизу вверх. Примерами таких потоков могут служить:
• плановая информация о деятельности функционального подразделения, доводимая начальником подразделения до подчиненных;
• контроль (согласование, визирование) подготовленных на нижнем уровне документов последовательно по всем уровням иерархии в рамках функционального подразделения;
• передача оперативной и периодической отчетности по выполненной работе исполнителями снизу вверх, формирование сводных отчетов и передача руководителям функциональной иерархии.
На рисунке 7 вертикальные потоки управленческих решений показаны в виде пунктирных стрелок, идущих от вершины пирамиды (символизирующей иерархию управления) к основанию и наоборот, информация о процессах идет снизу вверх. Называть вертикальные потоки информации процессами было бы некорректно, так как эти потоки являются только частью деятельности, выполняемой в функциональных подразделениях. Мы не станем называть вертикальным процессом простую последовательность шагов по передаче документа с одного рабочего места на другое сверху вниз по функциональной иерархии.
|
→
Вертикальные потоки информации (отчёты,
управленческие решения)
Бизнес-процессы предприятия
- Управленческая деятельность владельцев процессов
Рис. 7. Вложенность процессов по иерархии и вертикальные потоки информации
Построение иерархии бизнес-процессов приводит к тому, что наряду с уже существующей системой функционально-административного управления придется строить еще одну систему — систему управления процессами. Очевидно, что управлять сложным межфункциональным бизнес-процессом один руководитель не в состоянии (а именно такие процессы называют сквозными). Ему неизбежно придется брать себе заместителей и распределять между ними сегменты процесса, закрепляя ответственность за каждый сегмент за кем-то из них. Заметим, что границы сегментов такого сквозного процесса могут не совпасть с границами функциональных подразделений. Сегментирование сквозного процесса и назначение заместителей его владельца приведет к созданию некоторой иерархии управления сквозным процессом. Если такие действия будут выполнены по всем сквозным процессам, то в организации будет создана сложная многоуровневая иерархия управления бизнес-процессами. Но в этом случае в организации появится две параллельно существующие системы менеджмента. Одна из них основана на существующей структуре подразделений и является традиционной и понятной всем. Другая система менеджмента — процессная. Она живет своей жизнью, обеспечивая «эффективность» процессов. Таким образом, в организации будут одновременно существовать две системы менеджмента, которые должны постоянно согласовывать свои действия. Не говоря об огромных дополнительных затратах, целесообразность подобной менеджерской практики вызывает большие сомнения.
Две системы управления (процессная и функциональная) потребуют две системы учета и отчетности, две системы распределения ресурсов и, если довести ситуацию до полного абсурда, две системы планирования. Количество отчетных документов возрастет, как минимум, в два раза. Во столько же раз возрастет и количество указаний и распоряжений для рядового персонала.
Мы считаем, что выделив сквозные процессы можно сопоставить их с существующей структурой организации и понять, где структура «рвет» процессы с точки зрения зон ответственности руководителей. Далее мы предлагаем не порождать две параллельные системы менеджмента, а оставить традиционную систему, изменяя при этом границы структурных подразделений так, чтобы они совпадали с процессами, не «рвали» процессы. Мы понимаем практическую сложность такой работы, но это более приемлемо, чем создание и поддержание в рабочем состоянии двух систем менеджмента в одной организации. Кроме того, изменение границ структурных подразделений будет проводиться исходя из целей процессов — достижения наилучшего результата, а не для получения аппаратно-административных выгод.