Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Cross-Functional Process Optimization

This is third and last part of a study on managing cross-functional business process. Previous parts:

  1. Vulgar Interpretation of Cross-Functional Business Processes
  2. Cross-Functional Patterns

In the second part we introduced two basic ways to organize work within cross-functional business processes:

  • Synchronous - the performing unit starts work as soon as it received an internal order. Technically it’s implemented by a single process.
  • Asynchronous - orders are first accumulated in the input buffer unit of the performing unit, then extracted and processed with some frequency. Technically it’s implemented by two (when there is a single resource) or larger number of processes.

Synchronous mode grants minimal process execution time while asynchronous maximizes the performance (measured by the number of process instances completed per unit of time).

According to my observations asynchronous mode prevails in real life because departments and people both feel more comfortable when they are not chased by a continuous flow of a variety of tasks but have an opportunity to somehow organize and plan their activities.

Business and process analysts prefer synchronous schemes - not with something special in mind but because they just follow the path of least resistance: these schemes are plain simpler. This may lead to conflicts at the process implementation: people are pushed into the process framework which they feel uncomfortable.

Now if we look at it from the organization’s goals perspective (i.e. process performance) then the synchronous scheme is preferred because it provides the highest quality of customer service. A performer may not feel comfortable but it doesn’t matter on the condition that he/she isn’t overloaded (which does not happen as often as it may seem). Improving an individual’s performance may be a sub-optimization which is a bad word.

How can we bring these views together? I’m going to give some recommendation about optimal process schemes based on Goldratt’s Theory of Constraints (TOC).

1.Linear Approximation

Let’s start with the simplest case: N departments responsible for one activity each within a single business process (there is no other processes). E.g.:

Fig. 1. Resource and process performance

Just from the theory of probability resources performances would not be equal. Besides it’s sometimes impossible to align performances. For example, sales may have excessive performance because orders are accepted at distributed sales offices and you can’t place half of an employee into the office. From the other hand the design performance can’t be increased due to limited qualified labor force available.

In this example the overall process performance is determined by that of design. So this is the bottleneck, painted in red. The distinctive feature of a bottleneck: an increase in its productivity immediately results in overall productivity increase.

What’s more important, an increase of productivity of any link other than a bottleneck doesn’t affect the overall productivity.

Non-bottleneck links are painted in green except for the second from the bottom which is painted in yellow. It determines the extent to which the overall performance can be increased by improving the bottleneck performance only: from 60 to 80 in this case, i.e. by 33%.

According to Goldratt, the operations of the whole chain should be tied to the bottleneck - so-called “Drum-Buffer-Rope” method. The buffer is needed to eliminate the possibility of bottleneck downtimes and losses that they would lead to. The downtimes may happen due to variations - the performance figures are average ones so the number of client orders getting into design may increase or decrease. So it may happen that the bottleneck would be starving and the overall performance would suffer. The buffer compensates temporary lacks of input.

In accordance with TOC, buffer should be placed at the bottleneck’s input and at this place only: more buffers would not increase performance but only lead to excessive costs.

If applied to processes, the buffer corresponds to the asynchronous processing. Therefore under the given conditions - when there is just one linear process - a scheme with exactly one asynchronous link is optimal:

Fig. 2. Optimal scheme for a process with a single bottleneck

Asynchronous processing maximizes the design performance and hence the overall process performance. We don’t need to carry about other resources performance so we target them to maximum quality, keeping in mind that the end-to end process duration is a major quality indicator.

2. Constraint at the process input

The sales performance in the example above is the number of orders they are able to accept and process at a unit of time. It shouldn’t be messed it with the demand, i.e. the number of orders we may generally expect. Let’s suppose that the demand is less than the process performance:

Fig. 3. Process constrained by input

In that case the fully synchronous scheme would be optimal:

Fig. 4. Optimal scheme for a process constrained by input

It may seem absurd: why having more resources than the demand is? Yet this situation is common enough:

  • Most companies are willing to grow as long as possible i.e. as long as there is a payable demand. Accordingly, at the end of the day the demand becomes a constraint.
  • Seasons may be a factor. E.g. a beverage company may be constrained by capacity at summers (during the season) and by demand at winters.
  • Market environment is always unpredictable so it may be useful to have some spare capacity.
  • Demand isn’t something absolute - it’s affected by price and quality of our products/services .

The excessive performance equals 20% in the given example. If demand variation is within this range then the synchronous scheme should be preferred; otherwise it’d make sense to get back to the scheme depicted at fig. 2.

Unfortunately the linear models considered are too simple to use the conclusions at practice. There are at less two sources of non-linearity: restarts and readjustments.

3. The effect of restarts

The synchronous mode should be treated as such only from a process standpoint; it’s vice versa from performer’s standpoint:

  • sitting idle - no incoming orders
  • an order has come - start working, no hurry
  • a second order and yet another - where do they all come from?
  • all hands on deck, the backlog is growing
  • ok, did it, waiting for orders again

The asynchronous mode assumes by contrast that we build a plan in advance e.g. for a working shift and fulfill it steadily without hurry and/or breaks.

Similarly to a production line that gains full speed only after a while a human needs some time too to switch from being idle to productive work.

4. The effect of readjustments

It’s not that visible at the top process level but if we go down a level or two we’d discover that a performer (i.e. each of us) participates not in a single but in several process. As a rule, the higher at the hierarchy, the more processes he/she participates in.

Now imagine that you get incoming tasks from dozens of various processes. Switching between tasks requires additional efforts and extra costs similar to those that occur when a production line is readjusted from one product to another.

The less of these switches the less are costs to such “mental readjustments” and hence the more is your individual performance. The number of readjustments may be decreased by asynchronous processing.

Here is a simple example: let’s assume that two sorts of tasks get into your income queue -

  • in synchronous mode you’ll process them in the same order they arrived: A1, A2, B1, A3, B2, A4, A5, B3,…
  • in asynchronous mode the tasks will be buffered and processed in series: A1+A2+A3+A4+A5, B1+B2+B3,…

It’s always easier to perform similar tasks. May be it’s not evident for two task types but what if there were dozens? This explains why CFO probably would prefer payment requests to arrive by lists rather than one-by-one.

5. Optimization under nonlinear factors

So the synchronous mode minimizes the overall process execution time (good) yet it leads to decrease of productivity due to restarts and readjustments (bad).

As the result we may come e.g. to the following:

Fig. 5. Performance decrease due to restarts and readjustments

The result of design performance decrease is that it’s a bottleneck again: its performance is lower than the demand. The simplest way to cope with this problem is to get back to asynchronous mode, like at fig. 2. Moreover, due the decrease of manufacturing productivity it “sank” below the demand level too hence it should be switched to asynchronous mode.

However switching from synchronous to asynchronous mode is only one possible way. Toyota Production System offers another one: don’t compromise the quality (don’t increase the process duration) but cut the time spent to restarts and readjustments.

If applied to human work:

  • fight against your own inertia, accept any work without delay
  • don’t create a comfort zone by making tasks wait in a queue

Of course there is always a limit and if a particular manager or specialist is overloaded then do create such a comfort zone.

Yet it’s not the case most of the time. In order to succeed, one must take into account psychology:

  • A person in charge must understand that his individual performance doesn’t matter. The synchronous execution leads to excessive stress that could be avoided yet it’s better for a client who is the king in a proper business.
  • A human dealing with incoming tasks fast, executing them without delay as soon as they arrive must be sure that he/she won’t suffer - that the management would not decide to increase the load.

At the end of the day it depends on motivation: when a client calls to a small company nobody needs to be explained that the client is number one priority and everything else can wait. And what about a large one? “If it’s really important for you then pick up the damned phone!” However it’s beyond the scope of the article.

6. Auxiliary processes optimization

All of the above relates to the major processes directly affecting customers’ experience.

As for the auxiliary processes, the process duration isn’t that important so the efficient resource utilization becomes the major issue. Therefore the asynchronous mode must be considered as the major one.

Resources are usually utilized both in major and auxiliary processes. E.g. accounting is the major performing of the auxiliary processes of financial reporting and of employees fee calculations and payments. Besides, accounting may participate in the major sales process by creating invoices for customers. According to the principles above, the tasks within reporting and fee should be executed asynchronously while the invoicing should be done synchronously (on the condition that accounting isn’t the bottleneck which is hardly the case).

From the accounting standpoint it’d look this: financial reporting and fee calculations may be done in a steady and ordered way while invoices require immediate responses. Such arrangement may produce protests and conflicts because:

  • Within functional mindset, accounting will treat the former two process as “our own” because it’s the major performer there and hence it’ll give them more priority than invoicing which is a part of “foreign” business process.
  • The process logic is different: it requires the tasks belonging to major process to be prioritized whether they are “our own” or “foreign”.

The accounting is just an example indeed - a similar internal conflict would arise anywhere else. Once again we come to the necessity of process thinking and adequate motivation system.

02/17/11 | Articles | ,    

Comments (8)

  1. Сергей Ладнич 02/22/11 05:17 PM

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

  2. Anatoly Belychook 02/22/11 06:52 PM


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

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

    Вообще всегда, когда один процесс шлет 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 02/22/11 11:20 PM
  4. Сергей Ладнич 02/23/11 11:59 AM

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

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

  5. Anatoly Belychook 02/24/11 10:14 AM


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

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

  6. Anatoly Belychook 02/24/11 02:03 PM


    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 06/13/11 02:05 PM

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

  8. Anatoly Belychook 06/19/11 05:26 AM


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

Comments are closed

Copyright © 2008-2023 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments