Заметка — продолжение темы описания процессов, в предыдущей были некоторые соображения о процессах верхнего уровня.
Итак, ответ на вопрос в заглавии: да и нет.
Нет, потому что без понимания общей картины легко запутаться и сложно соблюдать целостность проекта.
Да, потому что текущая задача конкретному специалисту или команде может не включать описание процессов верхнего уровня, по разным причинам. Например, потому, что они уже есть и описаны. Или потому, что в данный момент для конкретной задачи нет тому никакой необходимости. Или потому, что используемая методика не подразумевает описания процессов верхнего уровня в начале (т.е. они могут быть описаны, если это понадобится, но позже, что несколько нетрадиционно для подобного рода проектов, но всё же).
Приведу пример, когда это просто не надо в рамках задачи: заказчик хочет автоматизировать работу отдела продаж, выбирает для этого CRM-систему, но вначале хочет понимать (что не сильно часто случается, к сожалению), каковы вообще процессы, т.е. что именно подразумевается автоматизировать.
Т.е. хочет не купить, а потом разбираться, а вначале разобраться с процессами, а затем выбрать из того, что поможет их автоматизировать.
Забегая вперед, замечу, что риск неудачи все равно присутствует, даже если делать "по уму": иногда заказчик увлекается и выходит за рамки проекта, пытаясь объять необъятное, фокус теряется и в погоне за общим можно не достичь запланированного.
Побочная польза, которая может быть иногда очень полезной, — руководство видит, что, собственно, делают сотрудники. Т.е. в чем состоит их работа, что стоит за словом "работают", как достигается результат. Если руководители и так это знают, то ничего нового. Но практика показывает, что это бывает далеко не всегда. Очень часто, например, на позиции тех же продавцов нанимают людей, которые как бы сами должны понимать, что именно надо делать, и от них требуют только результат, не вникая в процессы. И что в таком случае автоматизировать? 😉
Описание процессов, если это делается в первый раз и до этого работа вовлеченных сотрудников никак особо не регламентировалась, может помочь, помимо прочего, посмотреть, сколько лишней или малополезной работы выполняется сотрудниками. Сколько времени тратится на те или иные задачи. Конечно, вы никак это не увидите только из диаграмм. Диаграммы всего лишь помогут выделить ключевые действия и стать основой для последующего анализа.
Итак, возвращаясь к нашей теме, как на практике обойтись без описания процессов верхнего уровня? Сама методика более широка (возможно, опишу ее позже более подробно), но суть в подходе "от событий". Что является "запуском" для цепочки действий? Что возникает на регулярной основе, что по "волевому" решению, что в ответ на действия других участников?
Иногда кажется, что список будет огромен, если не бесконечен, но в реальности часто оказывается, что он не так уж и велик — если не выходить за рамки проекта.
Например, триггером, "запускающим" событием для начала процесса продаж может быть получение продавцом информации о потенциальном клиенте (лиде) или наступление определенной даты, когда запланированы действия по ранее накопленной информации.
Также это может быть обращение потенциального клиента. Т.е. на данный момент запустить процесс продаж может три разных типа событий: 1) получение информации (лида) 2) "время пришло" (т.е. на регулярной основе) 3) обращение клиента.
Что еще может запустить процесс продаж? Правда, не так уж много вариантов? 😉
Примерно то же самое и с многими другими отделами. Вроде работа относительно разнообразная, но это всё по большей части действия и варианты действий, может процедуры (которые часто удобно выражать не процессами, а подпроцессами), но событий, запускающих процессы, принципиально различных не так уж много — в общем случае.
Скажем, в работе справочного контакт-центра основной процесс будет всегда запускаться событием "звонок клиента". Можно оставить единый процесс, можно разбить на разные варианты (это случается не часто и не совсем "идеологически" правильно, но иногда удобно, если варианты принципиально разные), но если в задачу не входит пересмотр общей схемы работы компании, если она конкретна и нет места сомнениям, а что там со стратегией и т.п., то вот он список событий-триггеров, от него и пляшем.
В результате может получиться:
- описание нужного процесса или процессов, включающее все действия, которые оставляют "след" в существующей или предполагаемой системе;
- описание т.н. ad hoc процессов, где есть перечень действий, но алгоритм не определен;
- перечень событий, которые могут случиться в реальной жизни, но на которые у нас нет процесса как такового (и отработка которых пока не предполагает автоматизации, например);
- если это нужно, то перечень функционала, используемого вне описанных процессов, но необходимого в работе.
По сути, для разработчиков это готовые бизнес-требования, которые достаточно легко дополнить юзер-кейсами. И, что важно, можно достичь полной исчерпываемости этих требований. В конце концов, если функционал считается как бы нужным, но он нигде не используется, то вопрос, нужен ли он. А если в процессе указаны определенные требования, но разработчики не учли их, то это относительно легко проверить — просто протестировать процессы.
Как видно, для такого, относительно узкого типа задач, описание процессов верхнего уровня может быть избыточным. В любом случае, это, конечно, определяется рамками конкретного проекта.
Итак, ответ на вопрос в заглавии: да и нет.
Нет, потому что без понимания общей картины легко запутаться и сложно соблюдать целостность проекта.
Да, потому что текущая задача конкретному специалисту или команде может не включать описание процессов верхнего уровня, по разным причинам. Например, потому, что они уже есть и описаны. Или потому, что в данный момент для конкретной задачи нет тому никакой необходимости. Или потому, что используемая методика не подразумевает описания процессов верхнего уровня в начале (т.е. они могут быть описаны, если это понадобится, но позже, что несколько нетрадиционно для подобного рода проектов, но всё же).
Приведу пример, когда это просто не надо в рамках задачи: заказчик хочет автоматизировать работу отдела продаж, выбирает для этого CRM-систему, но вначале хочет понимать (что не сильно часто случается, к сожалению), каковы вообще процессы, т.е. что именно подразумевается автоматизировать.
Т.е. хочет не купить, а потом разбираться, а вначале разобраться с процессами, а затем выбрать из того, что поможет их автоматизировать.
Забегая вперед, замечу, что риск неудачи все равно присутствует, даже если делать "по уму": иногда заказчик увлекается и выходит за рамки проекта, пытаясь объять необъятное, фокус теряется и в погоне за общим можно не достичь запланированного.
Побочная польза, которая может быть иногда очень полезной, — руководство видит, что, собственно, делают сотрудники. Т.е. в чем состоит их работа, что стоит за словом "работают", как достигается результат. Если руководители и так это знают, то ничего нового. Но практика показывает, что это бывает далеко не всегда. Очень часто, например, на позиции тех же продавцов нанимают людей, которые как бы сами должны понимать, что именно надо делать, и от них требуют только результат, не вникая в процессы. И что в таком случае автоматизировать? 😉
Описание процессов, если это делается в первый раз и до этого работа вовлеченных сотрудников никак особо не регламентировалась, может помочь, помимо прочего, посмотреть, сколько лишней или малополезной работы выполняется сотрудниками. Сколько времени тратится на те или иные задачи. Конечно, вы никак это не увидите только из диаграмм. Диаграммы всего лишь помогут выделить ключевые действия и стать основой для последующего анализа.
Итак, возвращаясь к нашей теме, как на практике обойтись без описания процессов верхнего уровня? Сама методика более широка (возможно, опишу ее позже более подробно), но суть в подходе "от событий". Что является "запуском" для цепочки действий? Что возникает на регулярной основе, что по "волевому" решению, что в ответ на действия других участников?
Иногда кажется, что список будет огромен, если не бесконечен, но в реальности часто оказывается, что он не так уж и велик — если не выходить за рамки проекта.
Например, триггером, "запускающим" событием для начала процесса продаж может быть получение продавцом информации о потенциальном клиенте (лиде) или наступление определенной даты, когда запланированы действия по ранее накопленной информации.
Также это может быть обращение потенциального клиента. Т.е. на данный момент запустить процесс продаж может три разных типа событий: 1) получение информации (лида) 2) "время пришло" (т.е. на регулярной основе) 3) обращение клиента.
Что еще может запустить процесс продаж? Правда, не так уж много вариантов? 😉
Примерно то же самое и с многими другими отделами. Вроде работа относительно разнообразная, но это всё по большей части действия и варианты действий, может процедуры (которые часто удобно выражать не процессами, а подпроцессами), но событий, запускающих процессы, принципиально различных не так уж много — в общем случае.
Скажем, в работе справочного контакт-центра основной процесс будет всегда запускаться событием "звонок клиента". Можно оставить единый процесс, можно разбить на разные варианты (это случается не часто и не совсем "идеологически" правильно, но иногда удобно, если варианты принципиально разные), но если в задачу не входит пересмотр общей схемы работы компании, если она конкретна и нет места сомнениям, а что там со стратегией и т.п., то вот он список событий-триггеров, от него и пляшем.
В результате может получиться:
- описание нужного процесса или процессов, включающее все действия, которые оставляют "след" в существующей или предполагаемой системе;
- описание т.н. ad hoc процессов, где есть перечень действий, но алгоритм не определен;
- перечень событий, которые могут случиться в реальной жизни, но на которые у нас нет процесса как такового (и отработка которых пока не предполагает автоматизации, например);
- если это нужно, то перечень функционала, используемого вне описанных процессов, но необходимого в работе.
По сути, для разработчиков это готовые бизнес-требования, которые достаточно легко дополнить юзер-кейсами. И, что важно, можно достичь полной исчерпываемости этих требований. В конце концов, если функционал считается как бы нужным, но он нигде не используется, то вопрос, нужен ли он. А если в процессе указаны определенные требования, но разработчики не учли их, то это относительно легко проверить — просто протестировать процессы.
Как видно, для такого, относительно узкого типа задач, описание процессов верхнего уровня может быть избыточным. В любом случае, это, конечно, определяется рамками конкретного проекта.
No comments:
Post a Comment