Синхронность и асинхронность процессов

    Мир может многому научиться у программистов. Он и так учится, только не тому и не так. Например, взял процессы и алгоритмы, но не заметил такого подхода, как асинхронность.

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

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

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

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

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

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

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

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

    Конечно, юристы могут возмутиться – чего это мы будем оценивать поставщика, если вы там еще четко не решили, будете ли у него заказывать? Что им ответить?

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

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

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

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

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

    Типичный пример: «я буду согласовывать только после того, как согласует вот он». Или «я посмотрю на этот договор только после финансистов». Хотя, если верить статистике и здравому смыслу, подобные постановки не имеют под собой оснований, и являются лишь способом переложить ответственность.

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

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

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

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

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

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

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

    Комментарии 10

      +2
      Вы даже в термины не попадаете, а пишете дофига.
      Асинхронность — это пока что-то полезное делается, вместо того чтобы ждать и ничего не делать.
      Это когда ваши согласующие до своего согласования делают работу, а не тупо сидят и ждут команды «согласуй», параллельностью тут даже не пахнет. И так работают все вокруг. Если в компании на одного контрагента приходится столько человек и они больше ничем не занимаются, то их увольняют, для оптимизации.

      UPD: а момент с тем, что люди должны делать то, что ещё не утверждено, меня порадовал безмерно. А платить им потом за что, если они не сделали ничего? А когда они тогда должны делать то, за что им платят?
        +1
        На сколько я понял, существует некая вероятность успешности завершения процесса. Например при утверждении юристом, пусть будет несколько итераций по утверждению договора, но если историческая вероятность успеха например 95%, то сидеть и ждать глупо.

        Думаю что при желании можно в каждом конкретном случае по деньгам посчитать оба варианта и принять тот что наиболее выгодный.
          0
          Так а что, у вас в компании реально есть люди, которые сидят и ждут? Им больше нечем заняться?
            +1
            Я например, сижу вот пишу комменты на хабр. Жду когда мою продуктивность повысят в 10-ть раз.
          –5
          Ничего не понял. Вы правда считаете, что асинхронность — это когда что-то делается, вместо того чтобы ждать?
            +3
            Асинхронные действия — действия, выполненные в неблокирующем режиме, что позволяет основному потоку программы продолжить обработку
            Тащемта, в ИТ это так.
            –3
            У вас ОЧЕНЬ странное представление об асинхронности
            +1
            Мир может многому научиться у программистов. Он и так учится, только не тому и не так.

            Абсолютно согласен про не тому и не так.

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

            Синхронные действия процесса – те, которые выполняются в основном потоке, в рамках одного экземпляра процесса. Ключевое отличие синхронного режима: следующее действие начинается только тогда, когда завершено предыдущее.
            Это не синхронные действия, а последовательные. Синхронность это про одновременность.
            Вообще для того кто эти термины ввел в программирование положен отдельный котел в аду. Я вот программист и уже же привык, но все равно когда ставят знак равенства между последовательно и одновременно мозг взрывается. Что уж говорить об «обычных» людях.
              0
              Некоторые асинхронные процессы легко реализовать без автоматизации — если асинхронный процесс имеет единственного владельца, который и поддерживает «тред». Пример — контроль экономической безопасности, когда сделки проверяются в фоновом режиме, уже после заключения и иногда даже подписания актов. Такая проверка ничего не блокирует, просто по ее результату кто-то сядет с конфискацией. Это же можно применить для множества процессов классического документооборота (кроме критически-важных сделок), пост-санкции хорошо работают, дополнительный плюс — ответственность и внимательность сотрудников повышаются, ведь они понимают, что их сейчас никто не подстрахует от ошибки.
                0

                В общем случае никакой синхронности/асинхронности не существует. Эти термины возникают, когда появляется понятие "поток выполнения" и связанные с ним термины: контекст выполнения, состояние, стек, etc… Возьмите любой нормальный функциональный язык программирования, и внезапно куда-то исчезнет вся "последовательность выполнения".


                Есть два способа реализации асинхронного выполнения:


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

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое