Описание процессов
Когда за разработку процессов берутся люди, далекие от понимания алгоритмов, часто возникают ошибки. Причем, на словах, в понимании разработчиков, процесс получается вполне себе годным, но на бумаге он становится нерабочим. Люди думают – да ладно, все же понимают, как надо работать, а бумажка – это так, для отписки.
Но время идет, люди меняются – уходит разработчик процесса, меняются сотрудники, исполняющие процесс и настает момент, когда единственным источником информации становится та самая бумажка. А она – совсем негодная.
Поэтому к разработке бумажек стоит подходить более вдумчиво. Не суть важно, как именно описан процесс – в виде схемы, или текстом, или вообще на видео снят. Важно, чтобы люди, не погруженные в контекст, могли понять, как он работает, а если точнее – как он должен работать.
Особенно много ошибок допускается при рисовании схем алгоритма процесса. Тут «помогает» сам формат нарисованного процесса, требования к схеме и правила оформления. Нарисовать живой процесс в таких требованиях сложно, но нарисовать – «надо», особенно если действует какой-либо стандарт оформления. Вот и рисуют, кто как умеет, лишь бы «сдать».
Оформление процесса в виде алгоритма – это просто проекция, переложение понятной информации в некий формат. Любая проекция всегда ведет к потере части информации, либо к ее искажению. И красивая схема, и квалиграмма, и текстовое описание, и должностная инструкция – просто проекции.
Любая проекция искажает. Это – основной принцип, который следует помнить при разработке формализованного описания процесса. Как тогда быть? Ведь описание процесса – необходимо.
Правило номер 1: не начинайте с описания процесса.
Начните с самого процесса – сделайте его рабочим. Достигните критериев, которые вы или заказчик предъявили к процессу. Потом описание сделаете.
В бизнес-программировании важно не «цементировать» процесс, особенно в промежуточном состоянии, когда еще ведется его отладка. Как только вы написали бумажку, она связывает вам руки. Особенно, если бумажка прошла несколько согласований.
Работайте, как программист. Ни один здоровый на голову программист не будет оформлять документацию на программу, которую еще не отладил, не добился требуемого поведения и производительности.
Если же вы сначала делаете описание процесса, а потом занимаетесь его имплементацией, то неизменно будете подгонять реальность под описание. Потому что возвращаться к корректировке описания вы не захотите. Бумажка будет для вас ментально законченной, т.е. решенной задачей. Кто же любит отменять решенные задачи?
Правило номер 2: используйте несколько форматов одновременно.
Самый лучший способ описания процесса – комплексный. Нарисовать схему, если это возможно. Написать текст – живой, понятный, интересный, отражающий все основные особенности процесса.
Не забывайте, что читать процесс будут разные люди. Опять же, берите пример с программистов: они пишут несколько экземпляров документации, и у каждого – свое назначение. Есть инструкция для пользователя – простая, с картинками, без технических деталей. Есть описание архитектуры системы и программного кода – для других программистов, которые будут сопровождать и развивать систему.
Аналогично стоит описывать процессы. Например, в схеме для исполнителей нет смысла упоминать методики, которые вы использовали – людям это не интересно. А вот бизнес-программисту, который возьмется за рефакторинг процесса, будет полезно знать, что вы применили принципы ТОС или Scrum.
Главное же – не забывайте о здравом смысле. В бизнес-программировании нет стандартов, строгих правил и законов, кроме одного: должно работать.
Синхронность и асинхронность процессов
Любому программисту понятно, что такое синхронность и асинхронность. Вот насколько это понятно программисту, настолько это непонятно и обычным разработчикам процессов.
Синхронные действия процесса – те, которые выполняются в основном потоке, в рамках одного экземпляра процесса. Ключевое отличие синхронного режима: следующее действие начинается только тогда, когда завершено предыдущее. Соответственно, пока одно действие не завершено, процесс стоит колом.
Асинхронные действия – те, которые выполняются параллельно основному потоку, либо в том же экземпляре процесса, либо вообще в другом процессе. Ключевое отличие асинхронного режима: параллельное выполнение двух и более ветвей процесса.
Синхронные процессы, как и программы, писать и отлаживать намного проще, поэтому такой подход к конструированию процесса очень сильно распространен. С асинхронностью надо много возиться, особенно – с обозначением точек перехода в параллельное выполнение и возврата обратно, в русло основного процесса.
Например, тот же процесс закупок по заявке. Рисуется стандартно, как последовательность действий: появилась заявка, снабженец выбирает поставщика, запрашивает сроки и стоимость, согласует с продавцом или отделом внутреннего контроля, формирует заказ поставщику, запрашивает в юридическом отделе или в бухгалтерии оценку контрагента, создает заявку на оплату, ждет этой оплаты, отслеживает заказ, потом организует или отслеживает оприходование на складе, чтобы, в конце концов, закрыть заявку. Процесс полностью синхронен.
Теперь представим – в нашей информационной системе не подключен сервис оценки поставщиков. Значит, юридическому отделу нужно собирать информацию из открытых источников. Значит, на выполнение оценки требуется время. С учетом очереди заявок к юристам, пройдет дня три.
Что в это время будет с процессом? Согласно синхронной логике, он будет стоять колом. Снабженец, будучи верным элементом системы, и пальцем не пошевелит, пока не получит оценку поставщика – особенно, если предусмотрены санкции за работу с непроверенными контрагентами.
Можем мы здесь добавить асинхронности? Конечно. В тот момент, когда снабженец выбрал поставщика, он может отправить заявку на оценку контрагента в юридический отдел, а сам пока будет вести переговоры, согласовывать цены и сроки. К тому моменту, когда он будет готов разместить заказ, и оценка подоспеет. Процесс закончится раньше на три дня.
Конечно, юристы могут возмутиться – чего это мы будем оценивать поставщика, если вы там еще четко не решили, будете ли у него заказывать? Что им ответить?
Решение напрашивается само собой, выше мы его уже обозначили – подключить сервис оценки поставщиков. Теперь мы еще лучше понимаем, зачем оно нужно – для придания асинхронности и ускорения процесса. Хотя, сервис, наверное, будет как раз синхронным. Как думаете?
Если сервис не подключать, то можно оправдать такую оценку работой «впрок». Если в вашей информационной системе есть куда записать данные оценки, то в следующий раз, когда возникнет потребность в работе с этим поставщиком, обращаться в юридический отдел уже не придется. Конечно, у оценки есть срок годности, но в некоторых разумных пределах ей пользоваться можно.
В асинхронности обычно пугает отсутствие гарантий, то есть риск негативного результата в одной из параллельных ветвей процесса. Что делать, если согласование закончится неудачей?
Тут нужна статистика. Если вы работаете с существующим процессом, то примерно, или точно, представляете себе, как часто определенные действия заканчиваются негативно – например, согласования. Вот из этой вероятности и стоит исходить, запуская параллельное выполнение.
Асинхронность прям напрашивается во все процессы согласования. Если там работать только по синхронному режиму, да еще и идти на поводу у согласующих, то выстраиваются длинные, взаимозависимые цепочки, порождающие бюрократию и круговую поруку.
Типичный пример: «я буду согласовывать только после того, как согласует вот он». Или «я посмотрю на этот договор только после финансистов». Хотя, если верить статистике и здравому смыслу, подобные постановки не имеют под собой оснований, и являются лишь способом переложить ответственность.
Тут главное – не переживать, и не браться за все сразу. Попробуйте выделить в асинхронный режим сначала одну ветвь согласования. Возможно, потребуется пересмотреть задание, параметры согласования – так, чтобы исключить взаимозависимость.
Например, пусть финансовый отдел, стоящий в цепочке согласования договора, смотрит только на условия оплаты. Пусть у него будут свои, понятные критерии оценки. Лучше, если они будут формализованы в виде типового договора – например, 100% постоплата для поставщиков, 100 % предоплата для покупателей. В таком случае договоры, удовлетворяющие критериям, будут проскакивать на раз. И у финансистов не останется повода ждать оценки от тех же юристов.
Единственное, что важно: асинхронные процессы очень сложно реализовать без автоматизации. Если процессы, их исполнение и отслеживание реализованы только на бумаге, то добавление параллельных ветвей превратит их в хаос. Нужна автоматизация.
Лучше всего для такой автоматизации подходит принцип «Автозадачи». Хотя, можно обойтись и стандартными средствами рисования процессов, которые есть в современных платформах, только придется повозиться.
Стандартные «рисовалки» процессов потребую от вас обозначить весь процесс, все ветви и взаимосвязи. Если процесс сложный и длинный, то вы столкнетесь с проблемой – он банально перестанет влезать на экран, в ширину. Если вы учились в институте на программиста, то помните такое правило оформления алгоритмов: не более трех параллельных вертикальных ветвей. Правило придумано не просто так – если ветвей будет больше, понять схему алгоритма будет проблематично.
Автозадачи от этой проблемы избавляют – там изображения процесса нет вообще, т.к. отсутствует такая сущность – процесс. Есть задачи. Если очень хочется, можно из них собрать процесс. Но не наоборот. Эдакий дедуктивный метод рисования процессов.
Кроме асинхронности, есть еще более мощный метод оптимизации – буферизация процессов. О нем – в другой раз.
Конфликт "один-много"
Конфликт «один - много» распространен, в первую очередь, среди людей, занимающихся описанием процессов, но не прилагающих особых усилий для того, чтобы получилось что-то вразумительное.
«Один» - это когда действие процесса выполняется над одним объектом. Например, обработка одной заявки на закуп, одного заказа покупателя, одной заявки на расход денег.
«Много» - это когда действие процесса выполняется над большим множеством объектов, например – сразу над пачкой заявок, портфелем заказов и т.д.
И «один», и «много» имеют право на существование, и вполне себе могут присутствовать в процессах. Проблемы начинаются, когда «один» и «много» ставят в одной цепочке.
Например, лично видел такой процесс. Первое действие – составить план закупок на год. Это – «много». Следующим действием процесса было обозначено «обработка поступившей заявки на закуп», т.е. одной заявки, конкретной. Одна заявка, как следует из названия – это «один». В данном случае, очевидно, действия должны относиться к разным процессам – «составление годового плана закупок» и «обработка заявок на закуп».
Первый процесс выполняется один раз в год, в нем идет обработка множества объектов. В зависимости от политики закупок, это могут быть фактические продажи за прошлый год, с учетом сезонности, плюс планы по продвижению новой продукции и т.д. У процесса – один экземпляр за год.
Второй процесс выполняется каждый день, и не один раз. У него – много экземпляров каждый день. Экземпляром является заявка на закуп. Зачем «рисователь» процесса объединил эти действия в один процесс? Да Бог его знает. Вероятно, хотел побыстрее отделаться, закрыть задачу по разработке процесса, и, возможно, получить свою премию.
Ну, вроде бы, какая разница? Все же – адекватные люди, и понимают, что процесс нарисован «просто так», а жизнь идет по своим правилам. Тогда зачем рисовать такой процесс? Так и порождаются тонны бумаги, которой никто потом не пользуется.
Другой случай, не такой вопиющий – реальное объединение в рамках одного процесса действий над одним и множеством объектов.
Например, тот же закуп. Объективно, снабженцу неудобно подпрыгивать и бежать исполнять каждую заявку, когда она возникла. Ему намного проще взять сразу несколько заявок – штук десять, например, причем сгруппированных по неким признакам. Например, все заявки на штамповки, или на зубодолбежку, или на резину, и выполнить их скопом. Вероятно, там и поставщик будет один и тот же, и документ надо будет оформить один. Получается, в данном случае снабженец работает с «много».
А «рисователь» процесса хочет, чтобы у него получилось красиво: вот заявка, вот действие над заявкой, вот время выполнения процесса. Его волнует только внутренняя логика и непротиворечивость процесса.
Что в итоге получается? Если «рисователь» - человек авторитетный и пробивной, он заставит снабженца носиться с каждой заявкой по отдельности. Тем самым снижая общую скорость процесса, выводя из себя снабженцев и их начальника, плодя бесчисленное множество лишней бумаги, причем – в разных отделах. Ведь снабженец будет оформлять заказ поставщику на каждую заявку, а следом – отдельный счет, который придется отдельно оплачивать финансовой службе, потом – отдельную приходную накладную от поставщика, отдельную счет-фактуру и т.д.
Намного проще эти процессы разорвать – пусть первый останавливается на моменте передачи заявки снабженцам, и возобновляется при наступлении любого подходящего события – например, при появлении заказа поставщику в системе. Тогда процесс снабжения, т.е. обработки этих заявок, будет отдельным – не важно, как его назвать, процесс или подпроцесс.
Прослеживаемость, измерение скорости процессов при этом никуда не теряются – разумеется, при нормальной автоматизации процесса. «Рисователь», возможно, скажет, что его это не устраивает, и ему нужно видеть, буквально глазами, и щупать руками ход процесса. Вплоть до того, что заставит на бумажной копии заявки ставить отметки – заказано, размещено, оплачено и т.д. Но, как вы понимаете, такая система нужна только самому «рисователю» - ни заказчику, ни снабженцу этого не нужно. Вполне достаточно данных системы, своевременно реагирующей на изменения данных. Рекомендую использовать принципы «Автозадачи», «Информатор» и «Контекстный рабочий стол». Если сущности заявок в системе присутствуют, и остальные операции – выставление счета, заказ поставщику, оплата и т.д. – на эту сущность ссылаются, собрать данные и вывести их в понятно виде потребителям труда не составит.
Не соблюдая принцип «один - много», вы можете потерять полезные свойства процесса, понятные людям, но не видимые со стороны. При массовой обработке объектов – тех же заявок на закуп – у человека образуется контекст, которого нет при обработке одной заявки. Контекст, зачастую, очень важен. Элементарно, когда снабженец заказывает поставщику сразу много деталей одного типа, он может получить скидку, или ускоренный срок производства, т.к. пачка заявок образует солидный пласт его плана производства.
Если вы – программист, то принцип «один – много» вам будет интуитивно понятен. Например, в клиент-серверной архитектуре, если обработка одного или нескольких объектов требует вызова сервера, намного проще и лучше сходить на сервер один раз, передав пачку объектов. Как говорится, чтобы два раза не вставать. Процедуры и операции массовой обработки объектов давно и прочно вошли в обиход современных информационных систем. Осталось сделать их достоянием обычных, «человеческих» процессов.
Если вы начнете разговаривать о принципе «один - много» с традиционным «рисователем» процессов, он будет сопротивляться, потому что соблюдение этого принципа потребует значительной, иногда – радикальной переработки процессов. «Рисователю» намного проще оставить все, как есть, с формулировкой «люди сами разберутся». Люди-то разберутся, но, повторюсь – зачем тогда рисовать процессы? Если на бумаге – одно, а в жизни – совсем другое?
Пока на бумаге процесс один, а в жизни – другой, можно забыть об оценке эффективности, развитии, отладке и оптимизации процесса. Это все равно, что отлаживать программу, которая не выполняется. Можете себе такое представить?
Вот написали вы, как программист, некий код. И хотите узнать, как он работает. А он не работает. Нет, в нем нет ошибок, он красив и внутренне не противоречив. Но ваша программа не исполняется, она не запущена, в ней нет ни одного пользователя. Жизнь идет своим чередом, а ваша программа лежит на пыльной полке.
Если вы – программист, то сталкивались с подобным положением дел. Заказали вам автоматизацию – ну, я не знаю, заявок на ремонт оборудования. Вы все сделали, программа получилась красивая и удобная, вы ее проверили, отладили, протестировали. А заказчик не пользуется. В системе лежит одна заявка на ремонт – тестовая, которую вводили вы.
Что можете сказать об эффективности вашей программы? Ничего. Красивая, внутренне логичная, без явных ошибок. Но ни черта не понятно, работает она в жизни, или нет.
То же с процессами. Пока они нарисованы в тестовом режиме, оптимизировать их бессмысленно. Они могут быть даже сертифицированы, по тому же ИСО, но у вас нет главного – обратной связи от жизни. А раз нет обратной связи, вы не можете дать никакого корректирующего воздействия – изменить процесс то есть. Потому что нет информации, на основании которой его можно менять.
Поэтому, давайте, погружайте «рисователя» в реальную жизнь, пусть тоже изучает бизнес-программирование.
