Доброе утро, коллеги.

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

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

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

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

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

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

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

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

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

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

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

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