Заводсков Сергей Вадимович
бизнес-аналитик, эксперт по системам управления
Процессное управление и его отличие от ручного
- • Чеклист: признаки ручного управления организацией или процессом
- • Чем отличаются ручное и процессное управление. Ручное управление на примере. Ручное управление в электронном виде
- • Почему ручное управление бизнесом или процессом — это плохо, пример на схеме
- • Как перейти к процессному управлению. Cпособы управления заданиями — поток и план процесса
- • Какие ещё изменения понадобятся
• Систематизация бизнеса
• Выстраивание, реинжиниринг бизнес-процесса "как надо"
• Автоматизация процессов
• Описание бизнес-процессов "как есть"
• Оптимизация бизнес-процессов
• Внедрение регламентов, внедрение изменений в бизнес-процесс
• Лучшие практики. Готовые регламенты + внедрение
• Диагностика компании и бизнес-процессов
А есть ли альтернатива? Да, мы можем объединить повторяемые задачи в полноценный бизнес-процесс, и избежать всех этих недостатков. Но сначала давайте разберемся подробнее с ручным управлением.
А есть ли альтернатива? Да, мы можем объединить повторяемые задачи в полноценный бизнес-процесс, и избежать всех этих недостатков. Но сначала давайте разберемся подробнее с ручным управлением.
Чеклист: признаки ручного управления в организации
Мы привыкли к тому, что руководитель распределяет все задачи (то есть — каждую задачу), а ведь это как раз и есть ручное управление! Именно это та стандартная форма управления, которая реализуется в большинстве мест. Проверьте, какие признаки ручного управления есть в вашей компании.
№ | Признак |
1 | Исполнитель без команды не приступает к задаче, даже если она есть в графике или подобных документах и по ней имеется вся исходная информация |
2 | Некоторые/многие/все задачи процесса не создаются в начале процесса, а возникают внезапно (не из-за действий внешних сил и внешних событий, а просто диспетчер создаёт задачи по одной по мере выполнения предыдущих) |
3 | Нельзя сказать, когда процесс закончится, и даже — сколько в нем ещё будет задач |
4 | У «экземпляра процесса» (например, заказ клиента) есть «состояние сейчас», но нельзя сказать, медленнее или быстрее, чем надо, идёт этот «экземпляр процесса» |
5 | Исполнитель не может сказать, чем будет заниматься, например, через неделю, даже если уже все данные и «вводные» поступили (в сложных случаях — не может сказать, чем будет заниматься завтра и даже сегодня) |
6 | Руководитель (или распределяющий задачи) сильно занят, загружен; если есть проблема загруженности — то в 90% случаев есть проблема ручного управления |
Чем отличаются процессное управление и ручное управление
Классический процесс (в процессном подходе к технологии управления) — это связная последовательность задач, положенная на шкалу времени. Что из этого следует?
Задача по процессу отличается от задачи не по процессу. Задача по процессу — регулярная. Её нельзя не делать или делать в другое время (нужно делать в то, в какое положено по процессу).
Поэтому по ней сразу понятно что, как, когда делать, не нужна специальная «постановка задачи», и, как правило, не нужно и согласование задачи — следующий в цепочке обязан её выполнить, как только произошло «событие входа».
У каждой задачи есть нормативное время, когда она должна быть выполнена. Поэтому в момент начала процесса или в другие узловые моменты можно сказать, когда процесс должен закончиться.
Конечно, с той или иной степенью приближения, если там есть не зависящие от нас факторы: допустим, действия клиента. Но та часть, где действуют сотрудники компании, может быть рассчитана достаточно точно.
Выполнение одной операции автоматически вызывает выполнение следующей, не нужна какая-то специальная команда на продолжение, если это не оговорено особо.
Ну а в жизни в деятельности компаний часто вместо такого связного процесса имеется разрозненный набор задач.
В этом случае процесс разрезается на задачи, а между ними вставляются действия «диспетчера» (руководителя), который и говорит, кому, что, когда делать. Так и осуществляется управление.
В худшем случае каждый раз ещё и повторяется постановка задачи, в том числе через группу начальников, если это задача между разными подразделениями.
При этом речь идет о задаче по процессу, то есть повторяемой и которую нельзя не делать.
И ещё сложнее: ручное управление может быть и на уровне процесса и на уровне отделов. (Часто — и там, и там.)
Например, менеджер или руководитель проекта (тот, кто ведет экземпляр процесса) выступает как диспетчер, раздавая отделам задания по процессу.
А в отделах то же самое делает руководитель отдела, раздает задания, поступившие в отдел, конкретным исполнителям.
И если хотя бы один диспетчер не распределил задание, то никто не приступает к этому заданию, даже если все исполнители свободны.
Ручное управление в электронном виде
В современных компаниях ручное управление может быть в электронном виде.
В этом случае разрозненные задания создаются через систему постановки задач (планировщик, CRM, ERP и др.). Как правило, там есть полноценные инструменты постановки задач, с согласованием срока, вопросами, приложением исходных документов, отчетом о выполнении, назначении контролера/наблюдателя и т.п., что дополнительно усложняет работу и в данном случае вредит.
При этом, если нет такой электронной задачи, то исполнитель её не делает, даже если в процессе произошло «событие входа», и задачу делать надо.
Ручное управление на примере
Пусть есть процедура, где в ответ на какие-то внешние данные с ними работают две службы. Например, дизайнер и конструктор готовят эскиз изделия для клиента при заказе. Или для выкладывания на сайт в ответ на ТЗ копирайтер готовит текст статьи, а дизайнер — картинки к нему. Вот что содержательного делается в этой процедуре.
А теперь добавим к этому операции ручного управления.
Я нарисовал один прямоугольник прерывистой линией: "Поругаться о постановке задачи", потому что в практике при таком подходе к постановке задач просят перенести сроки, или придираются к неполноте документов и т.п.
Это я ещё не стал глумиться и не показал варианты, когда кто-либо не принял задачу или не принял результат задачи.
Схема процедуры с ручным управлением
Почему ручное управление бизнесом или процессом — это плохо?
Создаётся «спам», и действительно важные вещи теряются в потоке текучки. Если есть пятьдесят «задач» и одна ключевая, настоящая — то как скоро её заметят? Если к тому же в электронной системе неправильно настроено информирование, то на 30 задач может быть 100-150 уведомлений.
Это занимает лишнее время как чистое (на создание задач, заполнение, согласование), так и создает общее затягивание процесса на период ожидания, пока все эти люди найдут задачу среди «спама», откроют, прочитают, заполнят, переадресуют и пр. То есть тратится лишнее время на управление.
Нарушается здоровое взаимодействие внутренних клиентов и поставщиков, когда стандартный ответ на любую проблему: «без задачи ничего делать не буду».
Невозможно управлять загрузкой отдела / цепочки исполнителей, ведь будущие задачи нигде не записаны, поэтому нельзя увидеть пики и пробелы в загрузке.
Невозможно проактивно управлять самим процессом, а только реагируя на уже случившееся. Если мы не знаем, когда будет результат — то мы не управляем процессом.
И по той же причине невозможно оптимизировать работу. Во-первых, руководитель очень занят, а во-вторых, нет прогноза на будущее, поэтому нельзя на него никак воздействовать, а можно только реагировать на события.
Между прочим, когда мы проводили замер трудоёмкости, то в нескольких случаях обнаружили, что создание задач и отчёт за них (без собственно выполнения их) занимают в целом в месяц больше времени в отделе, чем некоторые полезные функции подразделения.
Откуда берётся ручное управление?
Как правило, оно связано с тем, что большинство руководителей не понимает: как это без него его сотрудник начнет выполнять задание! Даже если он всегда задания такого типа направляет этому сотруднику. И ни разу не сделал чего-то другого: не отверг и не изменил задание)!
А ведь в обычном магазине продавец начинает обслуживать покупателя без команды со стороны директора магазина. И директор не считает, что это умаляет его власть.
То есть многие руководители не знают, чем должен заниматься руководитель, и считают, что как раз ручным управлением.
Как перейти к процессному управлению
Внедрение регламента — это отказ от ручного управления (полный или частичный) в рамках процесса. То есть мы один раз решаем, как поступать со всеми задачами, относящимися к процессу (в том числе по их типам, подвидам, сложным правилам).
А как тогда управлять задачами и экземплярами процесса (например, потоком заказов), если не через "диспетчера"? Есть два способа — это план (график) процесса и поток заданий.
Как работает поток заданий
Поток – это когда задания распределяются и выполняются по неким заранее определенным правилам.
Например, экономист или менеджер ведёт определенных клиентов или объекты, и всё, что происходит по этим клиентам или объектам, он обрабатывает в порядке поступления, а срочные задачи — в приоритетном порядке (есть правила, как он определяет, что задача срочная).
К руководителю исполнитель обращается, только если наступает событие, оговоренное руководителем (сделка на миллион), или если случилось то, чего не было раньше, или произошел перегруз задачами или сбой.
Вот какая получается схема
А вот как действует исполнитель:
— Заглядывает туда, где лежат задания. Видит задание, относящееся к нему.
— Задание нормальное? Время есть? Не является заранее оговоренным случаям? — тогда делает и в конце отчитается.
— Если задание ненормальное (например, в нем чего-то не хватает) или нет времени, или относится к заранее оговоренным случаям — делает то, что руководитель сказал для этого случая: например, обращается к эксперту.
— Если не помогло или сбой / проблемы / не успеваю / случилось что-то новое – то обращается к руководителю.
Здесь мы убираем от руководителя назначение заданий и саму процедуру назначения заданий. Оставляем только рассмотрение сбоев, реакцию и точечное вмешательство. Т.е. он работает не со 100% заданий, а с 10-20%.
Время руководителя существенно высвобождается, и нестандартным случаям он может уделить больше внимания, для того чтобы перевести часть их в регламентные, разработать правила их предотвращения или поведения в таких ситуациях.
Как работает план процесса
В начале процесса (или сразу при получении достаточной информации) формируется набор заданий навесь процесс или на этап процесса (если там есть внешние силы, например решение клиента), со сроками «как надо».
Простейшая форма — контрольная таблица. Здесь пример контрольной таблицы и описание, какую информацию можно из неё извлечь.
Если есть проблемы с загруженностью — то план согласуется с исполнителями (руководителями отделов, которые подтверждают, что в это время смогут это сделать; для этого им нужен сводный план по всем проектам по всем задачам, или подобный инструмент). При необходимости сроки сдвигают.
В дальнейшем при наступлении срока каждый сам, без команды "диспетчера", приступает к своей задаче, при необходимости требуя от предыдущего участника промежуточный результат.
А при неполучении или проблемах — уведомляет владельца процесса о нарушении.
«В идеале» мы при этом спрашиваем результат только с последнего участника, остальные спрашивают друг с друга сами. (Хотя, если мы не готовы в конце процесса увидеть неожиданное, то разумный промежуточный контроль нам всё-таки понадобится.)
Этот план корректируется при появлении дополнительной информации или новых «вводных».
Если случается остановка процесса — например, отказ клиента от сделки — то тогда все задания по этому экземпляру процесса удаляются и график корректируется.
В отличие от потока, здесь мы видим прогноз будущего состояния дел. Это позволяет более гибко управлять процессом: например, провести заказ срочно или по нестандартному пути, и при этом не порушить остальные экземпляры процесса и не делать это в ручном режиме.
Вариант плана процесса при проблемах с загруженностью
Каждый заказ (будущий или принятый) изображается как набор единиц трудоемкости (нормочасов/дней и т.п.) для каждого подразделения, при этом эти единицы взаимосвязаны как процесс, т.е. могут быть последовательными, параллельными и пр.
Сначала таким образом вносятся все текущие заказы, затем к ним добавляются потенциальные. При появлении нового заказа он огрублённо или на основании расчета вносится в этот план, таким образом мы сразу видим:
А) возможный срок выполнения заказа;
Б) когда будут пики нагрузки и простои по подразделениям;
В) когда будет конфликт приоритетов между заказами;
Поставив фильтр по своему подразделению, участник увидит загрузку своего подразделения. Аналогичную вещь можно сделать в MS Project, но там есть большой соблазн всё усложнить: следите за этим.
Какие ещё изменения понадобятся
Другой принцип распределения задач внутри подразделений
В обоих этих случаях при процессном подходе мы даём больше самостоятельности исполнителям.
Вместо «ждать пока назначат» — исполнитель должен брать задачи сам (это годится для дизайнеров, конструкторов, сметчиков и пр. квалифицированных сотрудников). Т.е. задания «разложены» по будущим периодам с небольшим люфтом, а исполнители берут их. Тогда у нас не будет простоя в ожидании команды.
Чтобы не брали слишком медленно — руководителю нужно сделать «рабочее место» со «взглядом сверху» на все эти задания: он видит «горящие» задания, и может вмешаться и подбодрить.
Разница в том, что здесь он это делает выборочно, а не по каждому заданию, и находясь не внутри процесса, а над ним (т.е. процесс идёт и без него).
Руководитель же, вместо того, чтобы раздавать задачи, может заняться анализом и улучшением работы: например, почему у его людей разная производительность, кто лучше и хуже; провести обучение, продумать, как изменить работу, чтобы повысить производительность; оценить, какие замечания по качеству обычно получают сотрудники и как этого избежать; кому больше подходит какой тип задания и т.п.
Об оценке сложности заданий
Часто руководители аргументируют необходимость диспетчеризировать задания тем, что надо, например оценить их сложность или трудоемкость, назначить их «цену» для расчета зарплаты или премии.
На самом деле обработка заданий — например, оценка их трудоёмкости — может выполняться параллельно, не влияя на сроки заданий, лишь бы к концу месяца была доделана. Ведь рассчитать зарплату – это не ЦЕЛЬ процесса, а побочный результат, и он не должен мешать основному.
Об отметке о выполнении
Отметка о выполнении задания должна совпадать с приёмкой задания в работу следующим сотрудником, это одно и то же действие, а не два. И внешне она должна как-то выражаться только в случае замечаний или отказа.
Т.е. если ты взял это и стал с этим работать, то ты его уже принял, никаких специальных действий не должно быть. Если хочешь не принять — должен написать замечания.
Иначе возникают задания с неясным статусом — и замечаний нет, и не приняты.
Вот примерно этим и отличается ручное управление от процессного. Выстраивание управления процессом входит в нашу услугу Выстраивание, упорядочивание, переделка процесса — мы разработаем то, что идеально подойдёт в Вашем случае.