Автоматизация контроля границ

08.08.18

Архитектура

Продолжаем изучение учебника по бизнес-программированию. На этот раз - параграф из раздела "Автоматизация".

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

В данной публикации - сводка по методам решения.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    4068    0    comol    28    

28

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3512    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2212    0    slavik27    7    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    2938    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5658    0    ivanov660    10    

35

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2982    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3542    0    ke_almaty    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. yogaga 08.08.18 13:07 Сейчас в теме
Местами несколько заумно, но в целом статья полезна.
Не совсем понятна необходимость ретроспективного анализа для текущей оперативной деятельности, можете пояснить?
2. 1c-intelligence 12851 08.08.18 13:15 Сейчас в теме
(1)
Местами несколько заумно

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

это не для текущей оперативной деятельности. Об этом будет отдельный параграф.
3. yogaga 08.08.18 13:24 Сейчас в теме
На практике наибольшую сложность вызывают процессы, предполагающие несколько итераций, и требующие параллельной работы нескольких исполнителей, например, согласование договора, когда каждый согласующий смотрит свою часть, и в случае разногласий с контрагентом могут быть повторные итерации. Как тут лучше всего организовать контроль и оценку процессов?
8. 1c-intelligence 12851 09.08.18 07:37 Сейчас в теме
(3) ваш вопрос затрагивает несколько параграфов учебника, которые еще не опубликованы. С вашего позволения, не буду давать спойлеров.
9. yogaga 09.08.18 08:27 Сейчас в теме
(8) Ну так не интересно, по частям отлавливать ответы на конкретный вопрос...
10. 1c-intelligence 12851 09.08.18 08:29 Сейчас в теме
(9) ну, у меня варианта два: или на вопросы отвечать, или новые материалы писать.
11. yogaga 09.08.18 10:00 Сейчас в теме
(10) Любой учебник без рассмотрения практических задач бесполезен.
12. 1c-intelligence 12851 09.08.18 10:07 Сейчас в теме
(11) да, согласен. Но, мне кажется, полезнее и эффективнее рассматривать практические задачи в учебнике, а не в комментах. Тогда все почитают.
4. pm74 203 08.08.18 14:38 Сейчас в теме
Время нахождения в очереди -мысль хорошая нужно будет это использовать
6. 1c-intelligence 12851 09.08.18 07:32 Сейчас в теме
(4) на эту тему еще будет информация, здесь лишь вскользь упомянуто.
5. acanta 08.08.18 14:43 Сейчас в теме
Вы ничего не путаете с процессом принятия решения?
7. 1c-intelligence 12851 09.08.18 07:36 Сейчас в теме
(5) принятие решения - это не процесс, а действие. Ровно такое же, как обработка детали на фрезерном станке, или создание отчета о прибылях и убытках. К нему применимы те же метрики, что и к остальным действиям.

Трудность в том, что "принятие решения" считается чем-то вроде таинства. Такой миф искусственно создан и поддерживается менеджерами. Иначе их разогнать придется.

Программный код, когда исполняется, постоянно решения принимает. Помните, типа

Если КоличествоИтераций > 1000 Тогда
Прервать;
КонецЕсли;

И никакого таинства. Идет процесс, дошел до точки принятия решения, исполнил это действие, и пошел дальше.
13. acanta 09.08.18 10:48 Сейчас в теме
(7)
действие

Именно, принятие решения это процесс с определенным количеством итераций и порогом выхода. "Нельзя просто так взять и уволить(ся)/перейти на другую систему учета".
Порог выхода, это сумма/количество опыта/навыки/объем работы который человек/команда заработал/приобрел/выполнил на данном рабочем месте. Но каждый рабочий день это процесс принятия решения уйти. Как и каждый бизнес-процесс это набор действий для передачи результата в другую зону ответственности.
Никакого таинства нет, это факт выполнения определенного плана, о котором зачастую известно. А вот вмешательство в этот процесс с целью увеличить/уменьшить количество итераций в цикле или изменить порог выхода - это нарушение границ. Не говоря уже об изменении этого плана.
14. genayo 09.08.18 10:56 Сейчас в теме
(13) И вот вопрос - а что делать, когда понимаешь, что решение это на самом деле не твоё...
15. acanta 09.08.18 11:00 Сейчас в теме
(14) Определить порог выхода и количество итераций лица принимающего решение.
16. genayo 09.08.18 11:37 Сейчас в теме
(15) Решение принимаешь ты, но в итоге оказывается, что на самом деле, никакого выбора решения у тебя не было. Я вот про что.
17. acanta 09.08.18 11:45 Сейчас в теме
Выбор есть всегда. Но мы изучаем ответы на тесты для экзамена 1С-Профессионал. И проблема в том, что решение всегда находится вне множества "правильных ответов".
18. mcgoblin 3 09.08.18 15:36 Сейчас в теме
Было бы не плохо добавить ссылки на прошлые статьи из этого цикла.
Оставьте свое сообщение