Предположим, вам нужно разобраться в работе своей компании или своего подразделения (своей — не в смысле принадлежащей вам, а в смысле той, где вы работаете), потому что что-то идет не так. Или есть понимание необходимости внедрения автоматизации, но не совсем ясно, что именно нужно автоматизировать и во что это может вылиться по затратам.
Другими словами, есть желание описать процессы для дальнейшего их анализа и возможной оптимизации и/или автоматизации.
При этом по каким-то причинам речь о процессах верхнего уровня не стоит, по крайней мере в данный момент и в рамках данной конкретной задачи (нет средств, нет понимания, зачем это нужно, нет желания, эти процессы уже описаны и исправлять их нет смысла и т.п.), — т.е. данная заметка продолжение предыдущей, про описание процессов без процессов верхнего уровня.
Важное замечание: это по сути изложение методики, которая родилась у меня на основании опыта работы фрилансером-консультантом, я не прочитал о ней в книгах (я наверняка о многом еще не прочитал, литературы на эту тему огромное количество, она объемна, часто сложна и, что самое плохое, может очень быстро устаревать и терять актуальность), поэтому принимайте ее на свой страх и риск, проверяйте и относитесь критично. Возможно, также, что что-то похожее используется другими — ничего не могу об этом сказать.
Итак, начинать необходимо с определения целей и рамок проекта (лучше сразу мыслить в понятиях проекта — как чего-то, что имеет понятные цели и предсказуемое окончание). Почему? Потому что иначе очень легко "улететь в облака". Это тем более важно, если вы сторонний специалист, а не работаете в компании за зарплату. Кроме того, как говорится, если вы не знаете, куда идете, то даже если придете, — как узнаете, что уже пришли?
Т.е. задача должна быть сформулирована корректно (например, в рамках принципов SMART), проект должен подразумевать четко очерченную цель и понимание, каково должно быть завершение проекта. Обращаю внимание, в идеале, это, конечно, должен быть результат, но лучше, если помимо желаемого результата будет описание именно завершения проекта: будьте реалистами, результат достигается не всегда.
Лучше явно указать, зачем это всё надо. Т.е. цель должна отражать не только желаемый результат, но и почему он вообще нужен. Звучит странно, т.к. часто речь идет об очевидных вещах (обычно это эффективность), но явное описание понадобится в будущем, когда придется принимать решение, делать что-то или нет, сколько на это тратить времени и сил, — всегда можно будет посмотреть — а почему изначально всё затевалось? Нужно ли это для достижения заданной цели? Стоит ли оно того?
Далее, конечно, вы можете быть одновременно исполнителем и заказчиком. Но вообще-то это грустно. Вам не на кого будет "опереться в разговоре". Истина рождается в сомнении и дискуссии, для ее качества необходима конструктивная оппозиция, другая сторона.
Поэтому совет:
- если вы сами и заказчик, и исполнитель (т.е. делаете всё для себя), то уделите больше внимания на критичные показатели и обратную связь от участников процесса и всех, кто с ним связан (клиенты, партнеры и т.д.);
- если вы — "естественный" заказчик (т.е. собственник бизнеса, топ-менеджер или и то, и другое) — лучше найдите хорошего исполнителя, которому поставьте задачу (и сразу увидите, насколько корректна уже сама постановка задачи, как это выглядит со стороны и т.п.);
- если вы — инициативный сотрудник (в т.ч. руководитель, но не топ или не собственник) — попробуйте "продать" вашу идею выше, руководителю или собственнику; другими словами, сделайте заказчика из него; особенно важно, если ваших полномочий недостаточно для внедрения проекта, — 99% вероятность даже в случае блестящего исполнения, но без согласования с руководством, что проект не даст результат — такова жизнь (про оставшийся удачный процент можно будет писать вдохновляющие статьи или даже книги, в стиле "смотрите, какие бывают чудеса").
Итак, рамки проекта должны включать примерно следующее:
- проблематика и актуальность (почему это всё нужно);
- что предполагается сделать;
- каков ожидаемый результат;
- как он будет выглядеть и как его можно будет оценить;
- какие будут выделены ресурсы (если вы сторонний специалист, то тут нужно поточнее), в том числе по времени;
- каково будет завершение проекта;
- и так далее, что вообще присуще любому проекту, но не принципиально для описания данной методики.
Предположим, цель проекта не совсем внятна (увы, именно так часто и бывает) и звучит примерно так:
- почему? — отдел не дает нужный результат, положение ухудшается;
- что? (вообще) — нужно разобраться более детально в работе отдела;
- что? (конкретно) — для этого для начала нужно описать процессы отдела (или процесс);
- зачем? — чтобы видеть более детальную картину и иметь возможность на ее основании построить анализ;
- зачем? — на основании этого анализа, возможно, принять решение об изменении процесса (оптимизации) и, возможно, его автоматизации, в той или иной мере;
- зачем? — чтобы тем самым повысить эффективность (отношение результата к затратам) или результат (примечание: иногда результат нужен во что бы то ни стало, тогда речь идет не столько об эффективности, сколько о результативности);
- каков ожидаемый результат (проекта)? — вот перечень показателей на запланированный период или дату;
- как будет выглядеть результат (проекта)? — диаграммы процессов с их текстовым описанием и указанием, какие действия можно будет учитывать и оценивать (= какие показатели можно будет анализировать) в дальнейшем, для принятия решения; плюс рекомендации, сделанные уже в ходе первичного изучения процесса и его описания;
- ресурсы? — столько-то времени, столько-то денег (включая гонорар, в случае стороннего специалиста); сотрудники будут обязаны давать интервью и обратную связь, а также отвечать за качество информации;
- как будет проходить работа? — описание формата работы исполнителя;
- как будет выглядеть окончание? — отчет в заданную дату, включающий наличные на тот момент документы по проекту, рекомендации и краткий первичный анализ; исполнитель будет обязан предоставить наличные документы и отчет по работе, заказчик будет обязан их принять, учитывая то, что это совместная работа.
Естественно, в случае стороннего консультанта там могут быть важные дополнения и подробности, но, как уже было сказано выше, это не принципиально для методики.
Следующий шаг — определение ключевых (для процесса) специалистов и интервью с ними. Причем, из практики: список интервьюируемых может пополняться в ходе работы, поэтому не обязательно стремиться к тому, чтобы он изначально был точным и исчерпывающим.
На основании интервью уже можно рисовать диаграммы — желательно уже сразу добавлять к ним более подробное описание. Насколько подробное — зависит от задачи. Не стоит вдаваться в детали там, где это не пригодится в будущем.
Тот же самый разумный прагматизм имеет смысл применять и к описанию некоторых процессов или процедур: если не этот процесс или процедура главные, то вопрос, насколько детально нужно их описывать и даже вообще, нужно ли их описывать. Возможно, просто оставить в более общем виде, не теряя ни времени, ни сил.
Уже при составлении первых диаграмм может стать понятно, где можно оптимизировать процесс. Особо с выводами спешить не стоит, но некоторые вещи не только просматриваются сразу, но и наверняка знакомы сотрудникам — просто либо руки не доходили, либо не было убедительных доводов, либо не было общей картины и не было понятно влияние на другие вещи.
Чаще всего интервью — не разовый процесс, т.к. может понадобиться уточнять некоторые моменты. Особенно в случаях, когда точка зрения на происходящее различна у собственно исполнителей и их руководства.
К диаграммам может быть удобно добавлять подробные описания тут же — некоторые инструменты такое позволяют.
Проект очерчен, интервью проведены, процессы описаны — самое время вспомнить, зачем всё это затевалось. Если для анализа — сделать такой анализ. Возможная оптимизация — подготовить рекомендации по оптимизации. Автоматизация — тут могут быть нюансы, в частности, важно понимать, что никакая часть функционала не оказалась за бортом. Если все нужные процессы описаны, то можно "пройти" по ним как бы в тапочках пользователя и посмотреть, какой именно функционал нужен на каждом этапе. Можно дополнить юзер-кейсами, но в принципе может хватить и уже имеющегося описания — особенно, если процессы не сильно сложные.
Собственно, почти всё. Что у нас получилось? Больше, конечно, описание work flow. Чтобы это были именно процессы, нужно дополнить картину набором показателей — и промежуточных, и конечных. Т.е. как исполнением процесса достигается нужная цель (или не достигается и почему).
Дальше можно тестировать, корректировать и внедрять.
Другими словами, есть желание описать процессы для дальнейшего их анализа и возможной оптимизации и/или автоматизации.
При этом по каким-то причинам речь о процессах верхнего уровня не стоит, по крайней мере в данный момент и в рамках данной конкретной задачи (нет средств, нет понимания, зачем это нужно, нет желания, эти процессы уже описаны и исправлять их нет смысла и т.п.), — т.е. данная заметка продолжение предыдущей, про описание процессов без процессов верхнего уровня.
Важное замечание: это по сути изложение методики, которая родилась у меня на основании опыта работы фрилансером-консультантом, я не прочитал о ней в книгах (я наверняка о многом еще не прочитал, литературы на эту тему огромное количество, она объемна, часто сложна и, что самое плохое, может очень быстро устаревать и терять актуальность), поэтому принимайте ее на свой страх и риск, проверяйте и относитесь критично. Возможно, также, что что-то похожее используется другими — ничего не могу об этом сказать.
Итак, начинать необходимо с определения целей и рамок проекта (лучше сразу мыслить в понятиях проекта — как чего-то, что имеет понятные цели и предсказуемое окончание). Почему? Потому что иначе очень легко "улететь в облака". Это тем более важно, если вы сторонний специалист, а не работаете в компании за зарплату. Кроме того, как говорится, если вы не знаете, куда идете, то даже если придете, — как узнаете, что уже пришли?
Т.е. задача должна быть сформулирована корректно (например, в рамках принципов SMART), проект должен подразумевать четко очерченную цель и понимание, каково должно быть завершение проекта. Обращаю внимание, в идеале, это, конечно, должен быть результат, но лучше, если помимо желаемого результата будет описание именно завершения проекта: будьте реалистами, результат достигается не всегда.
Лучше явно указать, зачем это всё надо. Т.е. цель должна отражать не только желаемый результат, но и почему он вообще нужен. Звучит странно, т.к. часто речь идет об очевидных вещах (обычно это эффективность), но явное описание понадобится в будущем, когда придется принимать решение, делать что-то или нет, сколько на это тратить времени и сил, — всегда можно будет посмотреть — а почему изначально всё затевалось? Нужно ли это для достижения заданной цели? Стоит ли оно того?
Далее, конечно, вы можете быть одновременно исполнителем и заказчиком. Но вообще-то это грустно. Вам не на кого будет "опереться в разговоре". Истина рождается в сомнении и дискуссии, для ее качества необходима конструктивная оппозиция, другая сторона.
Поэтому совет:
- если вы сами и заказчик, и исполнитель (т.е. делаете всё для себя), то уделите больше внимания на критичные показатели и обратную связь от участников процесса и всех, кто с ним связан (клиенты, партнеры и т.д.);
- если вы — "естественный" заказчик (т.е. собственник бизнеса, топ-менеджер или и то, и другое) — лучше найдите хорошего исполнителя, которому поставьте задачу (и сразу увидите, насколько корректна уже сама постановка задачи, как это выглядит со стороны и т.п.);
- если вы — инициативный сотрудник (в т.ч. руководитель, но не топ или не собственник) — попробуйте "продать" вашу идею выше, руководителю или собственнику; другими словами, сделайте заказчика из него; особенно важно, если ваших полномочий недостаточно для внедрения проекта, — 99% вероятность даже в случае блестящего исполнения, но без согласования с руководством, что проект не даст результат — такова жизнь (про оставшийся удачный процент можно будет писать вдохновляющие статьи или даже книги, в стиле "смотрите, какие бывают чудеса").
Итак, рамки проекта должны включать примерно следующее:
- проблематика и актуальность (почему это всё нужно);
- что предполагается сделать;
- каков ожидаемый результат;
- как он будет выглядеть и как его можно будет оценить;
- какие будут выделены ресурсы (если вы сторонний специалист, то тут нужно поточнее), в том числе по времени;
- каково будет завершение проекта;
- и так далее, что вообще присуще любому проекту, но не принципиально для описания данной методики.
Предположим, цель проекта не совсем внятна (увы, именно так часто и бывает) и звучит примерно так:
- почему? — отдел не дает нужный результат, положение ухудшается;
- что? (вообще) — нужно разобраться более детально в работе отдела;
- что? (конкретно) — для этого для начала нужно описать процессы отдела (или процесс);
- зачем? — чтобы видеть более детальную картину и иметь возможность на ее основании построить анализ;
- зачем? — на основании этого анализа, возможно, принять решение об изменении процесса (оптимизации) и, возможно, его автоматизации, в той или иной мере;
- зачем? — чтобы тем самым повысить эффективность (отношение результата к затратам) или результат (примечание: иногда результат нужен во что бы то ни стало, тогда речь идет не столько об эффективности, сколько о результативности);
- каков ожидаемый результат (проекта)? — вот перечень показателей на запланированный период или дату;
- как будет выглядеть результат (проекта)? — диаграммы процессов с их текстовым описанием и указанием, какие действия можно будет учитывать и оценивать (= какие показатели можно будет анализировать) в дальнейшем, для принятия решения; плюс рекомендации, сделанные уже в ходе первичного изучения процесса и его описания;
- ресурсы? — столько-то времени, столько-то денег (включая гонорар, в случае стороннего специалиста); сотрудники будут обязаны давать интервью и обратную связь, а также отвечать за качество информации;
- как будет проходить работа? — описание формата работы исполнителя;
- как будет выглядеть окончание? — отчет в заданную дату, включающий наличные на тот момент документы по проекту, рекомендации и краткий первичный анализ; исполнитель будет обязан предоставить наличные документы и отчет по работе, заказчик будет обязан их принять, учитывая то, что это совместная работа.
Естественно, в случае стороннего консультанта там могут быть важные дополнения и подробности, но, как уже было сказано выше, это не принципиально для методики.
Следующий шаг — определение ключевых (для процесса) специалистов и интервью с ними. Причем, из практики: список интервьюируемых может пополняться в ходе работы, поэтому не обязательно стремиться к тому, чтобы он изначально был точным и исчерпывающим.
На основании интервью уже можно рисовать диаграммы — желательно уже сразу добавлять к ним более подробное описание. Насколько подробное — зависит от задачи. Не стоит вдаваться в детали там, где это не пригодится в будущем.
Тот же самый разумный прагматизм имеет смысл применять и к описанию некоторых процессов или процедур: если не этот процесс или процедура главные, то вопрос, насколько детально нужно их описывать и даже вообще, нужно ли их описывать. Возможно, просто оставить в более общем виде, не теряя ни времени, ни сил.
Уже при составлении первых диаграмм может стать понятно, где можно оптимизировать процесс. Особо с выводами спешить не стоит, но некоторые вещи не только просматриваются сразу, но и наверняка знакомы сотрудникам — просто либо руки не доходили, либо не было убедительных доводов, либо не было общей картины и не было понятно влияние на другие вещи.
Чаще всего интервью — не разовый процесс, т.к. может понадобиться уточнять некоторые моменты. Особенно в случаях, когда точка зрения на происходящее различна у собственно исполнителей и их руководства.
К диаграммам может быть удобно добавлять подробные описания тут же — некоторые инструменты такое позволяют.
Проект очерчен, интервью проведены, процессы описаны — самое время вспомнить, зачем всё это затевалось. Если для анализа — сделать такой анализ. Возможная оптимизация — подготовить рекомендации по оптимизации. Автоматизация — тут могут быть нюансы, в частности, важно понимать, что никакая часть функционала не оказалась за бортом. Если все нужные процессы описаны, то можно "пройти" по ним как бы в тапочках пользователя и посмотреть, какой именно функционал нужен на каждом этапе. Можно дополнить юзер-кейсами, но в принципе может хватить и уже имеющегося описания — особенно, если процессы не сильно сложные.
Собственно, почти всё. Что у нас получилось? Больше, конечно, описание work flow. Чтобы это были именно процессы, нужно дополнить картину набором показателей — и промежуточных, и конечных. Т.е. как исполнением процесса достигается нужная цель (или не достигается и почему).
Дальше можно тестировать, корректировать и внедрять.
