Почему ОТМ? Часть 6 — Автоматизационная

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

Нельзя забывать, что при всей гибкости, ОТМ все же является готовым приложением, которое позволяет некоторые вариации процессов, но строго в определенных рамках. С уверенностью могу сказать, что именно эти рамки и помогают не расставаться со здравым смыслом в процессе внедрения. Любая система является попыткой построить модель мира, но ни одна система не может вместить все разнообразие, с которым мы сталкиваемся в реальной жизни, поэтому мы должны принимать разумные упрощения и ограничения. С этим фактом нужно смириться чем раньше, тем лучше. Более того, нужно радоваться, что ограничения уже придуманы и не приходится принимать эти решения самостоятельно — можно положиться на авторитетную систему и иногда с облегчением сказать — «если этого нет в ОТМ, то значит это по большому счету и не нужно». К тому же часто возникает соблазн нагрузить систему различными «полезными» дополнительными, но несвойственными ей функциями. Справиться с соблазном опять же помогут разумные ограничения системы. Всем известно, что многофункциональные устройства всегда хуже справляются с каждой отдельной функцией, чем специализированные под конкретные задачи.

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

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

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

Параметры.

Правила.

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

Проверки.

С помощью проверок ОТМ может в том числе взаимодействовать с пользователем. Как правило именно эта возможность вызывает наиболее живой интерес. На каждом проекте внедрения ОТМ, где мне приходилось работать, рано или поздно вставал вопрос о создании отчета, который можно было бы условно назвать «Что не так?!» или «Почему опять не планируется?». Дело в том, что ОТМ система очень интеллектуальная, но при этом очень закрытая и если что-то идет не так, то разобраться что же именно не так крайне непросто, буквально приходится устраивать целое расследование с многоходовыми проверками и чтением не самых дружественных логов. Впрочем оно и понятно — если все настроено как следует и мастер данные внесены, то все работает само собой и заглядывать, а тем более вмешиваться в разнообразные сложные внутренние процессы планирования и оптимизации нет ни смысла, ни желания. Нельзя сказать, что механизм проверок может справиться со всеми возможными проблемами планирования, но точно может помочь исключить самые элементарные ошибки, а еще напомнит пользователю об обязательных к заполнению полях, последовательности действий, смены статусов. Суть проверки — это запрос на PL/SQL. В случае, если он выполняется при определенном действии пользователя и возвращает «положительный» ответ, то это значит проверка пройдена и можно двигаться дальше, а если нет, то это значит условие не выполнено, проверка не пройдена и пользователь увидит на экране заданный текст предупреждения, который должен подсказать что не так и помочь исправить ошибку.

Автоматические агенты.

Строго говоря это основной инструмент для создания самостоятельной логики, которая не заложена в базовые процессы системы. Агенты сочетают в себе все более простые элементы автоматизации, о которых говорилось выше. Но основа агентов — это элементарные действия с конкретным конечным результатом, например, установка статуса, планирование перевозки по заказу, перерасчет стоимости перевозки, постановка на ворота склада. На каждое из таких действий заранее запрограммирован определенный алгоритм. Комбинируя предопределенные действия и используя различные логические действия и проверки мы получаем уже свой более сложный алгоритм. Разумеется всего предусмотреть невозможно, поэтому среди предопределенных действий есть одно, которое позволяет включить в агент совершенно произвольное выражение на PL/SQL. Также есть возможность создавать логические выражения, похожие на проверки, которые описаны выше. Так что свобода творчества обеспечена.

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

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