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

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

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

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

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

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

Вкратце это выглядит так:

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

Пунктов конечно больше и они объемнее, но суть примерно такая.

Что же начинает происходить в жизни?

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

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

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

Вариантов выхода здесь не так уж много…

1. Нужно сделать так, чтобы исполнение регламента было единственным вариантом получения желаемого. Например, заявки принимаются только по электронной почте и выполняются в порядке поступления. Все остальные варианты поступления заявок – игнорируются, причем ответственность за невыполнение заявки полностью ложится на инициатора.
2. Нужно сделать так, чтобы у тех кто соблюдает регламент было ощутимое преимущество перед теми, кто его не соблюдает. Например, заявки, поступившие по стандартному каналу, обрабатываются первыми, не зависимо от «срочности» остальных заявок. Что-то вроде отдельной очереди для инвалидов и участников ВОВ.
3. Ввести некую систему «оплаты». Например, у IT-службы имеется некий объем ресурса, который расходуется на выполнение задач (пусть это будет объем человеко-часов программиста 1С). Этот объем выражается в баллах и распределяется между «клиентами» (подразделениями). Все поступающие задачи оцениваются в этих баллах и их выполнение списывает соответствующее количество баллов со счета подразделения. У задач существуют «дополнительные характеристики» как то: срочность, важность и т.д. и т.п. Характеристики имеют «коэффициент» к стоимости задачи.

Получается: задача оценивается в 5 баллов и выполняется согласно графику, т.е. – через 2 недели. Если инициатор присваивает ей срочность (за 1 неделю, вместо 2-х), то стоимость задачи умножается на коэффициент 2 и получается 10 баллов. Если инициатор хочет, чтобы задача была выполнена завтра, то ее стоимость становится 15 баллов и т.д. Пусть инициатор сам решает получить 5 задач по графику или получить быстро 2 и на этом до конца месяца лимит будет исчерпан.

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

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

Переводя на язык нашего примера – если вы можете решить сегодня 2 задачи, а вам поступило 3 и все срочные, вы все равно, сможете выполнить только 2.

При этом, вам придется решать, какую задачу вы сегодня отбросите. Проблема в том, что если процесс и алгоритм этого решения четко не поставлен (причем, на самом высоком уровне), то потом никто не будет оценивать, как хорошо вы выполнили 2 задачи, все внимание будет сосредоточено на том, что вы НЕ ВЫПОЛНИЛИ третью задачу. А ведь она была важной и срочной.

Формулировка и утверждение алгоритма выбора что выполнять, если выполнить все не возможно – задача очень важная. Это единственный вариант снять с себя ответственность за то, что Вы выполнить не в состоянии. Кроме того, этот алгоритм должен быть публичным и известным всем. Только так можно избежать нескончаемых споров «а почему выбрали не меня?!».