Процессами верхнего уровня обычно называют наиболее общее описание процессов, причем есть разные подходы к этому и разные способы реализации.
Один принцип, "превращение входов в выходы", мы уже упоминали, для этого часто используется нотация IDEF0.
Мы сейчас не будем описывать все способы и подходы — просто рассмотрим практические аспекты в том случае, если в компании или организации до этого процессы вообще никак не описывались или описывались слишком поверхностно и несистемно.
Прежде всего, давайте зададим себе два вопроса: почему мы это хотим это сделать (описать процессы верхнего уровня) и зачем нам это надо или может понадобиться.
Между прочим, очень часто эти простые вопросы ставят в тупик и вынуждают говорить какие-то общие фразы в ответ.
В какой-то момент покажется, что я хочу вас отговорить делать это описание вообще, но это не так. Просто важно полностью осознавать, зачем это делается. И интересно понимать, почему обычно ставится такая задача.
Почему — очень часто потому, что начинать с общего легче, чем сразу с деталей. Имея общую схему перед глазами, проще двигаться дальше. Поэтому часто, особенно люди с аналитическим мышлением, хотят иметь какой-то костяк, на который они будут опираться в дальнейшем.
Кстати, это вполне приемлемый вариант и для ответа на вопрос "зачем". Но возможны и другие: например, для того, чтобы иметь перед глазами структуру организации не только в кадровом смысле, но и в смысле процессов.
Важный практический аспект: в этом деле можно очень далеко зайти и быстро углубиться в дебри. Поэтому соизмеряйте важность вопроса с планируемыми затратами времени и ресурсов на его решение. Если это просто будет скелет, чтобы понимать, как двигаться дальше, мой совет — не мучайтесь и сделайте это быстро и просто. Не добивайтесь идеальной точности там, где она вам просто не нужна. Не тратьте время на то, что выполняет роль первого шага и дальше, возможно, не пригодится.
Если у вас производство или сложная цепочка поставок, там ответ на вопрос "зачем" будет, скорее всего, другим: правильно построенные процессы верхнего уровня можно декомпозировать и видеть не только более полную, но и более детальную картину.
В таком случае можно использовать как упомянутую выше нотацию IDEF0, так и, например, цепочку поставок или цепочку создания ценности. По сути, это тоже вариант процессного подхода.
Не будем углубляться в детали, просто еще раз напомню: всегда держите в голове вопрос "зачем". Скорее всего, ответ содержит в том числе какой-то предел, до которого имеет смысл описывать процессы, а дальше это занятие будет занимательным, но бесполезным.
Очень здорово попробовать, например, описать архитектуру компании. А зачем? Обычно это актуально для очень больших организаций, даже, я бы сказал, для "организаций организаций", т.е. которым актуальна систематизация и унификация различных своих составляющих, иначе управление слишком затруднено (типичный пример — гос. структуры).
А чем поможет фреймворк Закмана для описания процессов, скажем, дизайн студии? :)
Будет ли оправданным попытаться описать с помощью TOGAF архитектуру службы доставки пиццы?
Уверяю вас, это будет очень интересно, любознательные сотрудники будут благодарны за ценный опыт, но вряд ли это будет оправданно и полезно. Не исключаю, конечно, если речь не о службе доставки при кафе, а о национальной сети, но еще раз — надо четко понимать, зачем это делается.
Еще один вариант ответа на вопрос "зачем" — это нужно IT-отделу или разработчикам, чтобы понимать, какие будут задействованы информационные системы. Кстати, там, по понятным причинам, более оправданно будет использовать диаграммы потока данных (DFD).
Вообще, если хотя бы одна из причин так или иначе связана с ИТ, то для описания процессов верхнего уровня часто используют DFD.
Если в корне причин стоят управленческие задачи, то описание может быть довольно схематичным и представлять из себя по сути отдельные аспекты деятельности: маркетинг, продажи, доставка, сервис и т.п. В этом случае бывает удобно разделить процессы на основные (создают ценность), управленческие и вспомогательные ("обслуживают" основные).
На это увлекательное и непростое занятие можно потратить почти бесконечное количество времени и других ресурсов, особенно, если вам будет кто-то помогать 😉, поэтому важно с самого начала соизмерять цели, предполагаемые результаты и планируемые затраты.
Если вам хочется оптимизировать работу вашего сайта и магазинов, почему бы не ограничиться простой и приблизительной схемой, которая будет нужна просто для того, чтобы на нее время от времени оглядываться, не упущено ли что-то важное, но больше она ни для чего не пригодится?
Понятно, что если вы, к примеру, — крупная телекоммуникационная компания, то задачи держать всю работу в единообразном состоянии, понятном не только различным своим подразделениям, но и поставщикам, и разного рода партнерам, — и намного более актуальны, чем в случае малого или среднего бизнеса, и существенно сложнее. Если интересно, для примера можете посмотреть eTOM — это отдельный фреймворк именно для телекома.
А что если вы, скажем, — городская сеть химчисток? Мое скромное мнение относительно процессов верхнего уровня — keep it simple, не усложняйте и старайтесь держать их максимально отвечающими задачам. Возможно, это описание вам нужно всего лишь для начального толчка и больше ни для чего другого.
Какая есть еще серьезная проблема с процессами верхнего уровня: очень часто их не получается корректным образом декомпозировать до нижнего уровня — или это становится слишком сложной задачей. Вернее так: относительно понятно это получается в случае производства (и то не всегда). Т.к. там процесс почти всегда — прямая линия, с очень редкими ответвлениями. Но и там возникают проблемы с т.н. кросс-функциональными процессами — когда в процессе участвуют несколько подразделений разного направления. И кто будет т.н. хозяином процесса, и как будет реализована ответственность, и что делать, когда процесс на верхнем уровне отображает как бы одну деятельность, а участвуют в нем функции, за которыми закреплены вообще другие виды деятельности, как разобраться с тем, что на верхнем уровне, к примеру, сырье, детали, заготовки, данные, а на нижнем приходится привязываться к событиям, и т.п.
Поэтому довольно часто провал проекта по описанию процессов в крупной компании выглядит примерно так: описаны процессы верхнего уровня, предприняты упорные и настойчивые попытки их декомпозировать и одновременно описать процессы нижнего уровня, рождено огромное количество документов, проведена интереснейшая работа, о которой сотрудники будут вспоминать с благодарностью или ненавистью, основная часть результатов проделанной работы осталась либо в незаконченном виде (если проект невозможно завершить, то приходится его просто прекращать), либо валяется в совершенно ненужном состоянии, их никто не использует.
При этом руководство не считает такую ситуацию провалом, а хоть и считает, то нет смысла об этом всем рассказывать, поэтому вряд ли вы об этом услышите, если сами не были участником.
Если кому интересно, возможно ли вообще, теоретически то есть, "связать" процессы верхнего и нижнего уровней, то ответ есть — да, если они построены и описаны корректно, то это возможно. Только есть один нюанс: если задача стоит именно так, то оказывается, что проще вначале описать процессы на самом нижнем уровне, на "событийной" основе, а потом, к примеру, собрать все данные, используемые в начальных событиях, для взаимодействия между пулами и что получается на выходе, — и уже на основе этих данных построить процесс верхнего уровня в виде DFD.
Кстати, в нотации BPMN наличие т.н. "хореографии" (взаимосвязей на уровне процессов), помимо "оркестровки" (связей в пределах процесса), как раз призвано в т.ч. решить каким-то образом задачу построения процессов верхнего уровня и, с учетом того, что связь между пулами только на "информационном" уровне, по сути, есть определенной разновидностью диаграм потока данных.
А можно ли описать наоборот, от верхнего уровня к нижним? Тоже можно, но тут важно, чтобы процессы были уже построены более-менее логично, иначе легко запутаться. Также немаловажно чтобы тот, кто описывает, уже имел какой-то опыт (т.е. понимал, что примерно должно получиться в итоге и с чем он столкнется при описании). И самое главное понимать — а зачем это нужно. Если для последующей декомпозии на нижний уровень, и при этом начать с нижнего уровня будет с практической точки зрения точнее, — то смысл?
В общем, если на вопрос, "зачем нам нужно описание процессов на верхнем уровне" четкого и внятного ответа нет, а ответ на вопрос, почему это всё затеялось, выражается не вполне осознанным желанием что-то и где-то поменять, чтобы как-то всё улучшить, — лучше еще раз хорошо подумать над этим, посмотреть информацию об этом или, возможно, пригласить специалиста, чтобы уже он помог "вытянуть" смутно осознаваемую потребность наружу.
Так или иначе, если вы руководитель, сделали это всё описание, своими или привлеченными силами, то, возможно, в какой-то момент, когда вы придете к своему ИТ-специалисту, он вам задаст простой вопрос: а какую задачу это решает?
Надо сказать, не сильно удобный, но очень полезный вопрос. :) Особенно, если задавать его себе своевременно. :)
Один принцип, "превращение входов в выходы", мы уже упоминали, для этого часто используется нотация IDEF0.
Мы сейчас не будем описывать все способы и подходы — просто рассмотрим практические аспекты в том случае, если в компании или организации до этого процессы вообще никак не описывались или описывались слишком поверхностно и несистемно.
Прежде всего, давайте зададим себе два вопроса: почему мы это хотим это сделать (описать процессы верхнего уровня) и зачем нам это надо или может понадобиться.
Между прочим, очень часто эти простые вопросы ставят в тупик и вынуждают говорить какие-то общие фразы в ответ.
В какой-то момент покажется, что я хочу вас отговорить делать это описание вообще, но это не так. Просто важно полностью осознавать, зачем это делается. И интересно понимать, почему обычно ставится такая задача.
Почему — очень часто потому, что начинать с общего легче, чем сразу с деталей. Имея общую схему перед глазами, проще двигаться дальше. Поэтому часто, особенно люди с аналитическим мышлением, хотят иметь какой-то костяк, на который они будут опираться в дальнейшем.
Кстати, это вполне приемлемый вариант и для ответа на вопрос "зачем". Но возможны и другие: например, для того, чтобы иметь перед глазами структуру организации не только в кадровом смысле, но и в смысле процессов.
Важный практический аспект: в этом деле можно очень далеко зайти и быстро углубиться в дебри. Поэтому соизмеряйте важность вопроса с планируемыми затратами времени и ресурсов на его решение. Если это просто будет скелет, чтобы понимать, как двигаться дальше, мой совет — не мучайтесь и сделайте это быстро и просто. Не добивайтесь идеальной точности там, где она вам просто не нужна. Не тратьте время на то, что выполняет роль первого шага и дальше, возможно, не пригодится.
Если у вас производство или сложная цепочка поставок, там ответ на вопрос "зачем" будет, скорее всего, другим: правильно построенные процессы верхнего уровня можно декомпозировать и видеть не только более полную, но и более детальную картину.
В таком случае можно использовать как упомянутую выше нотацию IDEF0, так и, например, цепочку поставок или цепочку создания ценности. По сути, это тоже вариант процессного подхода.
Не будем углубляться в детали, просто еще раз напомню: всегда держите в голове вопрос "зачем". Скорее всего, ответ содержит в том числе какой-то предел, до которого имеет смысл описывать процессы, а дальше это занятие будет занимательным, но бесполезным.
Очень здорово попробовать, например, описать архитектуру компании. А зачем? Обычно это актуально для очень больших организаций, даже, я бы сказал, для "организаций организаций", т.е. которым актуальна систематизация и унификация различных своих составляющих, иначе управление слишком затруднено (типичный пример — гос. структуры).
А чем поможет фреймворк Закмана для описания процессов, скажем, дизайн студии? :)
Будет ли оправданным попытаться описать с помощью TOGAF архитектуру службы доставки пиццы?
Уверяю вас, это будет очень интересно, любознательные сотрудники будут благодарны за ценный опыт, но вряд ли это будет оправданно и полезно. Не исключаю, конечно, если речь не о службе доставки при кафе, а о национальной сети, но еще раз — надо четко понимать, зачем это делается.
Еще один вариант ответа на вопрос "зачем" — это нужно IT-отделу или разработчикам, чтобы понимать, какие будут задействованы информационные системы. Кстати, там, по понятным причинам, более оправданно будет использовать диаграммы потока данных (DFD).
Вообще, если хотя бы одна из причин так или иначе связана с ИТ, то для описания процессов верхнего уровня часто используют DFD.
Если в корне причин стоят управленческие задачи, то описание может быть довольно схематичным и представлять из себя по сути отдельные аспекты деятельности: маркетинг, продажи, доставка, сервис и т.п. В этом случае бывает удобно разделить процессы на основные (создают ценность), управленческие и вспомогательные ("обслуживают" основные).
На это увлекательное и непростое занятие можно потратить почти бесконечное количество времени и других ресурсов, особенно, если вам будет кто-то помогать 😉, поэтому важно с самого начала соизмерять цели, предполагаемые результаты и планируемые затраты.
Если вам хочется оптимизировать работу вашего сайта и магазинов, почему бы не ограничиться простой и приблизительной схемой, которая будет нужна просто для того, чтобы на нее время от времени оглядываться, не упущено ли что-то важное, но больше она ни для чего не пригодится?
Понятно, что если вы, к примеру, — крупная телекоммуникационная компания, то задачи держать всю работу в единообразном состоянии, понятном не только различным своим подразделениям, но и поставщикам, и разного рода партнерам, — и намного более актуальны, чем в случае малого или среднего бизнеса, и существенно сложнее. Если интересно, для примера можете посмотреть eTOM — это отдельный фреймворк именно для телекома.
А что если вы, скажем, — городская сеть химчисток? Мое скромное мнение относительно процессов верхнего уровня — keep it simple, не усложняйте и старайтесь держать их максимально отвечающими задачам. Возможно, это описание вам нужно всего лишь для начального толчка и больше ни для чего другого.
Какая есть еще серьезная проблема с процессами верхнего уровня: очень часто их не получается корректным образом декомпозировать до нижнего уровня — или это становится слишком сложной задачей. Вернее так: относительно понятно это получается в случае производства (и то не всегда). Т.к. там процесс почти всегда — прямая линия, с очень редкими ответвлениями. Но и там возникают проблемы с т.н. кросс-функциональными процессами — когда в процессе участвуют несколько подразделений разного направления. И кто будет т.н. хозяином процесса, и как будет реализована ответственность, и что делать, когда процесс на верхнем уровне отображает как бы одну деятельность, а участвуют в нем функции, за которыми закреплены вообще другие виды деятельности, как разобраться с тем, что на верхнем уровне, к примеру, сырье, детали, заготовки, данные, а на нижнем приходится привязываться к событиям, и т.п.
Поэтому довольно часто провал проекта по описанию процессов в крупной компании выглядит примерно так: описаны процессы верхнего уровня, предприняты упорные и настойчивые попытки их декомпозировать и одновременно описать процессы нижнего уровня, рождено огромное количество документов, проведена интереснейшая работа, о которой сотрудники будут вспоминать с благодарностью или ненавистью, основная часть результатов проделанной работы осталась либо в незаконченном виде (если проект невозможно завершить, то приходится его просто прекращать), либо валяется в совершенно ненужном состоянии, их никто не использует.
При этом руководство не считает такую ситуацию провалом, а хоть и считает, то нет смысла об этом всем рассказывать, поэтому вряд ли вы об этом услышите, если сами не были участником.
Если кому интересно, возможно ли вообще, теоретически то есть, "связать" процессы верхнего и нижнего уровней, то ответ есть — да, если они построены и описаны корректно, то это возможно. Только есть один нюанс: если задача стоит именно так, то оказывается, что проще вначале описать процессы на самом нижнем уровне, на "событийной" основе, а потом, к примеру, собрать все данные, используемые в начальных событиях, для взаимодействия между пулами и что получается на выходе, — и уже на основе этих данных построить процесс верхнего уровня в виде DFD.
Кстати, в нотации BPMN наличие т.н. "хореографии" (взаимосвязей на уровне процессов), помимо "оркестровки" (связей в пределах процесса), как раз призвано в т.ч. решить каким-то образом задачу построения процессов верхнего уровня и, с учетом того, что связь между пулами только на "информационном" уровне, по сути, есть определенной разновидностью диаграм потока данных.
А можно ли описать наоборот, от верхнего уровня к нижним? Тоже можно, но тут важно, чтобы процессы были уже построены более-менее логично, иначе легко запутаться. Также немаловажно чтобы тот, кто описывает, уже имел какой-то опыт (т.е. понимал, что примерно должно получиться в итоге и с чем он столкнется при описании). И самое главное понимать — а зачем это нужно. Если для последующей декомпозии на нижний уровень, и при этом начать с нижнего уровня будет с практической точки зрения точнее, — то смысл?
В общем, если на вопрос, "зачем нам нужно описание процессов на верхнем уровне" четкого и внятного ответа нет, а ответ на вопрос, почему это всё затеялось, выражается не вполне осознанным желанием что-то и где-то поменять, чтобы как-то всё улучшить, — лучше еще раз хорошо подумать над этим, посмотреть информацию об этом или, возможно, пригласить специалиста, чтобы уже он помог "вытянуть" смутно осознаваемую потребность наружу.
Так или иначе, если вы руководитель, сделали это всё описание, своими или привлеченными силами, то, возможно, в какой-то момент, когда вы придете к своему ИТ-специалисту, он вам задаст простой вопрос: а какую задачу это решает?
Надо сказать, не сильно удобный, но очень полезный вопрос. :) Особенно, если задавать его себе своевременно. :)
No comments:
Post a Comment