Что такое хорошо и что такое плохо при регламентации бизнес-процессов, или Как создать «правильный» регламент

Введение: зачем регламент руководителю

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

Сколько у Вас работает сотрудников?...

Процентов 50… (любимый ответ одного очень уважаемого мной руководителя).

А на самом деле, сколько у вас, как руководителя, подчиненных? Вы уверены? Скорее всего, в своих подсчетах вы учитывали только прямых подчиненных, которые подвластны именно вам (административно). Как вы думаете, это все кто вам подчиняется в компании? Менеджеры по продажам, менеджеры по закупкам, главные механики и так далее, кому они подчиняются? Бесспорно, своим непосредственным руководителям. Но здесь есть своя тонкость, которая заключается в понятии подчинения. Часто мы путаем его с понятием иерархической лестницы, из серии «посмотрел на погоны и сразу все понятно». На самом же деле, подчиняется — это значит, выполняет установленные кем-то требования, задачи и тому подобное, результаты которых этим кем-то контролируются. Причем жесткость подчинения зависит не от «звезд на погонах», а от жесткости задания этих самых требований и жесткости контроля их исполнения. В зависимости от этого сотрудник подчиняется кому-либо или на уровне сложившихся традиций, или на уровне неофициальных норм, или на уровне официальных правил (вообще, это тема отдельного разговора о корпоративной культуре, в данной статье ограничимся только основными понятиями и определениями) - см. Рисунок 1.

Рисунок 1. Уровни задания жесткости требований к деятельности и поведению сотрудника

Где:

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

Причем этим кем-то (кто выставляет требования и контролирует их исполнение) в компании может быть и обычно является не только один непосредственный руководитель, но и финансовый директор, и директор по персоналу, и директор по IT, и так далее. Это называется функциональное подчинение. Очень наглядно продемонстрировать функциональное подчинение можно на примере простейшего процесса оформления командировок. Ваши сотрудники ездят в командировки? За чей счет? А на каких основаниях они получают командировочные? На основании приказа, командировочного задания. Они сами решили заполнить эти документы, да еще и в установленной форме? Может, их непосредственный руководитель проявил верх сознательности и позаботился о правильности учета и дальнейшем списании затрат? Конечно, нет! Все эти сотрудники выполнили требование финансового директора о правилах оформления командировок точно так же, как и в дальнейшем они выполнят требования по отчету за командировку. Только зачастую эти правила выполняются из рук вон плохо, потому что финансовые директора и прочие функциональные руководители не могут всем все сказать, всех проконтролировать и до всех донести свои требования, ведь эти «межфункциональные требования» зачастую нигде не фиксируются, а доносятся так, как доносятся (на уровне традиций и норм). И чем больше компания — тем больше в этих взаимодействиях и из-за этих взаимодействий проблем. Именно для этого и нужен регламент — зафиксировать требования при выполнении своих бизнес-процессов (то есть БП, которыми управляет тот или иной менеджер процесса).

Мысли глобально — действуй конкретно, или В чем цель регламентации

Все болезни - от непонятки и сомнения, как поступить.
В армии этого нет. Как сказал командир, так и поступай.
Получается отлично. Руки заняты — голова свободна!
(ДМБ)
Старая армейская мудрость

Для того чтобы разобраться с требованиями к «хорошему» регламенту, для начала нужно определиться — кто его потребитель. То есть, кому и зачем он нужен:

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

§ Нужен ли регламент среднему менеджеру — конечно, так как именно в регламенте устанавливаются требования к результатам деятельности;

§ Нужен ли регламент простому исполнителю — нужен. А зачем? Для того чтобы он руководствовался им как неким сводом правил при выполнении тех или иных работ в тех или иных процессах.

