Операционная логика бизнес-процессов. human

Операционная логика бизнес-процессов. human-assisted systems
Яковлев Г.Г., инженер отдела ИТО ЦНИТ ТГУ
Мы в отделе сейчас занимаемся, в том числе, автоматизацией процессов в разрабатываемом
модуле "Электронная библиотека", поэтому примеры я буду приводить из этой области.
Определение: бизнес-процесс (БП) это процесс целенаправленного изменения некоторых
объектов. То есть, это всякая деятельность над объектами, подразумевающая некоторое
желаемое конечное состояние этих объектов (операционную цель). Например, БП является
публикация электронного издания в электронной библиотеке. При этом может понадобиться
создать (зарегистрировать) новые ключевые слова. Совокупное состояние всех объектов,
которые используются БП, будем называть состоянием БП. ОЦ может быть не одна, важно, что
такие (целевые) состояния БП есть.
Две плоскости абстракции в управлении БП
Управление БП можно рассматривать в двух плоскостях. Во-первых, это продвижение одного,
конкретного процесса, например, публикации одного, конкретного электронного издания. Вовторых, это управление протеканием совокупности процессов в целом, то есть принятие таких
решений, как решение о выделении ставки для еще одного корректора.
В первом случае, мы должны отвлечься, например, от проблем распределения задач между
исполнителями, то есть, допустим, от того, какой именно библиотекарь будет заниматься
приданием изданию официального статуса, а сосредоточиться на том, какие именно задачи и в
каком порядке надо выполнить, чтобы процесс был благополучно завершен. Так получается
операционная логика БП. В дальнейшем я буду говорить именно о ней.
Во втором случае, надо отвлечься от протекания конкретного БП, а сосредоточиться на том, как
расставить задачам по продвижению процессов приоритеты, как распределить нагрузку между
сотрудниками, как проследить степень задействованности сотрудника в выполнении своих
обязанностей и т.п. Так получается оптимизационная логика БП.
Движение БП
Посмотрим, что же необходимо для того, чтобы можно было двигать БП к операционной цели
(ОЦ)? Во-первых, нужна некоторая мера близости БП к ОЦ. Без этого мы не можем знать, как
изменить объекты, чтобы БП к ОЦ приблизить. Во-вторых, при любом состоянии БП должно
быть возможно совершение хотя бы одного действия над объектами, которое либо приблизит
процесс к ОЦ, либо завершит (отменит) процесс. Иначе, существовали бы состояния БП, при
которых он бы "зависал", то есть, было бы нельзя его ни продвинуть, ни отменить. И в третьих,
необходимо нечто, что бы обеспечивало планирование и выполнение таких действий (или
некто).
В дальнейшем, будем рассматривать только такие действия, которые приближают БП к ОЦ
(назовем их технологическими операциями - ТО). Другие действия не приближают БП к ОЦ,
поэтому с точки зрения операционной логики бессмысленны. Так вот, ТО не могут быть
произвольным изменением объектов,-- чтобы приблизить БП к ОЦ, они должны приводить к
соблюдению какого-то правила.
Выполнение ТО, вообще говоря, допустимо не в любом состоянии. Может требоваться
предварительное выполнение других ТО. Например, невыгодно начинать корректуру
электронного издания до того, как будет решено, будет ли это издание претендовать на
официальный статус.
Состояния БП, при которых допустимы одинаковые наборы ТО, идентичны с точки зрения
операционной логики. Очевидно, ТО может быть описано только конечное число, поэтому и
количество состояний БП конечно. Топологией БП назовем граф, состоящий из состояний БП и
возможных переходов (посредством ТО) между ними.
Крайние случаи топологии БП
Два крайних случая топологии БП - последовательная и параллельная. В первом случае, ТО
должны производиться строго упорядоченно, то есть, в каждый конкретный момент можно
произвести только одну ТО, и, как только ее произвели, появляется возможность произвести
следующую. Во втором -- надо произвести некоторое количество известных ТО в произвольном
порядке. Реальные процессы обладают смешанной топологией. Кроме того, реальные процессы
допускают переходы на более удаленное от ОЦ (предшествующее) состояние в силу ошибки
исполнителя, либо по независящим от исполнителей обстоятельствам.
Крайние случаи операционной логики БП
Есть также два крайних случая операционной логики БП - управление проектами и управление
функциями.
В первом случае, все действия, контрольные точки, сроки определяются еще до того, как
процесс начинается. Кроме того, существует менеджер проекта, который следит за
выполнением работ по проекту. Такой подход хорош для сложных БП (с большим количеством
состояний и ветвлений), при условии, что в каждый конкретный момент этих процессов
немного. Однако при уменьшении сложности БП и при увеличении количества работающих
процессов, увеличиваются затраты на менеджмент, включая и время планирования каждого
такого процесса.
Во-втором случае (функциональное управление),-- каждый исполнитель знает, как он должен
реагировать на какое событие (пришел счет, пришел клиент и сделал заказ и т.п.). Это менее
затратный подход, ибо позволяет обходиться без управления каждым процессом. Однако, при
возникновении непредвиденных обстоятельств, некому будет на них отреагировать.
Существуют процессы, идеально подходящие под каждую из этих крайностей. Однако, для
большинства процессов стоит найти комбинацию из этих крайностей, которая будет работать
эффективнее, чем любая из этих крайностей по-отдельности.
human-assisted systems или автоматизация операционного управления БП
Как только нам удалось полностью описать топологию процесса, заботу о планировании ТО
можно свалить на компьютер, оставив управленцам логику управления всей совокупностью БП.
Таким образом объединяются оба подхода к операционному управлению БП (проектный и
функциональный), и система, которая раньше помогала человеку (human-assisting system),
например, создавать и хранить документы, превращается в систему, которая пользуется
помощью человека (human-assisted) там, где без него обойтись не может.
При топологии БП близкой к параллельной, количество состояний БП растет, как 2n с ростом
количества ТО. Поэтому описать топологию БП, описывая все состояния БП, может оказаться
затруднительно. В этом случае более удобным и естественным описанием топологии БП будет
задание каждой ТО некоторой булевой функции допустимости этой ТО в зависимости от
состояния объектов БП. То есть, кроме булевой функции -- соблюдено ли правило, появляется
еще одна булева функция -- допустимо ли выполнение операции.