Только наши заказчики являются теми судьями, которые определяют, является ли наша компания качественной.
Управление кросс-функциональными процессами
Вульгарное представление о кросс-функциональных бизнес-процессах
Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски "функций" - отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.
Собственно, это не новая идея: "сломать стены между подразделениями" - это призыв еще реинжиниринга образца начала 90-х. Другое дело, что предложенный классическим реинжинирингом подход к реализации через однократное радикальное преобразование оказался не вполне удачным. Современный BPM принес новые взгляды на то, как это надо делать, но цель осталась та же самая.
Для иллюстрации кросс-функциональных проблем часто используют метафору силосной башни -"functional silo". Аналогия тут следующая: после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства - до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений - большая часть этого богатства недоступна для потребителей из других подразделений и не работает на достижения целей компании в целом.
Чисто функциональный взгляд на вещи влечет за собой искаженное представление о том, что для того или иного подразделения "свое", а что "чужое". Так, например, для бухгалтерии естественно считать, что основное ее занятие - это учет и отчетность. А выставление счетов за поставленный товар нужно кому-то другому, например, отделу продаж; для бухгалтерии это досадная помеха ее основной деятельности. Но с точки зрения бизнеса ведь все наоборот: выставление счета - это часть важнейшего с точки зрения ценности для клиента процесса "от заказа до оплаты", а учет и отчетность - это вспомогательная деятельность. Необходимая, так как ее требует государство и она нужна для планирования собственной деятельности. Но все же она не создает ценность, а следовательно, это затраты, которые по возможности следует минимизировать.
Бухгалтерия - это только один пример. Разработка новой продукции, подготовка коммерческого предложения, выполнение клиентского заказа "от и до" -- в компании есть множество вещей критически важных для клиента, а следовательно для бизнеса, но про которые нельзя сказать, что за них отвечает какая-то одна служба.
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 1. Функции и кросс-функциональные процессы.
Однако картинка типа приведенной выше создает совершенно ложное представление о том, как следует решать проблемы, возникающие на стыках между подразделениями. Она порождает вульгарное представление о бизнес-процессе как о простой последовательности шагов: "делай раз - делай два - делай три". Но бизнес так не работает.
Рассмотрим в качестве примера - процесс "от заказа до оплаты": приняли заказ - произвели - отгрузили - произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке на рис. 1:
Процесс начинается, когда отдел продаж получает заказ клиента.
Получив и оформив заказ, отдел продаж передает его в производство.
Производство приступает к выполнению заказа.
Изготовленный товар доставляется заказчику.
Финансовый отдел производит расчеты.
Рис. 2. Кросс-функциональный процесс "от заказа до оплаты", workflow-версия.
Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.
Более правдоподобной выглядит следующая схема:
Отдел продаж оформляет заказ клиента и размещает его в производстве.
С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.
В графическом виде:
Рис. 3. Кросс-функциональный процесс "от заказа до оплаты", BPM-версия.
У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов "клиентский заказ" и "производство" разные триггеры: поступление заказа от клиента и таймер, соответственно.
Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса "клиентский заказ". То есть технически процессов (пулов) тут не два, а больше.
Workflow, BPM и многопоточное программирование
Кросс-функциональные процессы невозможно реализовать при помощи workflow, потому что границы между подразделениями существуют не просто так: они разделяют области с разными распорядками работы и разными ритмами. Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2.
Технически эти задачи решаются при помощи процессных паттернов, один из которых изображен на рис. 3. А на уровне методологическом картинка, изображенная на рис. 1, может выглядеть так:
Рис. 4. Кросс-функциональный процесс как координатор функций.
Workflow работает только в пределах одной функции. Как только мы выходим за ее пределы, т.е. как только беремся за кросс-функциональные процессы и начинаем разбираться со стыками между подразделениями, необходимо задействовать более изощренные механизмы взаимодействия между workflow.
Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию.
К сожалению, для многих это становится непреодолимым барьером.
Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа "Оформление заявление на отпуск". Пилот получается успешный, только какое он имеет отношение к бизнесу?
Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.
Технически, многопоточность - это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а "workflow на стероидах".
К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS - это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным - графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой - лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия - единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.
Но сказать "осваивайте многопоточное программирование процессов" легче, чем последовать этому совету. В ответ раздается стон: "какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!".
Сложен не BPMN - сложен бизнес!
Кто бы вам не обещал простые средства решения бизнес-проблем, будь то BPM или что-то другое - не верьте! Бизнес - это конкурентная область человеческой деятельности: талантливые и изощренные люди соревнуются в ней за то, кому будет житься хорошо, а кому - не очень. Поэтому бизнес был, есть и останется делом сложным.
Сложность BPMN не чрезмерна - она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x - стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.
Если бизнес и можно запрограммировать, то только как многопоточную систему.
BPM и ACM
Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): "Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!"
Может быть можно, может быть нельзя: Скорее всего, в каких-то случаях можно, а в каких-то нет.
Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса - это ведь самая подходящая для BPM задача.
В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?
Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.
Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.
Кросс-функциональные паттерны
Воспользуемся следующим примером:
В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.
В простейшем виде процессная диаграмма может выглядеть так:
Рис. 5. Синхронный процесс
В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.
1. Планирование единственного ресурса
В данном случае нас интересует другой аспект: предположим, что компания ограничена в оборотных средствах. И возможна ситуация, когда счета, не оспариваемые ни по сумме, ни по срокам, тем не менее не могут быть оплачены вовремя, и компания принимает решение о задержке платежа - вынужденно или пользуясь терпением кредитора.
Принципиальный момент: невозможно квалифицированно принять такое решения по одному отдельно взятому счету. Разумный алгоритм действий лица, принимающего решение, следующий: собрать все счета к оплате за период (скажем, на сегодня или на наступающую неделю), проанализировать общую ситуацию - сколько у нас средств и сколько предъявлено счетов - и в зависимости от ситуации принять решение: какие счета оплачивать, а с какими повременить.
Схема процесса для такого алгоритма действий:
Рис. 6. Планирование ресурса
Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:
После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: "оплатить", "отказать", "отложить".
После того, как он это сделал и нажал кнопку "Готово", экземплярам процесса процесса обработки счетов, для которых выбрано "оплатить" или "отказать", автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано "отложить", остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.
Процессные диаграммы, похожие изображенную на рис.6, регулярно встречаются на практике. Если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.
Алексадр Самарин называет его "CPP - Collect and Periodically Process".
Мне больше нравится название "Планирование ресурса".
Еще вариант: "Буфер заказов".
В принципе, несколько названий для одного паттерна - это не только не плохо, а наоборот, очень хорошо: чем больше названий, тем с большим количеством "картинок" окружающего мира он у нас ассоциируется, тем шире мы его применяем.
Некоторые используют также термин "Групповая обработка", но мне он не нравится: слишком общо, может означать все что угодно.
2. Оптимистичное планирование
Какая из диаграмм на рис. 1 и 2 лучше? Правильнее? Однозначного ответа нет - зависит от того, что для нас является приоритетом:
если приоритет - скорость обработки (обработки счета в данном случае), то предпочтительна схема 1
если приоритет - эффективное использование ресурса, то предпочтительна схема 2
Вообще, вопрос "или-или" не стоит - можно ведь реализовать и комбинированную схему:
Рис. 7. Оптимистичное планирование
В данной схеме каждый счет рассматривается дважды: сначала синхронно, в рамках процесса обработки счета, затем - если необходимо - в рамках планирования ресурсов.
Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.
Эту схему целесообразно использовать тогда, когда ресурса достаточно "почти всегда". Ее преимущество, с одной стороны, в том, что счета одобряются без задержки, а с другой - если средств на оплату всех счетов не хватает, то остается возможность в последний момент отменить оплату каких-то счетов.
Получив предварительное одобрение, процесс обработки счета может совершить какие-то действия (на схеме не показаны) - например, уведомить поставщика о том, что счет направлен в оплату.
Соответственно, надо предусмотреть обработку исключительной ситуации: если в итоге оплата счета была отменена, то нужно сообщить об этом поставщику.
3. Планирование нескольких ресурсов
Другое направление развития диаграммы - обобщение на случай нескольких ресурсов. Например, компания может производить оплату из денежных средств, размещенных в разных банках.
Рис. 8. Планирование нескольких ресурсов
В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).
Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
После того, как решение по всем счетам принято, процесс планирования формирует ведомость для каждого банка и для каждой запускает процесс оплаты - уже не отдельного счета, а всех счетов по указанному банку на указанную дату.
Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.
Для оплаты счетов это выглядит несколько искусственно, но представьте себе планирование нескольких производственных линий. На выходе процесса планирования - сменное задание для каждой линии, включающее последовательность выполнения поступивших заказов. Естественно трактовать выполнение сменного задания как отдельный процесс. Процесс планирования запускает процесс выполнения сменного задания для каждой линии и на этом заканчивает свою работу. Причем если с понедельника по четверг составляются задания на следующий день, то в пятницу планируется производство в субботу, воскресенье и понедельник.
Вообще, рассмотренный пример - это не кросс-функциональный процесс в полном смысле слова: ведь и финансовый отдел, и финансовый директор - это, в принципе, одно и то же подразделение. Но суть не в этом, а в том, что мы имеем дело с процессом, использующим некоторый ограниченный ресурс - в данном случае финансовый.
Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.
С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.
Оптимизация кросс-функциональных процессов
Два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:
Синхронный - подразделение-исполнитель приступает к работе сразу, как только поступил заказ из подразделения-заказчика. Технически реализуется одним процессом.
Асинхронный - заказы накапливаются во входном буфере подразделения-исполнителя, затем с некоторой периодичностью извлекаются оттуда и обрабатываются. Технически может реализовываться двумя (в случае планирования единственного ресурса) или большим числом процессов.
Синхронная работа обеспечивает минимальное время прохождения процесса, асинхронная - максимальную производительность подразделения-исполнителя (Под производительностью будем понимать максимальное число экземпляров процесса, завершенных в единицу времени.)
По моим наблюдениям, в жизни чаще реализуется асинхронные режим, потому что и подразделения, и отдельные люди чувствуют себя более комфортно, когда их не "дергают" непрерывным потоком разнообразных заданий, а дают возможность как-то упорядочить и спланировать свою деятельность.
Бизнес - и процессные аналитики чаще рисуют синхронные схемы - не из каких-то особо хитрых соображений, а просто идя по пути наименьшего сопротивления: такие схемы банально проще. И в этом зародыш конфликтов, возникающих при внедрении процессного управления: людей втискивают в рамки процессов, в которых они чувствуют себя некомфортно.
Если же посмотреть с точки зрения интересов организации, т.е. показателей процесса в целом, то синхронная схема предпочтительна, так как обеспечивает максимальное качество обслуживания клиентов. А что исполнитель чувствует себя не комфортно, так это не главное - при условии, что он не перегружен (что в действительности случается не так часто, как может показаться). Повышать его индивидуальную производительность значит заниматься субоптимизацией, а это слово ругательное.
Как же примирить эти точки зрения? Попробуем дать рекомендации по выбору оптимальной схемы работы, опираясь на Теорию ограничений Голдратта.
1. Линейная система
Начнем с простейшей постановки задачи: N подразделений выполняет каждое по одной из N задач (или подпроцессов) в рамках единственного бизнес-процесса (других процессов нет). Пример:
Рис. 9. Производительность ресурсов и производительность процесса
Просто по теории вероятности, производительности подразделений не будут в точности совпадать. Кроме того, выровнять производительность зачастую невозможно технологически. Скажем, прием заказов обладает запасом по производительности, так как заказы принимаются в распределенных офисах продаж, а половину человека в офис не посадишь. А с другой стороны, производительность дизайнерского отдела не удается повысить из-за нехватки квалифицированной рабочей силы.
В данном примере производительность процесса в целом определяется производительностью участка дизайна. Это "бутылочное горлышко", его производительность мы изобразили красным столбиком. Отличительная особенность "бутылочного горлышка" - увеличение его производительности немедленно отражается на производительности всей цепочки.
Что более существенно, увеличение производительности любого звена, не являющегося "бутылочным горлышком", никак не отразится на производительности цепочки.
Звенья, не являющиеся "бутылочным горлышком", изображены зеленым цветом, за исключением второго с конца по производительности звена - в данном примере это производственный участок, его мы покрасили желтым. Он определяет, на сколько можно повысить производительность процесса только за счет увеличения производительности "бутылочного горлышка": в данном примере с 60 до 80, т.е. на 33%.
По Голдратту, ритм и порядок работы всех звеньев следует привязать к "бутылочному горлышку" - т.н. метод "барабан-веревка-буфер". Буфер нужен для того, чтобы исключить возможность потерь из-за простоя "бутылочного горлышка". Простои могут возникать из-за стохастического разброса - ведь приведенные цифры производительности являются усредненными, и на вход участка дизайна может поступать то больше, то меньше клиентских заказов. Соответственно, может возникнуть ситуация, когда "бутылочное горлышко" окажется на голодном пайке, и в результате снизится производительность всей цепочки. Чтобы это исключить, нужен буфер - он будет компенсировать временную нехватку на входе.
Согласно Теории ограничений, буфер следует организовать перед "бутылочным горлышком", но только в этом единственном месте: дополнительные буфера не повысят производительность, а только приведут к лишним затратам.
Применительно к процессам, буфер соответствует асинхронной обработке. Таким образом, в рассмотренной постановке - когда есть только один процесс, протекающий линейно - оптимальной будет схема ровно с одним асинхронным участком:
Рис. 10. Оптимальная схема для процесса с одним "бутылочным горлышком"
Асинхронная обработка на этапе дизайна максимизирует его производительность и тем самым - производительность процесса в целом. О производительности остальных участков можно не заботиться, поэтому их работу мы организуем так, чтобы максимизировать качество - ведь время прохождения процесса от начала до конца есть один из главных показателей его качества.
2. Ограничение на входе системы
В рассмотренном выше примере производительность участка приема заказов есть число заказов, которые он способен принять и обработать в единицу времени. Не следует путать этот показатель с потенциальным спросом, т.е. числом заказов, на которое мы в принципе можем рассчитывать. Предположим, что спрос меньше, чем производительность нашего процесса:
Рис. 11. Процесс, ограниченный по входу
В этом случае оптимальной будет полностью синхронная схема:
Рис. 12. Оптимальная схема для процесса, ограниченного по входу
Ситуация может показаться абсурдной: зачем держать ресурсы, превышающие имеющийся спрос? Тем не менее, такая ситуация встречается достаточно часто:
Большинство компаний стремятся расти до тех пор, пока есть возможность - т.е. пока есть платежеспособный спрос. Соответственно, в конце концов они приходят к тому, что спрос становится главным ограничителем.
Может сказываться сезонность. Скажем, компания, выпускающая прохладительные напитки,
может быть ограничена производственными мощностями летом (в сезон) и объемом спроса - зимой.
Конъюнктура всегда отчасти непредсказуема, и поэтому полезно иметь некоторый запас производительности.
Спрос не является чем-то абсолютным: на него влияют в том числе цена и качество наших продукции и услуг.
В рассматриваемом примере запас производительности процесса относительно спроса составляет 20%. Если спрос колеблется в этих пределах, то синхронная схема будет предпочтительной; если больше, то есть смысл вернуться к схеме на рис. 12.
К сожалению, рассмотренные линейные модели слишком просты, чтобы полученные выводы можно было непосредственно использовать на практике. В жизни есть как минимум два источника нелинейностей: старты и переналадки.
3. Влияние стартов
Синхронный режим работы является таковым с точки зрения процесса, а с точки зрения исполнителя (ресурса) вовсе наоборот:
сидим, курим, заказов нет
пришел заказ- работаем, особо не спешим
второй заказ, третий- откуда их столько?
аврал, не справляемся, выполнение заказов задерживается
уф, справились, снова курим
И наоборот, асинхронный режим предполагает, что мы заранее составляем план работы, скажем, на рабочую смену, и спокойно, ритмично, рассчитывая свои силы, без авралов и перекуров, его выполняем.
Аналогично тому, как производственная линия выходит на рабочий режим не сразу, а через некоторое время, человеку тоже нужно время, чтобы перейти от простоя к производительной работе.
4. Влияние переналадок
На уровне процессов верхнего уровня это не так заметно, но если мы спустимся на один-два уровня ниже, то обнаружим, что исполнитель (т.е. каждый из нас) задействован не в одном, а в нескольких процессах. Причем как правило, чем выше человек поднимается по служебной лестнице, тем большее число процессов требует его участия.
Теперь представьте, что вам во входящие непрерывно поступают задания от десятка разнообразных процессов. Переключение между задачами сопряжено с усилиями и дополнительными затратами, аналогичным тем, которые возникают при переналадке универсальной производственной линии с выпуска одной продукции на другую.
Чем меньше таких переключений, тем меньше затраты на "умственную переналадку" и следовательно, тем выше ваша индивидуальная производительность. Уменьшить число переналадок можно за счет асинхронной обработки.
Проиллюстрируем это простейшим примером: пусть вам на вход поступают задачи двух видов: А и Б -
при синхронном режиме исполнения процессов вы будете их обрабатывать в той последовательности, в которой они к вам поступили: А1, А2, Б1, А3, Б2, А4, А5, Б3,:
при асинхронном режиме исполнения процессов задания будут накапливаться в буфере и обрабатываться сериями: А1+А2+А3+А4+А5, Б1+Б2+Б3,:
Выполнять однотипные задачи всегда легче. Может быть для двух типов задач это не так очевидно, но что если их десятки? Это объясняет, почему финансовый директор скорее всего предпочтет, чтобы заявки на оплату поступали к нему не по одному, а списком.
5. Рекомендации по оптимизации с учетом нелинейных факторов
Итак, в синхронном режиме время исполнения процесса минимально (хорошо), но этот режим сопряжен со снижением производительности из-за стартов и переналадок (плохо).
В результате мы можем получить, например, такую картину:
Рис. 13. Снижение производительности из-за стартов и переналадок
Снижение производительности на участке дизайна привело к тому, что он стал узким местом - его производительность стала ниже уровня спроса. Простейший способ справиться с этой проблемой - вернуться к асинхронной схеме работы, изображенной на рис. 12. Мало того, из-за снижения производительности на участке производства он тоже "провалился" ниже уровня спроса - следовательно, его тоже надо перевести на асинхронный режим.
Но переход от синхронного режиму к асинхронному - только один из возможных вариантов действий. Другой предлагает система Тойоты: не компрометировать качество (не увеличивать продолжительность процесса), а сокращать время, затрачиваемое на старты и переналадки.
То есть, применительно к работе, выполняемой людьми:
бороться с собственной инерцией, браться за любую работу сразу и не раскачиваясь
не создавать себе комфортную зону, давая задачам "вылеживаться" во входящих
Конечно, всему есть предел, и если тот или иной руководитель или специалист реально перегружен, то ему как раз надо создать такую комфортную зону.
Однако в большинстве случаев это не так. Но тут, чтобы добиться успехов, необходимо учитывать психологические факторы:
У исполнителя должно быть понимание, что его личная производительность не имеет значения. Синхронное исполнение процессов создает для него лично дополнительное напряжение, которого при иной организации работы можно было бы избежать, но это делается не для того, чтобы над ним поиздеваться, а потому, что так лучше для клиента, который царь и бог в правильно организованном бизнесе.
Если человек быстро справляется с поступающими задачами, без задержки выполняя их в том темпе, в котором они к нему приходят, то он должен быть уверен, что он из-за этого не пострадает- что начальство не решит, что он мало работает.
В конечном итоге, все зависит от мотивации: когда в маленькую компанию звонит клиент, то никому не надо объяснять, что клиент - это главное, а все остальные дела могут подождать. А в большой компании? "Если мой звонок так важен для вас, то черт возьми, возьмите наконец трубку!" Но эта тема уже выходит за рамки данной статьи.
6. Оптимизация вспомогательных процессов
Все сказанное выше относилось к основным процессам, качество и производительность которых непосредственно отражается на клиентах.
Что касается вспомогательных процессов, то там время исполнения не столь важно, и на первый план выходит экономное расходование ресурсов. Поэтому для вспомогательных процессов асинхронный режим исполнения следует считать основным.
Если посмотреть в разрезе ресурсов, то они, как правило, задействованы и в основных, и во вспомогательных процессах. Например, бухгалтерия является основным исполнителем во вспомогательных процессах сдачи баланса и расчетов с персоналом, а кроме того, бухгалтерия готовит счета покупателям в рамках основного процесса продажи. В соответствии с изложенными выше принципами, задачи в рамках сдачи баланса и расчетов с персоналом должны выполняться в асинхронном режиме, а выписка счета - синхронно (при условии, что бухгалтерия объективно не является "бутылочным горлышком", что маловероятно).
С точки зрения бухгалтерии это будет выглядеть так: балансовая отчетность и расчеты с персоналом ведутся в размеренном ритме, а счета готовятся в режиме немедленного реагирования. Такая организация легко может вызвать протесты и конфликты, так как:
в рамках функционального мышления первые два процесса бухгалтерия будет считать "своими", так как является в них основным исполнителем, и соответственно, будет уделять им внимания больше, чем выписке счетов в рамках "чужого" бизнес-процесса
в процессной же логике дело обстоит иначе: она требует, чтобы к задачам в рамках основных процессов относились как к приоритетным вне зависимости от того, "свой" это процесс или "чужой"
Понятно, что бухгалтерия здесь взята просто для примера - аналогичный внутренний конфликт будет возникать в любом подразделении. Опять-таки, здесь мы приходим к необходимости культивации процессного мышления и адекватной мотивации.
Также на сайте:
Практический опыт внедрения и сертификации Системы Менеджмента Качества (СМК) по требованиям ISO 9001:2000
Причины трудностей при внедрении системы менеджмента качества и как их решать
О проекте
quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.
Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.
Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.