Процессное управление и его отличие от ручного

Заводсков Сергей Вадимович

А есть ли альтернатива? Да, мы можем объединить повторяемые задачи в полноценный бизнес-процесс, и избежать всех этих недостатков. Но сначала давайте разберемся подробнее с ручным управлением.

Чем отличаются процессное управление и ручное управление

Классический процесс (в процессном подходе к технологии управления) — это связная последовательность задач, положенная на шкалу времени. Что из этого следует?

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

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

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

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

При этом речь идет о задаче по процессу, то есть повторяемой и которую нельзя не делать.

И ещё сложнее: ручное управление может быть и на уровне процесса и на уровне отделов. (Часто — и там, и там.) Например, менеджер или руководитель проекта (тот, кто ведет экземпляр процесса) выступает как диспетчер, раздавая отделам задания по процессу.
А в отделах то же самое делает руководитель отдела, раздает задания, поступившие в отдел, конкретным исполнителям. И если хотя бы один диспетчер не распределил задание, то никто не приступает к этому заданию, даже если все исполнители свободны.

Ручное управление в электронном виде

В современных компаниях ручное управление может быть в электронном виде.

В этом случае разрозненные задания создаются через систему постановки задач (планировщик, CRM, ERP и др.). Как правило, там есть полноценные инструменты постановки задач, с согласованием срока, вопросами, приложением исходных документов, отчетом о выполнении, назначении контролера/наблюдателя и т.п., что дополнительно усложняет работу и в данном случае вредит.

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

Ручное управление на примере

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

Заводсков Сергей Вадимович

А теперь добавим к этому операции ручного управления.

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

Схема процедуры с ручным управлением

Заводсков Сергей Вадимович

Как перейти к процессному управлению

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

А как тогда управлять задачами и экземплярами процесса (например, потоком заказов), если не через "диспетчера"? Есть два способа — это план (график) процесса и поток заданий.

Как работает поток заданий

Поток – это когда задания распределяются и выполняются по неким заранее определенным правилам.

Например, экономист или менеджер ведёт определенных клиентов или объекты, и всё, что происходит по этим клиентам или объектам, он обрабатывает в порядке поступления, а срочные задачи — в приоритетном порядке (есть правила, как он определяет, что задача срочная).

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

Вот какая получается схема

Заводсков Сергей Вадимович

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

Здесь мы убираем от руководителя назначение заданий и саму процедуру назначения заданий. Оставляем только рассмотрение сбоев, реакцию и точечное вмешательство. Т.е. он работает не со 100% заданий, а с 10-20%.

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

Как работает план процесса

В начале процесса (или сразу при получении достаточной информации) формируется набор заданий навесь процесс или на этап процесса (если там есть внешние силы, например решение клиента), со сроками «как надо».

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

Если есть проблемы с загруженностью — то план согласуется с исполнителями (руководителями отделов, которые подтверждают, что в это время смогут это сделать; для этого им нужен сводный план по всем проектам по всем задачам, или подобный инструмент). При необходимости сроки сдвигают.

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

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

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

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

Вариант плана процесса при проблемах с загруженностью

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

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

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

Поставив фильтр по своему подразделению, участник увидит загрузку своего подразделения. Аналогичную вещь можно сделать в MS Project, но там есть большой соблазн всё усложнить: следите за этим.

Какие ещё изменения понадобятся

Другой принцип распределения задач внутри подразделений

В обоих этих случаях при процессном подходе мы даём больше самостоятельности исполнителям.

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

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

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

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

Об оценке сложности заданий

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

На самом деле обработка заданий — например, оценка их трудоёмкости — может выполняться параллельно, не влияя на сроки заданий, лишь бы к концу месяца была доделана. Ведь рассчитать зарплату – это не ЦЕЛЬ процесса, а побочный результат, и он не должен мешать основному.

Об отметке о выполнении

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

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

Иначе возникают задания с неясным статусом — и замечаний нет, и не приняты.

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

→ В Базу знаний | К началу страницы