Именно в этом и кроется первая основная ошибка регламентации, которая зачастую делит данные проекты на ноль: при разработке регламентов забывают об ожиданиях и потребностях того, кто будет ими пользоваться, — исполнителей. А ожидания их очень просты, из серии «ты не умничай — ты пальцем покажи, что я должен сделать». Зачастую мы просто забываем о необходимости об этом сказать, оставляя выбор способа реализации и организации собственной деятельности за исполнителем. Мы считаем: зафиксировали принципы на верхнем и среднем уровне управления — получили 80% эффекта от решения. Принципы, несомненно, важны! Это бесспорно. Но вот только с точки зрения эффективности вообще и регламентации в частности правило Парето 80/20, к сожалению, не всегда работает. Здесь работает совершенно другое правило: невозможно перепрыгнуть пропасть на 99%. Одними только принципами деятельность не улучшить. Как бы малоприятно для нас это ни было, работы по производству продукта компании осуществляют простые исполнители: рабочие, служащие и так далее. И если мы будем доводить до них наши требования по выполнению работ в виде выскоуровневых принципов, то выглядеть это будет, как в том фильме: «космические корабли бороздят просторы мирового океана».

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

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

a) Определять зоны ответственности сотрудников при выполнении работ;
b) Содержать требования к результатам работ;
c) Содержать требования к содержанию работ;
d) Содержать требования к качеству работ.

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

Кто за что отвечает, или Иерархия регламентирующих документов

– Дядя Вова, цапу надо крутить, цапу!
– Которая тут цапа?
– Вон та - ржавая гайка...
– Да они у вас ту все ржавые...
– А та самая ржавая...
– Вот раз такой умный на сам и крути…
– Мне нельзя, я чатланин!!..
– Уйди отсюда! Как советовать, так все чатлане, а как работать, так…
(Кин-дза-дза)

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

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

У БП есть одна очень нехорошая особенность — разноуровневость. БП, к сожалению, - это не просто «совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы» (как утрирует всем нами любимый стандарт ИСО). Это такой «слоеный пирог преобразований». На самом верхнем слое этого пирога находится «черный ящик», который называется «деятельность компании». Следующий уровень пирога раскрывает основные части этого «черного ящика» — формулирует основные направления деятельности (функциональные области), из которых состоит деятельность компании. Следующий уровень — раскрывает содержания «черных ящиков» по направлениям деятельности, и так далее. То есть каждый нижний уровень данного пирога раскрывает детали верхнего по отношению к нему уровня. Количество этих уровней зависит от размеров компании. Обычно для средних компаний (численностью от 500 до 4 тыс. человек) количество таких уровней будет где-то в районе пяти. Упрощенно их можно отобразить следующим образом (см. рисунок 2):

Рисунок 2. Уровни детализации бизнес-процессов

Где:

• Операция — минимальная для анализа часть деятельности отдельного сотрудника, выполняемая им без проведения осознанного контроля за счет «автоматизма», полученного при многократном повторении. Например, переключить скорость в коробке передач или нажать «CtrlB» в редакторе MS Word, чтобы выделить слово полужирным шрифтом. Естественно, что любая операция когда-то была действием;
• Действие — несколько последовательно выполняемых операций, после выполнения которых исполнитель осуществляет осознанный контроль. Например, заполнить приходно-кассовый ордер или выписать разовый пропуск. Причем, выделяя операции и действия, необходимо ориентироваться не на уровень начинающего работника, а на уровень профессионала;
• Процедура — несколько последовательно выполняемых действий выполняемых одним конкретным исполнителем, приводящим к получению некого результата деятельности, передаваемого другому участнику процесса. То есть результат процедуры всегда передается другому сотруднику. В зависимости от процесса, этот результат может быть документом (электронное письмо, служебная записка, факс), вещественным предметом (сырье на складе, полуфабрикаты на линии и тому подобное) или недокументированной информацией (устное сообщение, телефонный звонок и так далее);
• Бизнес-процесс базового уровня (далее по тексту БПБУ) — последовательность взаимосвязанных процедур, выполняемых различными исполнителями, приводящая к получению законченного и значимого результата для организации. Например, заключенный договор (причем учтенный в бухгалтерии, подшитый архивариусом), акт приема-передачи, товар на складе (с обязательной передачей первичных документов бухгалтеру и учету бухгалтером ТМЦ) и тому подобное;
• Направление деятельности — укрупненная часть деятельности организации, состоящая из одной или нескольких групп бизнес-процессов базового уровня (например, управление персоналом, управление финансами, управление производством, управление логистикой и тому подобное).

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

