Всегда существует множество путей и способов изменения системы. (Закон Берталанфи)

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


Сергей ТУРКО


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

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

Вот эти законы:

  1. Закон недопустимости передачи неготового продукта на следующие стадии (дзидока);

  2. Закон однозначности, четкости и непротиворечивости понятий;

  3. Закон единства значений параметров;

  4. Закон извещений о статусе и двойной записи;

  5. Закон замкнутости процесса;

  6. Закон визуализации;

  7. Закон понимания системы и разделения системных и несистемных причин несоответствий;

  8. Закон разделения работ с разным ритмом;

  9. Закон разделения управленческой и исполнительской работы;

  10. Закон постоянства управления.

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

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

Несоблюдение данного закона опасно, потому что:

  1. размывается ответственность (если одну и ту же работу можно сделать как сразу, так и потом, в режиме переделки, кто в таком случае за нее отвечает?);

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

  3. теряется возможность улучшений (ведь если продукт можно исправить потом, зачем совершенствовать основной процесс?);

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

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

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

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

  1. Все ли процессы в вашей компании дают законченный результат с первого раза? Если нет, что этому мешает?

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

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

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

Говоря об операциональных определениях, У. Шухарт и Э. Деминг имели в виду именно это. Не должно быть никаких различий в понимании любых понятий, например "качество", "бракованное изделие", "быстрое обслуживание", "цель фирмы", а также терминов, включая аббревиатуры. Последнее требование особенно актуально для крупных международных фирм, где часто используют сокращения и иные "красивые" слова для обозначения тех или иных управленческих инициатив.

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

Невнимание к обеспечению однозначности понятий и нечеткости формулировок опасно, потому что:

  1. результат может оказаться далеким от ожидаемого (например, если заказчик поручает дизайнеру разработать рекламный плакат с единственным требованием "чтобы было красиво", вряд ли заказчик останется доволен);

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

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

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

  1. Все ли термины и понятия, которые используются в работе, сотрудники понимают одинаково? Это просто ваше мнение, или вы проверили это на деле?

  2. Когда сотрудник говорит "я все сделал", часто ли бывает, что при ближайшем рассмотрении оказывается, что он сделал работу не до конца или вообще выполнил все совершенно иначе?

  3. Часто ли поручения даются настолько нечетко, что даже сам начальник затрудняется назвать критерий, когда работу считать сделанной правильно, а когда - нет?

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

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

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

Следует обеспечить, чтобы:

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

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

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

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

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

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

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

  1. Существует ли единый регистр для каждого параметра процесса или продукта?

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

  3. Часто ли у разных сотрудников значения одного и того же параметра или экземпляры одного и того же документа различаются?

  4. Хранят ли сотрудники параметры, которые важны не только им, у себя в записной книжке или в отдельном файле, доступ к которому имеют только они?

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

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

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

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

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

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

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

Я часто сталкивался с такой практикой информирования и все время чувствовал, что что-то здесь не так. И действительно! Нарушается принцип обратной связи: сотрудник, давший поручение, сам же оказывается ответственным за обратную связь - ведь это его обязанностью становится "периодически проверять файл". Решение - в признании, что никакой процесс-потребитель (не говоря уже о реальном заказчике) не должен выступать "просителем" важной для него регулярной процессной информации. Ключевое слово здесь "регулярной", т.е. этот принцип применим только к информации, которая является частью системы обратной связи. Уникальные запросы, отчеты - особый случай.

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

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

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

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

  1. Каким образом ответственный за тот или иной процесс узнает, как идут дела? Существует ли система информирования, работающая в проактивном режиме?

  2. Часто ли теряются уникальные носители информации, с которых не были сняты копии?

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

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

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

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

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

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

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

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

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

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

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

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

  3. Часто ли приходится для выполнения задачи беспокоить руководство?

  4. Понимает ли сотрудник, оставивший важную информацию у себя на компьютере, что она может быть нужна кому-то еще?

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

Кто бы захотел ездить по дорогам, если бы вместо трех цветов светофора, видных за километры, использовались надписи, например, "езжай", "стой", "жди", а вместо звукового сигнала при возникновении опасной ситуации на дороге вам на электронную почту высылался отчет, в вежливой форме информирующий о том, что через 0,15 с ожидается столкновение? Ведь как удобно понимать, что происходит, при помощи простых средств индикации - цвета и звука! Почему тогда в организациях важная и нужная информация зачастую представляется в таком сложном виде, что приходится долго и мучительно в ней разбираться? Почему во многих бухгалтерских программах так сложно составить простой и понятный отчет? Почему важные требования контракта или протокола совещания не выделены цветом, жирным шрифтом или иным заметным образом? Неужели все простое и ясное несет оттенок несерьезности, а сложное и заумное (а лучше - вообще непонятное) считается признаком профессионализма? Хочется верить, что нет.

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

