Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Оптимизация кросс-функциональных процессов

Это третья и завершающая часть исследования на тему управления кросс-функциональными процессами. Предыдущие части:

  1. Вульгарное представление о кросс-функциональных бизнес-процессах
  2. Кросс-функциональные паттерны

Во второй части мы рассмотрели два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:

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

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

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

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

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

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

1. Линейная система

Начнем с простейшей постановки задачи: N подразделений выполняет каждое по одной из N задач (или подпроцессов) в рамках единственного бизнес-процесса (других процессов нет). Пример:

Рис. 1. Производительность ресурсов и производительность процесса

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

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

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

Звенья, не являющиеся «бутылочным горлышком», изображены зеленым цветом, за исключением второго с конца по производительности звена - в данном примере это производственный участок, его мы покрасили желтым. Он определяет, на сколько можно повысить производительность процесса только за счет увеличения производительности «бутылочного горлышка»: в данном примере с 60 до 80, т.е. на 33%.

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

Согласно Теории ограничений, буфер следует организовать перед «бутылочным горлышком», но только в этом единственном месте: дополнительные буфера не повысят производительность, а только приведут к лишним затратам.

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

Рис. 2. Оптимальная схема для процесса с одним «бутылочным горлышком»

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

2. Ограничение на входе системы

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

Рис. 3. Процесс, ограниченный по входу

В этом случае оптимальной будет полностью синхронная схема:

Рис. 4. Оптимальная схема для процесса, ограниченного по входу

Ситуация может показаться абсурдной: зачем держать ресурсы, превышающие имеющийся спрос? Тем не менее, такая ситуация встречается достаточно часто:

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

В рассматриваемом примере запас производительности процесса относительно спроса составляет 20%. Если спрос колеблется в этих пределах, то синхронная схема будет предпочтительной; если больше, то есть смысл вернуться к схеме на рис. 2.

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

3. Влияние стартов

Синхронный режим работы является таковым с точки зрения процесса, а с точки зрения исполнителя (ресурса) вовсе наоборот:

  • сидим, курим, заказов нет
  • пришел заказ- работаем, особо не спешим
  • второй заказ, третий- откуда их столько?
  • аврал, не справляемся, выполнение заказов задерживается
  • уф, справились, снова курим

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

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

4. Влияние переналадок

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

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

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

Проиллюстрируем это простейшим примером: пусть вам на вход поступают задачи двух видов: А и Б -

  • при синхронном режиме исполнения процессов вы будете их обрабатывать в той последовательности, в которой они к вам поступили: А1, А2, Б1, А3, Б2, А4, А5, Б3,…
  • при асинхронном режиме исполнения процессов задания будут накапливаться в буфере и обрабатываться сериями: А1+А2+А3+А4+А5, Б1+Б2+Б3,…

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

5. Рекомендации по оптимизации с учетом нелинейных факторов

Итак, в синхронном режиме время исполнения процесса минимально (хорошо), но этот режим сопряжен со снижением производительности из-за стартов и переналадок (плохо).

В результате мы можем получить, например, такую картину:

Рис. 5. Снижение производительности из-за стартов и переналадок

Снижение производительности на участке дизайна привело к тому, что он стал узким местом - его производительность стала ниже уровня спроса. Простейший способ справиться с этой проблемой - вернуться к асинхронной схеме работы, изображенной на рис. 2. Мало того, из-за снижения производительности на участке производства он тоже «провалился» ниже уровня спроса - следовательно, его тоже надо перевести на асинхронный режим.

Но переход от синхронного режиму к асинхронному - только один из возможных вариантов действий. Другой предлагает система Тойоты: не компрометировать качество (не увеличивать продолжительность процесса), а сокращать время, затрачиваемое на старты и переналадки.

То есть, применительно к работе, выполняемой людьми:

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

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

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

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

В конечном итоге, все зависит от мотивации: когда в маленькую компанию звонит клиент, то никому не надо объяснять, что клиент - это главное, а все остальные дела могут подождать. А в большой компании? «Если мой звонок так важен для вас, то черт возьми, возьмите наконец трубку!» Но эта тема уже выходит за рамки данной статьи.

6. Оптимизация вспомогательных процессов

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

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

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

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

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

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

17.02.11 | Статьи | ,    