a) на уровне БПБУ, Процедур и Действий — рядовые исполнители (бухгалтеры, грузчики, тестомесы...);
b) на уровне направлений деятельности — руководители среднего звена (руководители департаментов, отделов, служб…);
c) на уровне всей деятельности компании — первые лица компании (генеральный директор, его замы и так далее).

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

• Принцип первый: «Каждому овощу свой лоток».

По-другому: регламентировать процессы нужно в жестком соответствии с уровнями детализации;

• Принцип второй: «У регламентации должна быть основа».

То есть регламентировать бизнес-процесс можно только на основе схемы (модели), и в этом кроется 60-70% успеха «хорошего» регламента;

• Принцип третий: «Жесткость — сестра прозрачности».

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

• Принцип четвертый: «Регламент - не поэма, а сухое изложение требований, норм, правил».

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

Правила регламентации, или Когда регламент станет «хорошим»

…У нас писарь в уезде был, в пачпорте год рождения
одной только циферкой обозначал —
чернила, шельмец, вишь, экономил.
Потом дело прояснилось, его в острог,
а пачпорта уж переделывать не стали…
Ефимцев, купец, третьего года рождения записан
от Рождества Христова, Куликов — второго,
Кутякин — первого. Да, много тут «долгожителей».
(«Формула любви»)

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

Рисунок 3. Структура документации с учетом уровней детализации БП

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

• Задавать общие принципы (правила) работы как в компании в целом, так и в том или ином направлении деятельности (как декомпозиция целей и задач)
• Фиксировать ответственность за достижение поставленных целей и задач по тому или иному направлению деятельности
• Давать ориентировку сотрудникам:

1. во всей структуре управления компанией
2. в конкретном направлении деятельности
3. в системе регламентации деятельности

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

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

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

Здесь важно понимать, до какого уровня регламентировать деятельность. На практике существует два крайних мнения. Первое - что регламентировать нужно все до самого детального уровня, чтобы исполнитель работал, как некий «биоробот», из серии «шаг влево, шаг вправо — попытка к бегству, расстрел». Второе - что важно задать принципы, а остальное - забота руководителя, как он договорится и решит — так и будет. Во втором случае мы всецело полагаемся на разумность и «правильность» конкретного руководителя. На самом деле, второй вариант имеет место быть и очень даже эффективен в небольших компаниях (до 70-300 человек, в зависимости от отрасли). В таких компаниях преобладают так называемые «джентльменские соглашения», когда правила выполнения детально задаются в основном устно или с помощью разнородных и бессистемных бумажек. И это нормально! На самом деле, количество правил в таких организациях небольшое. С учетом малого количества персонала, компания остается вполне управляемой. При этом у нее есть один ощутимый плюс — такой способ коммуникаций и задания правил самый быстрый (руководитель может быстро перестроить работу, без всяких «лишних» бумажек). А, следовательно, компания оперативно меняется в зависимости от внешней среды и остается гибкой. А ведь гибкость и оперативность — это основное конкурентное преимущество небольших компаний. Когда приходит клиент и просит «хочу то же самое, но с перламутровыми пуговицами», в итоге клиента получает тот, кто быстрее удовлетворил его желание, то есть быстро изменил устройство своей деятельности. К сожалению, регламентация к такой быстроте не располагает. В таких компаниях модель управления и жесткость контроля ее исполнения задается харизмой и организаторскими способностями конкретного руководителя (собственника(ов), генерального директора и так далее).