Совсем несложно помнить о визуализации при работе с любыми средствами извещений или файлами с информацией о статусе процесса. Например, в информационной системе можно присвоить каждому статусу процесса свой цвет, документы для разных отделов печатать на разной бумаге, различные требования клиентов регистрировать на ярлыках разной формы и пр. Даже средствами MS Excel можно автоматизировать окрашивание ячеек в разные цвета в зависимости от значения содержимого (через функцию условного форматирования). А что уже говорить об информационных системах уровня ERP! Я считаю, что если информационная система не обеспечивает визуализации представления данных, ее эффективность не просто понижается, она может быть вообще сведена к нулю: ведь если критичный статус процесса не удалось своевременно распознать только потому, что он визуально не сильно отличался от других, система просто бесполезна!

Вспоминая работу над интернет-магазином www.alpina.ru, следует сказать, что вся система администрирования заказов проектировалась исходя из требований визуализации. Каждый статус заказа имеет свой цвет, например, выполненные окрашиваются в зеленый, просроченные - в красный, заказы, по которым пришел срок выполнения, - в розовый.
Общее требование визуализации следующее: нужно связать ту или иную важную информацию о процессе с как можно более узнаваемым средством, напрямую доступным нашим органам чувств (любителям писать непонятные отчеты напоминаю, что органы чувств - это зрение, слух, осязание, обоняние, вкус, но никак не интеллект). Слово "визуализация" я употребляю в широком смысле "обеспечения быстрой узнаваемости", а не только в связи со зрительной информацией, хотя объем такой информации и превалирует в средствах информирования. Воздействуя напрямую на органы чувств, можно существенно сократить время реакции на ту или иную проблему по сравнению с включением интеллекта в процесс распознавания информации.

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

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

  2. Можете ли вы с одного взгляда понять, как ведет себя тот или иной процесс? Или для этого надо сделать несколько звонков по телефону другим сотрудникам?

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

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

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

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

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

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

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

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

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

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

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

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

  3. Принимая то или иное решение, на сколько шагов вы просчитываете его последствия? Анализируете ли его влияние на сотрудников? На другие службы? На клиентов, поставщиков, общество?

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

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

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

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

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

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

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

  1. Часто ли бывает, что важная "длинная" работа задерживается, так как сотрудника постоянно прерывают?

  2. Учитывается ли при расчете загрузки сотрудника только чистое время его работы или проводится учет ритма его работы?

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

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

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

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

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

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

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

  2. Не возникают ли ситуации, когда на стратегические дела у менеджеров не остается времени, потому что они постоянно заняты текучкой?

  3. Чем вызвана необходимость включить менеджера в исполнительскую работу? Нет людей? Если работа такая сложная, что ее может выполнить только руководитель, действительно ли это исполнительская работа? Может быть, она связана с постановкой задач и критериев выполнения, т.е. является по сути управленческой?

Краткое описание. Передав задание на исполнение, не следует оставлять его без внимания, думая, что все будет сделано вовремя и правильно, а сотрудник известит сразу, как только появятся проблемы. Управлять - значит постоянно держать объект управления в фокусе внимания.

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

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

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

  1. Держат ли менеджеры вашей организации все свои дела в фокусе внимания? Как часто они уточняют, как идут дела?

  2. Кроме формальной системы отчетности используются ли неформальные беседы и встречи для того, чтобы понять, что происходит?

  3. Не существует ли практики наказывать сотрудника, приносящего плохие вести?

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

1. ТРИЗ - теория решения изобретательских задач. - На эту тему см. публикации А.М. Кузьмина в журнале "Методы менеджмента качества", 2005, № 1-6 под рубрикой "Методы поиска новых идей и решений". - Прим. ред.


Опубликовано в Стандарты и качество





Также на сайте:
Десять шагов по пути к процессной структуре организации
Одиннадцать этапов к усовершенствованным процессам

О проекте

quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.

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

Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

Добавить в "Избранное"

Рекомендуем

Избранные книги

Реклама на сайте





Как сюда попасть?