Комментарии (8)

  1. Сергей Ладнич 22.02.11 17:17

    Добрый день, Анатолий.
    У меня вопрос по рисунку 2. Я интерпретирую выполнение данной схемы так:
    При поступлении заказа от клиента создается токен в БП “Клиентский заказ”. Выполняется операция, в результате которой информация о заказе поступает в буфер. После этого токен переходит в “ожидание” сообщения от доставки. При этом в процессе “Клиентский заказ” может быть создано много токенов, пополнивших буфер и ожидающих сообщения от доставки.
    Теперь посмотрим на процесс “Производство”. При наступлении определенного времени создается токен этого процесса, причем один. Он поступает на выполнение в операцию по дизайну. По идее дизайн берет буфер за основу и начинает выполнять по каждой из позиций экземпляр задачи “дизайн”. После выполнения каждого экземпляра такой задачи генерируется токен для продолжения процесса “Производство”. Количество таких токенов равно количеству позиций в буфере. При выполнении доставки в процесс “Клиентский заказ” поступает сообщение о возможности продолжения процесса по токену из набора ожидающих такого сообщения токенов. Дальше процесс идет так как Вы нарисовали.
    Вот только ситуация: дизайн берет буфер за основу и начинает выполнять по каждой из позиций экземпляр задачи “дизайн”, причем не обязательно в хронологическом порядке поступления заявок в буфер. Тогда мне не совсем понятно за счет чего определяется, какой из токенов должен продолжить свой путь по приходу сообщения о доставке. Не могли бы Вы прокомментировать такую неоднозначность?
    Еще вопрос: зачем моделировать процесс так как показано на рисунке? Если смоделировать процесс так как показано на рисунке 4, то у дизайнера в BPMS системе сама по себе организуется очередь из задач. Буфер в таком случае все равно образуется, только диаграмма будет проще в каком то роде.
    Еще вопрос: каким образом реализуется буфер? Движок BPM управляет заявками, а буфер организуется, например, в ERP системе? Тогда вообще не понятно как движок после выполнения заявки понимает какую именно заявку выполнили. И соответственно по какой продолжать процесс “Клиентский заказ”.

  2. Anatoly Belychook 22.02.11 18:52

    Сергей

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

    >> какой из токенов должен продолжить свой путь по приходу сообщения о доставке.

    Вообще всегда, когда один процесс шлет BPMN-сообщение в середину другого процесса (в message receive task или event), он (отправитель) должен идентифицировать конкретный экземпляр процесса (токен). Делаться это может по-разному: в простейшей реализации BPMS тупо требует указать атрибут, через которой процесс-отправитель должен отдать id процесса-получателя, в более сложной может быть что-то типа publish/subscribe, т.е. связь может осуществляться не через id процесса. Вся эта механика называется correlation. (Если сообщение шлется в start event, то корреляция не нужна.)

    Предвижу вопрос: откуда процесс-отправитель узнает id получателя? Самый простой способ - процесс “Клиентский заказ” вместе с информацией о заказе запишет в базу данных собственный id.

    >> Если смоделировать процесс так как показано на рисунке 4, то у дизайнера в BPMS системе сама по себе организуется очередь из задач.

    Вы правы, буфер образуется и в этом случае, но это будет неуправляемый буфер:
    - Клиентский отдел не будет видеть плана для уже принятых заказов и соответственно не сможет назвать клиенту обоснованный срок исполнения его заказа.
    - Дизайн не будет иметь возможность обозреть объем работы на завтра и как-то его оптимизировать. (Хотя может быть, дизайн в этом смысле не самый удачный пример - потери на старты и переналадки тут не столь очевидны.)
    - При этом дизайн все время будет виноватым: он будет срывать свои сроки, так как задачи будут ждать своей очереди непредсказуемое время.

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

    >> Еще вопрос: каким образом реализуется буфер? Движок BPM управляет заявками, а буфер организуется, например, в ERP системе?

    Варианты могут быть разные:
    1) Обычно для этого создается таблица в базе данных.
    2) Можно воспользоваться ERP, но тогда вам как-то надо будет или найти место для хранения идентификатора экземпляра процесса клиентского заказа, или искать процесс клиентского заказа по пользовательскому ключу, который есть в ERP - например по номеру заказа.
    3) В случае BizAgi BPMS все просто: в этой системе каждому экземпляру процессов автоматически ставится в соответствие запись в таблице БД, выделенной под данный процесс. Поэтому процессу “Клиентский заказ” ничего никуда специально записывать не придется - планирование дизайна просканирует эту таблицу, чтобы найти ожидающие клиентские заказы.

  3. AS 22.02.11 23:20
  4. Сергей Ладнич 23.02.11 11:59

    Анатолий, приветствую. Спасибо за ответ. Осталась одна неоднозначность.
    >> При этом дизайн все время будет виноватым: он будет срывать свои сроки, так как задачи будут ждать своей очереди непредсказуемое время.

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

  5. Anatoly Belychook 24.02.11 10:14

    Сергей

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

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

  6. Anatoly Belychook 24.02.11 14:03

    Alexander

    It looks pretty similar but here is the difference:
    - in my diagram the selection logic is embedded into the first task of collecting process
    - in EPN diagram it is located in event aggregation

    This logic isn’t trivial - I had cases where it was actually a human task: some incoming orders are accepted while others remain in the queue by some semi-formal reasons. If this is the case then your alternative #4 won’t work.

  7. Andrey 13.06.11 14:05

    А есть ли что-либо подобное применительно к разработке ПО?

  8. Anatoly Belychook 19.06.11 05:26

    Андрей

    Уточните пожалуйста вопрос.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии