процесс можно разбить на
Немного теории о бизнес-процессах
Является организация коммерческой, некоммерческой или государственной, ее главным предназначением является создание продукции и услуг, обладающих ценностью для потребителя. Цели организации достигаются путем осознанного управления бизнес-процессами. К этому должны сводиться все цели организации. Сущность стратегического планирования заключается в определении основных векторов развития организации и показателей его деятельности на определенный временной период, идентифицирующий желаемый результат его активности в целом. «В рамках стратегического планирования обеспечивается комплексное обоснование проблем, с которыми может столкнуться предприятие, и определяются действия по их разрешению, а также разрабатывается конкретный план управленческих действий (стратегии) по выполнению миссии предприятия и достижению сформулированных целей».
Организация – это система, воплощенная в реальную модель. Хорошо работающая модель должна быть непротиворечивой, быстрой, синхронизированной и экономичной. Для построения таких моделей нужно использовать определенные алгоритмы действий, которые получили название бизнес-процессы. «Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе». Бизнес-процесс существует только пока в нем есть наличие человека. Если какой-либо процесс или алгоритм осуществляется автоматизированной системой или компьютерной программой, он становится технологическим процессом. В бизнес-процессе принимают участие люди в разной форме, уровне вовлеченности и ответственности.
Допустим, человек работает один (например, музыкант), у него все равно имеются люди, вовлеченные в его бизнес-процесс (например, студия звукозаписи) и потенциальные потребители (слушатели). Ничто не существует в «вакууме» – так же и у музыканта одиночки есть люди, которые непосредственно являются фактором влияния на его работу. В данном случае — это студия звукозаписи и потенциальные слушатели. Эти люди тем или иным образом оказывают влияние на бизнес-процесс. Для дальнейшего продвижения по теме, необходимо подробнее рассмотреть понятие «бизнес-процесс».
«Бизнес-процесс – это совокупная последовательность действий по преобразованию ресурсов, полученных на входе, в конечный продукт, имеющий ценность для потребителя, на выходе». «Бизнес процесс – это четкий, зафиксированный письменно алгоритм выполнения некой деятельности». Бизнес-процессы необходимы для визуализации действий, происходящих внутри организации, для изображения реальных зон ответственности рабочих, для выявления потенциальных слабых сегментов деятельности предприятия, для детальной систематизации и стандартизации рабочих процессов и повышения эффективности принятия решений. Бизнес-процессы присутствуют в любой организации, иногда они являются задокументированными, что приносит огромный скачок в качестве, а иногда нет, что является плохим признаком в рамках развития организации, так как исчезает возможность работать над эффективностью процесса. Организацию в большинстве случаев рассматривают, как набор подразделений, каждое из которых выполняет определенные функции, но у процессного подхода есть свои преимущества. Рассмотрение предприятия с точки зрения процессного подхода позволяет разделить организацию на две части – основную и поддерживающую. Помимо этого, можно выделить управленческую часть и часть ответственную за развитие развития.
Рисунок 1.1 – Графическая интерпретация иерархии бизнес-процессов
«Основные бизнес-процессы – это процессы, которые непосредственно создают ценность». «Поддерживающие – процессы, без которых не могут существовать основные бизнес-процессы, бизнес-процессы обеспечения разнообразными ресурсами». Остальные процессы описания не требуют. Углубимся еще немного. Бизнес-процесс можно разбить на сегменты, которые в нем есть:
Рисунок 1.2 – Поток создания ценности
Поток начинается от запроса потребителя и направляется к исходному сырью – другими словами это несколько процессов, которые один за другим вносят полезные качества и определенную ценность для потребителя. В целом все легко и просто. Что еще нужно знать про бизнес-процессы? Их можно разделить на задачи к которым они относятся. На задачи которые они решают. Из этого следует, что разновидностей бизнес-процессов может быть сколь угодно много, выделим основные из них:
Для более детального рассмотрения сути бизнес-процессов требуется ввести понятие жизненного цикла бизнес-процесса. Жизненный цикл бизнес-процесса представляет собой прохождение четырех основных этапов, каждый из которых характеризуется набором определенных действий, которые направлены на бизнес-процесс на этом этапе. Жизненный цикл бизнес процесса выглядит следующим образом.
Рисунок 1.4 – Жизненный цикл бизнес-процесса
Улучшение бизнес-процесса на этапе «Проектирование» состоит из таких этапов, как:
Как справиться с декомпозицией задач и не перестараться
Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.
Как видно из приведенных примеров, описание каждой задачи зависит по большей части от фантазии и здравого смысла заказчика. Где-то оно больше, где-то оно меньше, но аналитикам надо как-то с этим работать. Иногда указывают еще и границы функционала, а иногда присылают просто тему. Если передать такую задачу сразу в разработку, на выходе получим что-то непонятное. Что приходится делать?
Идти к заказчику ногами и выспрашивать все требования, уточнять, что именно должно быть на выходе. Правда, бывают еще золотые заказчики, которых, на самом деле, большинство — они пишут все требования у себя в Confluence, поэтому можно в любой момент пойти и спокойно почитать, задать вопросы. И когда уже все понятно с рамками фичи, можно приступать к нарезке задачи.
Зачем нужна декомпозиция
Основная цель декомпозиции заключается в том, чтобы бизнес мог быстро реализовывать все свои хотелки, и чтобы от самой идеи до появления функционала у пользователя проходило как можно меньше времени. Для этого можно делать более мелкие задачки, от которых пусть небольшой, но все-таки рабочий функционал будет доходить до пользователя.
Помимо достижения глобальной цели удовлетворения потребностей пользователя и бизнеса, декомпозиция задач позволяет получать более быстрый фидбэк от заказчика, в правильном ли направлении копает разработка, или же получилось совсем не то, что заказчик себе представлял.
Если задача изначально большая и мы взялись за нее сразу целиком, то мы потратим на нее очень много времени и после комментариев заказчика нам придется все выбросить. Ну а если задача маленькая, день-два работы от силы, — ничего страшного. Переделка займет еще примерно столько же. Второй подход, к тому же, обойдется еще и дешевле. Не говоря уже о сэкономленных нервах с обеих сторон.
Если один функционал разбить на несколько кусочков, разработчики могут работать над ними параллельно. Таким образом мы распараллелим поток и ускорим вывод функционала в прод. Важная штука — при этом задачи должны как можно меньше зависеть друг от друга.
Плюс быстрое тестирование и исправление багов. Опять же, мелкий функционал гораздо проще и быстрее тестировать, чем монструозную махину. И если что-то пойдет не так, на «пофиксить» разработчик потратит совсем немного, и все быстрее заработает.
На этапе разбивки задач вместе с заказчиком можно сразу понять, какой функционал важен прямо здесь и сейчас, чтобы уже начать получать прибыль, что можно оставить на потом, а что, возможно, само отвалится за ненадобностью.
Бизнесу же важно знать, как быстро появится рабочий функционал. И при разбивке на задачи мы можем спрогнозировать и более точно оценить время, которое потребуется на их реализацию, чем когда у тебя один большой фронт работ. Но помимо того, что мелкие задачи легче оценить в плане времени на их проработку, разработчику также проще оценить риски, которые могут возникнуть в процессе работы.
Например, обновились фреймворки, какие-то методы вывели из эксплуатации, проблемы с кодом и прочее. Беря в работу небольшие задачи, мы минимизируем все эти риски, и даже если такая задача что-то заблокирует в потоке, это будет не так критично, как если бы это был здоровенный кусок (который бы заблокировал вообще всё). В случае необходимости можно будет сделать рабочее решение и в бэклог положить техдолг, с которым можно будет разобраться чуть позже, когда проблемы будут решены.
Основные подходы и правила декомпозиции
Существуют два основных подхода к декомпозиции задач — горизонтальный и вертикальный. При горизонтальном задачи делятся по типам работ, по уровням или по компонентам. Например, у нас каждая задача проходит через несколько стадий: фронтенд, бэкенд, базы данных. И при горизонтальном подходе одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных.
Чем плох данный подход? Мы не получаем рабочий функционал после выполнения каждой отдельной задачи. Только собрав результаты из трех источников, мы можем получить какой-то результат и фидбэк на него. По этой причине горизонтальную декомпозицию чаще всего не используют.
Гораздо удобнее вертикальный подход, при котором в каждой задаче можно сделать наглядный функционал — задача проходит по всем стадиям и на выходе есть результат, который можно проанализировать, протестировать, показать заказчику и поправить, если надо. И быстренько запустить в работу и использовать.
Если говорить про правила, здесь я выделил всего три. Во-первых, задача должна быть логически завершенной, то есть независимой сама по себе. Она не должна ломать логику вокруг себя и обязательно должна нести в себе хоть какой-нибудь бизнес-смысл, который в результате получит пользователь. При этом не стоит разбивать на части те задачи, которые не несут бизнес-смысла (в идеале их вообще не должно быть).
Во-вторых, результат выполнения одной небольшой задачи должен нести небольшие изменения. Чем меньше изменения, тем быстрее они попадают в общий код, и таким образом код не устаревает. Кроме того, маленькие задачи помогают избежать конфликта между разработчиками при мердже.
В-третьих, не стоит разбивать задачу на совсем уж микроскопические части. Если разбить слишком мелко, очень много времени уйдет на управление этими задачами. На каждом этапе их, возможно, придется переприоритезировать, заново проставлять связи зависимости и вот это всё. Таким образом, скорость разработки не увеличится, а наоборот, резко упадет. Поэтому нужно искать золотую середину.
Способы декомпозиции
В зависимости от источника, количество способов декомпозиции очень сильно варьируется: где-то их указывают всего восемь, где-то десять, где-то двадцать. Я бы хотел остановиться на тех способах, которыми мне приходится пользоваться каждый день на работе.
Несколько потребностей
Этот способ удобнее всего использовать, когда в истории присутствуют союзы «и», «или». Например, потребитель хочет сделать заказ и оплатить его картой или бонусами. Эту задачу можно разделить на три: первая, в которой пользователь делает заказ, вторая, где он оплачивает его картой, и третья, где в ход идут бонусы.
Сценарии использования
Еще один часто встречающийся способ — делить задачи в зависимости от сценария использования. В этом случае одна история представляет из себя один основной путь и несколько альтернативных. Допустим, пользователь хочет купить товар, и это будет основной сценарий. Но есть еще альтернативные пути — он может сразу положить товар в корзину и оплатить, а может захотеть перед покупкой сравнить этот товар с другими. И тогда отдельной задачей мы делаем сравнение товаров.
Возможно, он не хочет покупать прямо сейчас, а отложить куда-нибудь, добавить в избранное, чтобы позже к нему вернуться. Или пользователю понравился товар и уже готов его купить, но его нет в наличии. Значит, надо дать ему знать о том, когда товар появится. И вот таким образом получается четыре сценария.
От простого к сложному
Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.
При таком подходе с каждой последующей задачей функционал должен расти. Мы можем, например, сделать из сетки карусель, а потом добавить какие-нибудь ссылки, тексты, кнопки и остальное. В общем, сначала реализуем самый простой и быстрый в исполнении вариант, а затем движемся к более сложному.
Как раз недавно я занимался похожей задачей по реализации баннера. Баннер должен был висеть на главной управляться из CMS. Если спросить у заказчика, а чем бы именно он хотел управлять, он, не моргнув, радостно ответит — всем. Поэтому здесь было важно немного погрузиться в тему и выделить то, чем нужно управлять прямо сейчас, чем просто часто, а чем почти совсем не пользуются. И таким образом расставить приоритеты по реализации и поделить на задачи.
Операции (CRUD)
Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.
Варианты интерфейса
Используется, когда надо поддержать несколько вариантов интерфейса. Например, сайт должен поддерживать несколько языков. Сначала мы делаем русскоязычную версию. Затем, при запусках в других странах, добавляем английский. Если же в стране используется язык, отличный от английского, то можем добавить и его. В этом случае проще все сделать сначала на одном языке, а потом постепенно добавлять переводы.
Совсем недавно мы завершили проект личного кабинета для юридических лиц, в котором нужна была поддержка мультиязычности. Сроки были сжатые, поэтому изначально сделали все на одном языке, но заложили основу для дальнейшего перевода. Теперь, чтобы добавить поддержку нового языка, нужна всего лишь одна небольшая задача. Если нужно добавить сразу несколько языков, на каждый из них заводится отдельная задача.
Разделение по ролям
Подходит для ситуаций, в которых функциональность подразумевает работу нескольких ролей и групп пользователей. На сайте «Спортмастера» у пользователя могут быть разные роли. Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя, и, допустим, пользователь колл-центра. Последняя роль также может делиться на две — это может быть как рядовой пользователь, так и администратор.
Для каждой роли мы можем сделать отдельную задачу. Начать с отображения для анонимного пользователя, а затем добавить какой-нибудь расширенный функционал в рамках задачи для авторизованного. И не забыть про технические роли операторов колл-центра и функционал для них.
Обработка ошибок
Если сроки сжатые, а минимальный функционал нужен как можно быстрее, можно вынести обработку ошибок в отдельную задачу. Здесь речь идет не о написании тестов, а об обработке ошибок пользователей и систем, с которыми интегрирован сайт. Представим, что мы обрабатываем страницу с каталогом, которая содержит плитку с товарами. В каждой карточке есть описание, фото и дополнительная информация.
Случилось так, что какая-то часть информации не приходит из баз данных.
Возможно, если речь идёт о бренде или материале, то этим можно пренебречь и просто не показать информацию. Но если не дойдет цена или название, стоит ли показывать эту карточку?
Что в такой ситуации делать? Этот вопрос можно вынести в отдельную задачку и затем обрабатывать каждое отдельное поле. То есть, если не пришла цена, то выполняем одно действие, потерялось описание товара — другое. То же самое с ошибками пользователя. Если он ввел что-то некорректно и отобразилась ошибка, например, «Страница не найдена» или ошибка 500, мы должны показать ему конкретную информацию о том, что случилось, и предложить ему сценарий, что он может сделать дальше.
Этот способ также подходит для ситуаций, когда нужно быстро получить обратную связь на функциональность, чтобы решить, оставлять ее или нет.
Статические, затем динамические
Это один из моих любимых способов. Подходит в ситуациях, когда можно реализовать функционал «на заглушках», то есть внешние системы не готовы поддержать функционал. Например, какие-то блоки на главной странице не могут управляться из CMS. Или меню, когда мы делаем его у себя в коде и отображаем пользователю, но при этом им не может управлять бизнес. И чтобы внести изменения, бизнесу надо постоянно ходить в разработку и просить это сделать.
Здесь мы выносим потребности пользователя и получение прибыли в приоритет. Пользователь получает готовый функционал сразу, пусть мы внутри можем испытывать некоторые неудобства. Поэтому мы делим задачу на несколько и сначала делаем новый блок доступным для пользователя, но бизнес им пока напрямую управлять не может. Но затем мы можем интегрироваться с какой-то системой или базой данных, где бизнес сам сможет менять пункты местами и добавлять новые самостоятельно, а мы их будем отрисовывать без участия разработки.
Мы часто используем этот способ: сначала делаем функционал на своих данных, которыми нельзя управлять со стороны, а потом уже добавляем динамику и начинаем получать данные из сторонних систем.
Производительность
Если задача в целом сложная и объемная, непонятно, с какого конца за нее взяться, то производительностью можно пренебречь. В первую задачу вынести готовый функционал, который хоть как-то, пусть медленно, но работал. А следующей задачей сделать ускорение работы. Например, это может быть медленная работа поиска товаров, применение фильтров, получение какой-либо информации
Иногда большая часть усилий вкладывается в быстрое создание функции — первоначальная реализация не так уж сложна. Но можно многому научиться из медленной реализации, плюс это имеет определенную ценность для пользователя, который иначе не смог бы выполнить какое-нибудь важное действие. Во всех этих случаях задачи разбиваются на «заставьте это работать» и «сделайте это быстрым».
Возможные трудности
Если вы решите использовать декомпозицию задач в своих проектах, то скорее всего первой сложностью, с которой вы столкнетесь, будет зависимость задач друг от друга. По моему опыту, именно эта проблема приводит к блокированию всего потока и встречается наиболее часто. Чтобы этого избежать, к декомпозиции стоит подходить ответственно и уделять ей достаточное количество времени.
Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?
Мы для себя вывели правило, что задача должна проходить по всему потоку не больше, чем за одну неделю (около 40 часов). Речь идет про все стадии: стадию аналитики, разработки, тестирования. Плюс учитываются две стадии разработки бэкенда и фронтенда, включая ревью и тестирование на каждой.
Еще у нас была проблема с тем, что не всегда понятны границы эпика. Недавно нам поставили задачу с оформлением заказа. Где у нее границы? Что должно получиться на выходе? Нам было непонятно, нужно ли нам делать весь функционал до самого конца, или выбрать какую-то часть. Входит ли в этот эпик оплата, или это уже отдельный эпик.
Бывают задачи, с которыми сложно понять, как их декомпозировать и когда. Большую часть задач мы декомпозируем на стадии приема эпика, но бывают ситуации, когда это нужно сделать, например, на этапе аналитики. Мы берем задачу в работу и считаем, что все нужные данные в наших интеграционных системах уже есть, но в процессе анализа выясняется, что либо нас не устраивает формат данных, либо проблема в качестве самих данных, либо требуется доработка со стороны других систем, с которыми мы связаны. Тогда нам приходится делать задачу «на заглушках» и заводить еще один пункт в бэклог, к которому мы приступим уже после того, как решим основные проблемы.
Вот, вроде бы, и всё. Будет здорово, если поделитесь в комментариях историями о том, какой подход к декомпозиции задач используете вы и почему.
Как декомпозировать бизнес-процессы
Декомпозиция – это разделение задачи на более простые составные части. В контексте управления предприятием этот термин чаще используется для целеполагания. Но дробить можно не только цели, но и процессы. Чаще всего декомпозиция используется, чтобы упростить управление процессами.
Вся деятельность компании состоит из процессов – производство товаров или оказание услуг, поиск покупателей и сбыт продукта. Каждый процесс представляет собой последовательность определенных действий, чаще всего повторяющихся и цикличных. От того насколько действия эффективны, зависит прибыль организации и ее конкурентоспособность на рынке.
Если бизнес-процесс неправильно декомпозировать и некачественно описать, то и результаты работы не дотянут до поставленных целей. Если декомпозиция бизнес-процессов вообще отсутствует, значит, отделы компании работают хаотично.
Правила декомпозиции
Чтобы правильно описать бизнес-процесс, необходимо учитывать в работе такие нюансы:
Части бизнес-процесса
Один бизнес-процесс можно декомпозировать на более мелкие части. Один процесс обычно делится на подпроцессы. Он имеет такие же свойства, как и процесс, – начало, окончание, показатели или механизмы реализации, длительность. Количество подпроцессов может быть неограниченным.
Действия в подпроцессе делятся на операции. В идеале каждая операция будет максимально простой, то есть ее уже невозможно раздробить на более мелкие операции.
Нет единого правила, насколько подробно следует дробить процесс на составляющие части. Все зависит от навыков и компетенций тех работников, которые будут задействованы в процессе. Если работают новички, возможно, для них следует декомпозировать процесс подробно. Более опытным работникам не нужна подробная инструкции, поэтому для них зачастую можно обойтись только перечнем подпроцессов.
Систематизация операций
Когда бизнес-процесс разделен на части, их необходимо сгруппировать. Обычно группируют операции в такие группы:
Например, в отделе маркетинга работой может быть определение типа рекламы, ведь эти процессы выполняют сотрудники одного отдела. Но в создании рекламы задействованы разные специалисты – фотографы, видеооператоры, авторы рекламных слоганов и маркетологи. У каждого есть свои операции, но все они необходимы для достижения одной цели – запуска рекламы.
Иногда гораздо удобнее группировать операции в одну процедуру. Ключевое отличие процедуры заключается в порядке выполнения операций. В рамках одной процедуры операции всегда имеют строгую последовательность и выполняются без перерыва.
Оценка бизнес-процесса
Чтобы понять, насколько эффективно выполнен бизнес-процесс, его следует оценить. Оценку стоит проводить по нескольким критериям. Первый критерий – результативность. Важно проверить, достигнута ли изначальная цель бизнес-процесса или группы операций. Например, если цель заключалась в создании годового отчета и по итогам работы этот отчет сделан, значит, процесс результативен.
Важно понимать, что мелкие ошибки в отчете не отменяют результативности операций. Однако они влияют на второй критерий – определенность. У многих бизнес-процессов есть стандарты и образцы. Например, процесс уже описан в каком-то документе, поэтому после его выполнения результат работы можно сравнить с задокументированным эталоном. Если они совпали, значит, бизнес-процесс соответствует критерию.
Третий критерий – эффективность. Необходимо оценить, сколько ресурсов компании было потрачено во время процесса. Если для получения нужного результата ушло больше ресурсов, чем было запланировано, то процесс нельзя считать эффективным.
Вот какие еще критерии есть у бизнес-процессов:
Этапы декомпозиции
Чтобы раздробить бизнес-процесс на несколько составляющих, необходимо работать по алгоритму. В первую очередь, следует выбрать тот бизнес-процесс, который необходимо декомпозировать. Обычно бизнес-процессы привязаны к дереву целей предприятия и соответствуют прописанным там задачам. Но если дерева целей нет, следует ориентироваться на ключевые направления деятельности – производство товаров, оказание услуг, реклама, сбыт.
Следует обозначит его начало и конец бизнес-процесса. Начало иногда называется входом процесса. Чтобы определить вход, чаще всего используют какую-то проблему, которая есть перед компанией. Например:
Создание продукта и поиск клиентов – это основные задачи, стоящие перед бизнесом. Но в каждом отделе могут быть свои бизнес-процессы. Их тоже можно декомпозировать и разбить на подпроцессы. Например, в отделе продаж есть такие бизнес-процессы:
Конец, или выход процесса – то, что должно быть получено в результате работы. Обычно это решение проблемы. Решение позволяет перейти к следующей задаче или цели.
Третий этап – подробное описание того, что нужно сделать. Если руководитель хорошо знает деятельность каждого отдела, он может выполнить этот этап самостоятельно. Но чаще всего требуется привлечь к описанию процессов сотрудников соответствующих отделов. Например, если рассматривается такой бизнес-процесс, как «создание продукта», то логично провести собрание с начальником производства, руководителем отдела закупок, отдела контроля качества продукции. Ведь пока компания создает продукт, она:
При желании можно раздробить каждый подпроцесс на более мелкие операции. Например, закупка сырья представляет собой такой набор действий:
Если детально прописывать порядок работы, очевидно, что к обсуждению следует привлекать работников соответствующих отделов.
Следующий этап декомпозиции – формирование порядка работы, чтобы на основе декомпозиции можно было составить схему или регламент. Необходимо определить, в какой последовательности будут совершаться все операции. Часто на этом этапе возникают идеи, как можно упростить или автоматизировать процесс.
После того как выстроена схема процесса, необходимо проверить процесс на соответствие ключевым критериям и назначить ответственных за выполнение операций. За каждой задачей должен быть закреплен конкретный сотрудник, должность или даже программа на компьютере. Кроме того, необходимо найти человека, который отвечал бы за весь процесс целиком. При декомпозировании бизнес-процессов такой человек называется владельцем процесса. Если большую часть операций делает один и тот же человек, то допускается именно его сделать владельцем.
Уже на этом этапе декомпозицию бизнес-процесса можно считать законченной. Прописанные подпроцессы можно использовать для составления регламентов, должностных инструкций. Тогда следует записать план работ в таблицу, для каждой операции прописать длительность или сроки выполнения, ответственное лицо, ожидаемый результат. Здесь же следует прописать показатели, по которым придется оценивать эффективность процесса.
При желании бизнес-процесс можно еще детальнее декомпозировать, то есть прописать действия работников пошагово. Тогда получится инструкция для новичков, не знакомых с порядком работы.