Еще один кусочек учебника по бизнес-программированию.

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

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

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

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

Про устную передачу задач и говорить не стоит. Как говорится, в одно ухо влетело, в другое – вылетело.

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

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

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

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

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

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

Критерий простой: если вы, не спрашивая сотрудника, можете сказать по каждой конкретной задаче, что нужно сделать, то очередь декомпозирована правильно. Если ответом будет «надо разбираться», или «надо как-то исправить», или «еще не смотрел», то декомпозиция выполнена скверно. Система, и процесс, продолжают зависеть от сотрудника.

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

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

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

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

Итак, критерий простой: если вы видите у каждой задачи время нахождения в очереди, то требование выполнено. Типичной ошибкой является мнение, что достаточно знать и видеть дату постановки задачи, ведь в этом случае время нахождения в очереди легко можно вычислить. Средствами автоматизации это сделать, действительно, легко. Но вычислять в уме – намного сложнее, и ни один здравомыслящий сотрудник этого делать не будет. Поэтому, время нахождения в очереди не будет учитываться в работе.

Пятое требование – как ни банально, но должен быть известен исполнитель задачи. Если выбор исполнителя регулируется автоматизированным алгоритмом, то должен быть понятен момент, когда этот алгоритм выполняется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Способ рисования «железобетонных» процессов можно использовать, как вспомогательный, большого вреда не будет. Либо, его можно применить в конце проекта, как способ консервации настроенных процессов. До следующего проекта.

Однако, не забывайте о третьем пункте – склонности к бюрократизации. Если вам кажется, что вы консервируете систему на время, то у остальных сотрудников и руководителей мнение противоположное: не трогай то, что работает. Созданная, отлаженная и внедренная вами система начнет вам же и сопротивляться.

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

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

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

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

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

Ретроспективный анализ очередей – еще менее распространенное явление, потому что большинство систем вообще не содержит необходимых данных. Такие данные доступны только в случае полного использования принципа «Айсберг», когда хранится не только мгновенное время состояния, но и его история.

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