С другой стороны, при переходе некой границы (некоего количества персонала и правил), когда компания уже достаточно большая и устойчивая, оперативность и гибкость уже принимают иной смысл, который называется «хаосом». Когда все вокруг все быстро решают, а в итоге получается из серии «лебедь, рак и щука». У автора статьи был один забавный случай, когда он как ответственный за планирование производства сотрудник ежедневно в 11 вечера отдавал в цеха посменный план производства, в надежде на то, что все будет произведено вовремя (ибо в компании не хватало производственных мощностей, и она торговала практически «с колес»). Приходил утром, а производство произвело совершенно не то, что указано в плане, потому что какой-нибудь руководитель какого-нибудь отдела звонил в 12 ночи, удивлялся, почему так мало запланировано нужной только ему продукции, и… от сбалансированного плана не оставалось и следа. В этом случае от жесткого описания процесса вплоть до уровня конкретных исполнителей вам никуда не деться. Ибо у каждого руководителя свои цели, часто они разнонаправленны, каждый «тянет одеяло на себя», и в отдельно взятом подразделении или направлении все хорошо, но вот в целом в компании — бардак.

Другая проблема, что во всем нужно знать меру. Так при описании регламента зачастую нет никакого смысла спускаться до уровня операций. Во-первых, потому, что зачастую это смеху подобно, из серии «Водитель, с помощью нажатия на педали газа, тормоза, переключения коробки передач и поворотов руля довозит продукцию до розничной точки» (интересно, почему автор забыл про светофоры, сплошные и вообще не переписал все пункты ПДД). А во-вторых, долго и не всегда разумно, так как квалифицированный сотрудник должен обладать необходимой компетенцией: водитель — уметь водить, бухгалтер — знать план счетов и так далее. В противном случае не совсем понятно, как они оказались у вас в компании. Самое разумное - останавливаться в регламентах на уровне действий, из серии: «Проверяет первичные документы на предмет того-то, того-то», «открывает в 1С 7.7. документ ТОРГ-12», «согласно первичным документам, заполняет все указанные в электронной форме поля», «проверяет получившуюся сумму документа на соответствие указанной в первичном документе» и так далее.

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

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

• Сырье на складе?
• Сырье на складе + первичные документы, переданные в бухгалтерию?
• Сырье на складе + первичные документы, переданные в бухгалтерию + проведенная по бухгалтерии поставка (когда товар появился на остатках, а затраты списаны по бухгалтерии)?

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

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

• Каковы «входы» и «выходы» процесса?
• Из каких процедур состоит процесс?
• Кто выполняет каждую процедуру?
• Что получается в результате ее выполнения?
• Кто получает результат, и что он с ним делает?

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

Последнее, что необходимо отметить, говоря о моделировании в рамках рассматриваемой проблематики: способы моделирования для различных целей различны, и не всегда новомодные средства моделирования становятся благом, с точки зрения регламентации. Интернет пестрит советами и тренингами на эту тему. Aris, BpWin, IDEF, VAD, eEPC… Как милы эти аббревиатуры сердцу простого русского человека. На самом ли деле все так сложно? Или не так страшен зверь, как его малюют, и все это - простой рекламный ход? Все и проще и сложнее одновременно. Здесь важно развести по разным углам две основные задачи, для которых применяется моделирование: автоматизацию БП и оптимизацию/регламентацию БП. Требования к моделированию для этих задач будут разными. Обусловлено это тем, что в первом случае нам важно понять роль IT-системы в БП и требования к IT-ситеме со стороны БП и в дальнейшем использовать данные схемы для постановки задачи на автоматизацию, разработку программного обеспечения и тому подобное. Во втором — нам нужно, чтобы модели были просты, понятны и однозначно воспринимались тем же грузчиком или оператором палочковбивателя. Поэтому для целей регламентации, внедрения правил работы важно получить такую схему бизнес-процесса, которая, с одной стороны, информативна и достаточна для написания регламента (см. требования выше), а с другой — проста и понятна исполнителям БП (демонстрирует простое отображение процесса). Тогда вполне нормальная для регламентации схема БПБУ может выглядеть приблизительно следующим образом (в целях минимизации объема статьи в схеме есть некие упрощения по входным документам и составу процедур):

Рисунок 4. Пример схемы для целей регламентации

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

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

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

Для этого обратимся к приведенному выше примеру схемы. Заметьте, у схемы очень жесткая структура — в ней есть пять основных полей (см. Рисунок 5). Четыре по вертикали:

• «Исполнители», в этом поле указывается должность или роль, которая выполняет ту или иную процедуру бизнес-процесса;
• «Процедуры», в этом поле указывается название процедуры и перечень действий исполнителей (если это необходимо);
• «Условия (исключения)», в этом поле указываются все возможные ветвления результатов процедуры исполнителя, в зависимости от принимаемых им в рамках процедуры решений (обозначены на схеме ромбиком);
• «Результаты», в этом поле указываются все результаты, которые приходят к исполнителю (входы процедуры), либо которые производятся исполнителем в той или иной процедуре (выходы процедуры).

И одно поле по горизонтали — «область описания субъекта», в нем один исполнитель (субъект) отделяется от другого (см. пунктирную линию на Рисунке 5).

Рисунок 5. Разбиение схемы бизнес-процесса по полям

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

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

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

К основным минусам следует отнести нечитабельность такого представления и сложность разработки. К сожалению, работать в таблицах с большим количеством текста очень неудобно. Документ получается большим. При этом его пространство используется неэффективно — в каждом столбце формулируется различное количество текста. Так, например, в поле «Что делает», объективно, текста всегда будет в разы больше, чем в поле «Кто делает», при этом использовать «простаивающее» пространство мы не можем, так как лишимся основных плюсов табличного представления. В итоге тест получится длинным, сжатым, и читать его будет максимально неудобно. А ведь вспомните, с чего мы начинали нашу статью: максимально просто и удобно исполнителю. Плюс к этому, у процедуры может быть не одно условие (исключение), а несколько, причем с достаточно сложным описанием. В этом случае мы вынуждены либо делать динамическую таблицу (с изменяемым количеством столбцов), либо отказываться от принципа адресации, что нежелательно.

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

Теперь транспонируем (перевернем) данную матрицу и получим следующую структуру текста:

n.

n.1. Кто выполняет процедуру.

n.2. Что делает (какие действия совершает) при выполнении процедуры.

n.3. Что является результатом процедуры.

n.4. Требования к процедуре и результатам.

n.5. Описания первого исключения или условия выполнения процедуры.

n.6. Описания второго исключения или условия выполнения процедуры.

n.m. Описания m-ого исключения или условия выполнения процедуры.

В пункте n всегда указывается название процедуры в жестком соответствии схеме. В пункте n.1 всегда формулируется, кто и после чего выполняет данную процедуру (согласно схемы БП). В пункте n.2 всегда перечисляются действия, которые исполнитель должен выполнить, чтобы гарантировано получить указанные в пункте n.3 результаты. В пункте n.4 приводится перечень требований как к качеству выполнения самой процедуры, так и к ее результатам (по времени, качеству, стоимости и тому подобному). Пункты n.5, n.6, n.7 и далее до m описывают все возможные, известные нам ограничения на исполнение процедуры (из серии «в случае, если... - то…»). Таким образом, мы сохранили и адресацию, и жесткость, и назначение ячеек нашего регламента, при этом отказались от таблицы.

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

Рисунок 6. Возможная организация структуры регламента (задание жесткости)

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

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

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

В раздел «Условия и ограничения» указываются:

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

В разделе «Требования к процедурам» задаются правила выполнения работ исполнителей БП (в однозначном соответствии схеме). Данный раздел содержит подразделы от 3.1 до 3.n, где n — количество процедур в схеме бизнес-процесса. Названия подразделов 3.n должны быть такими же, как и названия процедур на схеме бизнес-процесса. Каждый подраздел в обязательном порядке должен содержать пункты 3.n.1 — 3.n.4 (см.Рисунок 6). Стоит отметить, что количество и название результатов процедуры (п. 3.n.3) должны жестко соответствовать схеме бизнес-процесса. Кроме того, в случае наличия неких условий или исключений для процедуры подраздел 3.n может включать пункты 3.n.5., 3.n.6., 3.n.7 и так далее, в которых описывается, какие действия должны быть выполнены исполнителем, если в ходе выполнения процедуры возникли обстоятельства, мешающие логическому ее завершению.

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

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

Радел «Приложения» содержит ссылки на следующие документы и приложения:

1. Схему выполнения процедур;
2. Формы документов, используемые при выполнении процедур.

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

Фото: pixabay.com