Правила описания бизнес процессов: Что такое бизнес-процесс и описание бизнес процесса / Trinion corporate blog / Habr – Как описать бизнес процесс
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_7",blockId:rtbBlockID,pageNumber:7,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_7").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_7");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
Как описать бизнес процесс
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_6",blockId:rtbBlockID,pageNumber:6,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_6").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_6");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
Существует два диаметрально противоположных подхода к началу описания бизнес-процесса. Некоторые учебники рекомендуют сначала описать все текстом, пошагово, и только потом переходить к графике. Другие советуют сразу моделировать графическую нотацию, а потом описывать ее текстом по мере необходимости.
Я считаю, что начинать с текста – это путь в никуда. Потому что вы таким образом получаете на первом этапе много текстовой информации, в которой даже самому можно запутаться. Кстати, это происходит не так редко, как может показаться. Тем более, ваши заказчики будут долго и с трудом разбираться, что вы им хотите донести.
Другое дело – графическая нотация, где наглядно видно, какое действие выполняется на каждом этапе, где находится «условная вилка» и т.д. В этом случае любые ошибки и недочеты становятся очень заметны.
Я рекомендую такую последовательность действий:
- Цель описания бизнес процесса
- Цели бизнес процесса
- Поговорить с руководством в отделах которые работают в бизнес процессе
- Поговорить с сотрудниками
- Выявить наиболее важные задачи бизнес процессе
- сделать первый вариант бизнес процесса
- Выявить начало и конец процесса, начало должно быть только одно, финалов много.
- Составить список задач с условиями
- Обсудить детали с руководством и с ключевыми сотрудниками
- представить финальный вариант
- Подготовить текстовое описание бизнес процесса
Такой подход экономит время и вам, и заказчику. И что еще важнее, гарантирует взаимопонимание. Но давайте разберемся шаг за шагом, с чего начинать и как действовать.
1. Описать цель описания бизнес процесса
Цель описания бизнес процесса ни в коем случае не надо путать с целью самого бизнес-процесса. Это разные этапы работы.
Цель описания бизнес-процесса – это задача, которая стоит перед вами. Например, это может быть автоматизация процесса продажи, автоматизация приема заявки, процесса управления снабжением и т.д.
Также целью описания может быть не автоматизация, а реинжиниринг или, говоря проще, оптимизация бизнес-процесса. В этом случае вам сначала понадобиться сделать описание «как есть», и только потом его оптимизировать.
Примеры подобных задач: «Оптимизация процесса бизнес-контроля» или «Реинжиниринг процесса планирования».
Т.е. первый этап – это четкое понимание, а еще лучше, сразу краткое текстовое описание того, зачем вы вообще выполняете эту работу.
2. Описать цели бизнес процесса
Теперь необходимо четко обозначить цели самого бизнес-процесса. Т.е. те финальные результаты, к которым необходимо прийти.
Напоминаю, что в отличие от технологического процесса у бизнес-процесса может быть несколько финалов. Но их число всегда ограничено, и все их необходимо перечислить.
Очень важно, чтобы бизнес-процесс начинался и завершался так, как было запланировано. По сути, таким образом, мы обозначаем точку «выхода», т.е. то, что мы обязательно должны получить в том или ином случае.
Например, процесс продажи или обслуживания клиента может иметь два очевидных финала:
- Сделка завершена успешно.
- Сделка проиграна (клиент отказался от сотрудничества).
Оба эти финала должны быть запланированы заранее. Причем, в случае проигранной сделки, обязательно нужно заранее определить, в каких случаях может возникнуть такой вариант выхода из бизнес-процесса, ведь заказчик может отказаться от сделки на разных этапах и по разным причинам. Здесь очень важно определить оптимальные варианты выхода из сделки.
Почему так важно четко определить цели бизнес процесса? Очень важно в любом процессе на выходе получить максимум информации о том, как он проходил, где и на каком этапе завершился, где и по каким причинам он сорвался, или, наоборот, что сделали, чтобы процесс прошел успешно.
3. Поговорить с руководством отделов, которые работают в бизнес процессе
Теперь, когда поставлены все необходимые цели, пришло время обсудить нюансы работы с руководителями отделов, которые будут учувствовать в бизнес-процессе.
Важно понимать, что где бы и с кем вы ни работали, вы всегда будете сталкиваться с определенной иерархией внутри организации. Скорей всего, первый этап переговоров у вас будет происходить на уровне руководства. Но дальше вам необходим контакт с подразделениями, которые задействованы в бизнес-процессе. Нужно выявить тех сотрудников, которые будут учувствовать в нем непосредственно. Для этого вам понадобится общение с руководителями этих подразделений.
Важно понимать что иногда вам не нужно будет говорить с каждым с кем запланировано, кто нибудь из руководства может вам рассказать и за себя и за других людей. Соблюдайте меру, не будьте роботом.
4. Поговорить с сотрудниками
Далее, уже с согласия и, возможно, при участии этих руководителей, имеет смысл пообщаться с лучшими сотрудниками. Я их называю обычно «звезды». Это те люди, которые в текущих условиях выполняют свою работу наиболее эффективно. Информация от них поможет вам понять, как составить бизнес-процесс наилучшим образом.
Список звезд вы должны получить от руководства отделов, это может быть один или несколько человек.
5. Выявить наиболее важные задачи в бизнес-процессе
На основе собранных интервью сотрудников и руководства подразделений нужно определить наиболее важные и значимые задачи.
Здесь важно понимать, что каждый сотрудник считает свою работу – самой важной. Почти все уверены, что именно качество их работы лежит в основе результатов коллег и других подразделений. С психологической точки зрения это вполне понятно, более того, разумный руководитель даже стимулирует такое отношение к своей работе у подчиненных.
Но вам важно понять, что действительно значимо с точки зрения бизнес-процесса, а что – нет. Иначе, если вы будете записывать каждое мелкое действие каждого сотрудника, вы сами «заблудитесь» в собственных заметках или переплетениях графической нотации, перегруженной лишними подробностями.
Скорей всего, вам совсем не нужно знать, когда по правилам сотрудник перезагружает компьютер или какой из бланков он использует для оформления делового письма, а какой – для коммерческого предложения. В случае необходимости такие мелкие подробности можно будет уточнить потом, например, для программиста, который будет создавать форму делового письма.
Учитесь выявлять важное и отсекать ненужное. Что именно на самом деле важно, в каждой организации и в каждой ситуации индивидуально. Вы – специалист, и вы должны уметь выявлять то, что действительно требуется для моделирования бизнес-процесса. При этом вы будете исходить из контекста, из поставленной задачи, из ресурса финансового и временного и т.д.
Очень важно понимать что на самом деле вы всегда сможете добавить что то, даже если вы убрали это ранее. Ведь при обсуждении вам скорее всего укажут на вашу недоработку тот кого вы до этого интрвьюировали.
6. Выявить начало и конец процесса
Вы уже определяли цели процесса, теперь, после общения с сотрудниками компании-заказчика, их можно и даже нужно уточнить. Кроме того, на этом этапе нужно четко обозначить начало процесса, с учетом всех входящих данных.
Помните: финалов у бизнес-процесса может быть несколько, начало – всегда одно. В принципе в пункте 2 вы уже описали финалы, но важно понимать что на данном этапе вы пишете конкретно где и сколько будет финалов.
7. Составить список задач с условиями
Определите основные задачи, которые должны быть решены для достижения результата. Вы уже представляете, как работают сотрудники компании. Опыт и знания позволяют вам понять, как они должны работать, например, после внедрения автоматизации. И вы можете определить «ключевые моменты».
Например, в процессе продажи это может быть получение контактных данных у лида, чтобы иметь возможность вести с ним переговоры. Далее, согласование цены или ассортимента и т.д.
Условия или развилки — это места в в вашем описании бизнес процесса где действия процесс будет делиться в зависимости от условия. Обычно условия могут быть “или” или “и”. В зависимости от нотации количество видов развилок может варьироваться.
8. Сделать первый вариант бизнес процесса
Пришло время заняться созданием самого бизнес-процесса. Я обычно называю первый вариант черновым, но, тем не менее, показываю заказчикам. Именно в качестве черновика.
Необходимо уметь донести до своих клиентов, что это такое и зачем вы им показываете «черновик». Они должны понимать, что вы – специалист в своем деле, но не в особенностях работы их бизнеса. И только совместная работа над бизнес-процессом поможет добиться наилучшего результата. Потому вы составляете «черновой» вариант бизнес-процесса, а они его изучают, скорей всего, на уровне руководителей тех самых подразделений, которые будут по этой схеме работать. И вносят свои пожелания и уточнения.
На своем опыте я также понял, что оптимальное решение – разослать черновой вариант бизнес-процесса заранее всем заинтересованным лицам, например, за 1-2 дня до дня встречи или онлайн-конференции. Графические нотации читаются просто, они понятны интуитивно даже не специалистам, особенно, если составлены грамотно. Нужно стараться делать ваши нотации как можно более понятными. Впрочем, при необходимости вы можете составить краткое пояснение для каких-то сложных или особо важных этапов.
Дайте людям время на изучение бизнес-процесса. Пусть они составят свои вопросы и уточнения заранее. Конечно, никто не гарантирует, что они найдут время и прочитают нотацию заранее. Но все же старайтесь сделать так, чтобы заинтересованные люди успели ознакомиться с вашим «черновиком», и, что еще важнее, смогли понять, что именно вы предлагаете.
9. Обсудить детали с руководством и с ключевыми сотрудниками
Далее следует этап обсуждения. Здесь важно, с одной стороны, внимательно прислушиваться к мнению руководителей подразделений и самих сотрудников, учитывать нюансы, которые вы могли не совсем верно понять при первом интервью. Но также помните, что эксперт в этом случае – вы. Именно вы знаете, как лучше. А потому везде, где сотрудники компании будут стремиться вернуть процесс на «привычные рельсы», а они будут это делать с высокой вероятностью, проявляйте твердость. Они хорошо знают «как есть», а вы – «как должно быть».
10. Представить финальный вариант
Черновых вариантов может быть более одного, особенно, если бизнес-процесс сложный и специфический. Но в любом случае, этот процесс согласования не может продолжаться бесконечно. Лучше всего, если заказчик будет понимать заранее, что вы готовы дорабатывать 1,2 или 3 раза. Но не более. Тогда и обсуждение будет максимально конструктивным.
После согласований вы создаете финальный вариант графической нотации.
11. Подготовить текстовое описание бизнес процесса
Текстовое описание бизнес-процесса следует готовить после всех согласований. Подробно описывать имеет смысл только финальный вариант. Здесь уже вы готовите текстовое описание как документ, прилагаете к нему план работ и т.д. На основании графической нотации и этого описания вы в дальнейшем будете работать.
Правила описания бизнес-процесса
Выше я много сказал о творческом подходе, о возможностях включения условий и вариантов действий в описании бизнес-процессов. В результате может показаться, что любое описание действий человека «на работе» можно считать описанием бизнес-процесса. На самом деле, существуют строгие рамки и правила, которые определяют, можно ли назвать перечень действий описанием бизнес-процесса (в графической или текстовой форме) или нет:
- Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
- Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» — если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений. - Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.
- Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
- Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.
Все остальное зависит только от вас и потребителя описания бизнес-процесса. Если нотация соответствует перечисленным выше правилам и понятна вашему потребителю, вы создали именно то, что нужно. И это действительно описание бизнес-процесса, профессиональное и оптимальное для работы.
Вопросы и ответы
Какое количество элементов должно быть в описании бизнес-процесса?
Важно понимать, что чем больше элементов в бизнес-процессе, тем более он подробный и детальный. С другой стороны, обилие элементов делает ваш бизнес-процесс запутанным и повышает вероятность ошибки. Вы на этапе постановки задач уже определили действительно важные. Ориентируйтесь на них.
Лично я считаю, что 40-50 элементов в бизнес-процессе – это допустимый максимум. Это тот объем, который люди могут воспринять. Если необходима на каком-то этапе большая детализация, создавайте отдельные подпроцессы. Здесь главное, чтобы прочесть правильно нотацию смогли и вы, и ваши заказчики. Иначе проблем, недовольства и переделок не избежать.
Как описывать задачи текстом и делать текстовые пояснения в нотации?
Я всегда во время интервью обращаю внимание на то, какие термины, какой сленг используют сотрудники компании. Например, если они привыкли говорить «потенциальный клиент», я не буду писать «лид», хоть это одно и то же. Я постараюсь пользоваться привычной им терминологией.
В черновом варианте можно также пользоваться словами типа «платежка» вместо платежного поручения и т.д. На этом этапе самое главное – взаимопонимание. А люди всегда быстрее понимают привычный им сленг.
В финальном варианте и документе описания уже стоит применять грамотную терминологию и приложить словарь терминов (глоссарий).
В какой нотации лучше описывать бизнес-процесс?
Я считаю, что лучше всего использовать либо BPMN, либо IDEF3. Подробно я о них здесь не буду говорить, но основное отличие заключается в том, что в IDEF3 вы можете декомпозировать элементы, а в BPMN такая возможность отсутствует. С другой стороны, в BPMN вы можете создать около 40-50 элементов, т.е. подробно описать большой процесс. В IDEF3 допустимое число элементов меньше. Потому здесь не выйдет изобразить большой бизнес-процесс, зато можно часть процессов представить «черными ящиками», после чего декомпозировать их в подпроцессы.
Элементарные правила описания процессов
Правила описания процессов, которые я здесь привожу, в первую очередь, предназначены для тех, кто не использует специализированное программное обеспечение. Если для описания процессов вы пользуетесь стандартными офисными программами наподобие MS Office и MS Visio, то эта статья будет вам очень полезна.
- Карта процессов верхнего уровня отражает не более 22 – 25 процессов, включающих в себя основные процессы, вспомогательные и процессы управления.
- На карте верхнего уровня необходимо отображать взаимосвязи процессов. Взаимосвязь – это то, что производит один процесс и использует другой. Производитель – клиент. Таким образом, вы связываете основные процессы в цепочку добавленной ценности.
3. Вспомогательные процессы, как правило, поставляют свои продукты во все остальные бизнес процессы. Например, процесс «Управление персоналом» поставляет свой продукт “персонал” во все остальные процессы. В таком случае укажите на карте факт выхода процесса, но не связывайте его с другими процессами.
4. Помимо прочего на карте процессов верхнего уровня должны быть отображены:
- Продукты
- Категории клиентов
- Требования к продуктам
5. Расположение организационных единиц, которые участвуют в бизнес процессах на карте верхнего уровня, поможет в дальнейшем анализе.
Подробнее о подготовке карты процессов верхнего уровня:
6. Если вы не используете ПО для моделирования бизнес процессов и намереваетесь в дальнейшем использовать распечатанные описания процессов, настоятельно рекомендую нумеровать / кодировать процессы. Это поможет не только в соединении уровней описания, но и облегчит поиск связей в документах.
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_5",blockId:rtbBlockID,pageNumber:5,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_5").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_5");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
Пример кодировки процессов
В нашей компании мы используем следующие принципы определения кода процесса:
- Карта процессов верхнего уровня всегда имеет код А1.
- Каждый бизнес процесс на карте верхнего уровня имеет свой номер и буквенное обозначение:
- Основные процессы обозначаются буквой B (Business)
- Вспомогательные процессы имеют букву C (Costs)
- Процессы управления начинаются с буквы D(Driver)
- После буквы идет порядковый номер процесса
- Нумерация процессов сквозная, то есть не зависит от буквы процесса, нумерация идет по порядку. Так что набор процессов может быть таким: B2, B3, B4, C5, C6, D7 и т.д.
- Подпроцессы следующего уровня используют многоуровневую нумерацию. Например, подпроцессы процесса B2 будут начинаться с B2.2, B2.3 и т.д.
- После кода процесса всегда следует его название. Например, B2 Производство. А его подпроцесс «Настройка оборудования» будет иметь код B2.2
7. Понятие уровней. Уровень представляет из себя описание процесса в определенных рамках детализации. Если на первом уровне процесс описывается в виде одного блока и лишь основных входов и выходов, то чем ниже уровень описания, тем детальнее оно становится.
8. Деление процессов на уровни называется декомпозицией. Чем больше процесс декомпозирован, тем детальнее он описан.
9. Жестких правил по декомпозиции процессов по уровням нет. Тем не менее мы в своей работе выделяем 3 уровня описания бизнес процессов.
Уровни описания процессов
10. Разные уровни описания процесса размещаются на разных схемах. 1 схема = 1 лист описания.
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_4",blockId:rtbBlockID,pageNumber:4,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_4").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_4");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);См. Правила моделирования бизнес- процессов
11. Правила описания процессов говорят о том, что разные процессы могут иметь разное количество уровней описания.
12. Если нас интересует содержание подпроцесса, а не его взаимодействия с другими, то это описание представляет из себя одну схему уровня.
13. Тем не менее связи схемы на листе должны быть понятны. Должны быть обязательные пометки о том, к какому процессу и уровню относится данная схема. Частично эта проблема решается с помощью нумерации и кодификации, однако можно сделать еще удобнее. Для этого можно использовать отображение «пути» декомпозиции. Как это делается на интернет страницах.
14. Если элемент на схеме ссылается на элемент на другой схеме (странице), необходимо указать номер и название объекта, на который ссылаются. Если есть возможность автоматически вставить номер страницы, на которой располагается элемент, то стоит такую ссылку сделать. Вручную же указывать номера страниц не стоит. Нумерация страниц может быть легко нарушена, и тогда ссылки окажутся бесполезными.
15. Наименование страницы со схемой должно соответствовать системе кодирования и названия процессов.
16. Уровни заголовков страниц со схемами процесса должны соответствовать уровням описания. В таком случае с помощью функции оглавления вы сможете сразу создать структуру описания – удобную для ориентации и поиска информации.
17. Если есть возможность делать активные ссылки внутри документов, чтобы при нажатии на нее происходил переход на указанное место, то это желательно сделать. Это экономит время и удобно.
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_3",blockId:rtbBlockID,pageNumber:3,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_3").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_3");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
18. В документе со схемами и описаниями обязательно должен быть раздел с расшифровкой терминов и значков схем процессов.
19. В общем мы рекомендуем следующую структуру документов по описанию процессов:
Структура документации
20. Соотношение схем и текстового описания. Схема должна быть составлена таким образом, чтобы текстового пояснения требовалось по минимуму. Однако не всегда можно избежать текста, а порой дополнять просто необходимо. В таком случае используйте принцип сносок. Т.е. если к элементу на диаграмме есть некое текстовое пояснение дальше, то необходимо указать номер сноски. Схема и текстовые пояснения должны быть на разных листах.
21. Схема должна быть составлена таким образом, чтобы она могла разместиться на одном листе А4 и быть достаточно удобной для прочтения в таком размере. Если схема получается слишком большой, разбивайте процесс на большее количество подпроцессов.
22. Обязательно ведите историю изменений документа. История должна быть неотъемлемой частью документа.
23. Скрупулезно проверяйте изменения и названия в документе. Не должно быть такого, что в одном месте название объекта изменили, а в другом нет.
Таковы базовые правила описания процессов.
Часть 9. «Золотые правила описания бизнес-процессов»
Семь
«золотых» правил описания
бизнес-процессов
Сама
по себе методология описания
бизнес-процессов довольно проста, но
ее эффективное применение на практике
не является простой задачей. Подводные
камни, появляющиеся при описании
бизнес-процессов компании могут свести
эффективность этой работы на нет.
Возникновение подводных камней связано
с человеческим фактором, так как
большинство сотрудников компании не
заинтересованы в проведение подобных
работ в их организации.
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_2",blockId:rtbBlockID,pageNumber:2,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_2").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_2");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
Описание
бизнес-процессов дает ответы на вопросы,
кто чем занимается в компании и кто за
что отвечает. Это делает компанию
прозрачной и подконтрольной руководству.
Прозрачность в первую очередь выгодна
руководителям организации, при этом
она заставляет всех сотрудников работать
на цели организации в ущерб их личным
интересам. Более того описание
бизнес-процессов и повышение прозрачности
позволяет выявить излишки финансовых
и временных ресурсов, которые «припасли»
сотрудники» на крайний случай. Поэтому
основная часть сотрудников не
заинтересована в этой работе и при
описании деятельности компании постоянно
возникают сопротивления, препятствующие
получению реальной информации о том,
кто чем в компании занимается и кто за
что отвечает.
Что
бы уменьшить сопротивления незаинтересованных
сторон описанию бизнес-процессов нужно
использовать «золотые» правила,
которые были выведены из практического
опыта проведения подобных работ.
Правило
1. Составляйте, уточняйте, подтверждайте
схемы вместе с «владельцами»/»участниками»
бизнес-процессов.
К
работе по описанию бизнес-процессов
нужно активно привлекать специалистов,
которые участвуют в этом процессе и
отвечают за эффективность их выполнения.
Во первых, это ускорит работу и повысит
качество результатов, так как кроме
самих участников процесса никто другой
лучше не знает как бизнес-процесс
происходит на самом деле. Во вторых, на
основании разработанный описаний в
дальнейшем будет проводится оптимизация
и проведение изменений бизнес-процессов.
Одним из главных правил эффективного
проведения изменений является вовлечение
на ранних стадиях в эти работы сотрудников
участвующих в процессе и чья деятельность
будет затронута изменениями.
if(rtbW>=960){var rtbBlockID="R-A-744041-3";} else{var rtbBlockID="R-A-744041-5";}
window.yaContextCb.push(()=>{Ya.Context.AdvManager.render({renderTo:"yandex_rtb_1",blockId:rtbBlockID,pageNumber:1,onError:(data)=>{var g=document.createElement("ins");g.className="adsbygoogle";g.style.display="inline";if(rtbW>=960){g.style.width="580px";g.style.height="400px";g.setAttribute("data-ad-slot","9935184599");}else{g.style.width="300px";g.style.height="600px";g.setAttribute("data-ad-slot","9935184599");} g.setAttribute("data-ad-client","ca-pub-1812626643144578");g.setAttribute("data-alternate-ad-url",stroke2);document.getElementById("yandex_rtb_1").appendChild(g);(adsbygoogle=window.adsbygoogle||[]).push({});}})});
window.addEventListener("load",()=>{
var ins=document.getElementById("yandex_rtb_1");if(ins.clientHeight =="0"){ins.innerHTML=stroke3;}},true);
Правило
2. Используйте визуальные подходы
описания бизнес-процессов, способствующие
повышению эффективности работы в группе.
При
описании бизнес-процессов нужно
оперативно фиксировать и визуализировать
полученную информацию. Работая в группах,
можно использовать флипчарт или доску,
на которых в процессе работы рабочей
группы будет разрабатываться и
фиксироваться описание бизнес-процесса.
Большой эффективностью обладает подход,
связанный с использование мультимедийного
проектора при помощи которого изображение
схемы бизнес-процесса разрабатываемого
с помощью специализированного программного
обеспечения выводится на экран в режиме
реального времени.
Правило
3. Используйте язык, понятный
«владельцам»/»участникам»
бизнес-процесса.
При
описании бизнес-процессов нужно
использовать тот язык, ту терминологию,
которые приняты в организации. В каждой
компании есть своя специфика, есть свои
устоявшиеся названия бизнес-процессов,
функций, документов и отделов. Поэтому
рекомендуется использовать устоявшуюся
терминологию. Это сделает схемы
бизнес-процессов понятными для всех
участников процесса, что с экономит
много времени при их согласовании,
анализе и оптимизации.
Правило
4. Создавайте схемы деятельности, а не
организационных структур.
При
описании бизнес-процессов нужно «забыть»
про существующую организационную
структуру и не использовать ее как
средство выделения бизнес-процессов и
работ. Бизнес-процессы строятся на
основе стратегии, а организационная
структура подстраивается под них, но
не наоборот. Именно поэтому организационная
структура описывается и накладывается
на бизнес-процессы в последний момент.
Факт того что, она будет не состыковываться
с процессами говорит об ее неоптимальности.
Если пренебречь этим правилом и в
качестве средства выделения бизнес-процессов
и работ использовать действующую
оргструктуру, то вероятность того, что
разработанные описания бизнес-процессов
будут искажены в случае неоптимальной
организационной структуры достаточно
велика.
Давайте
рассмотрим пример одной компании, в
которой сотрудники описывали бизнес-процесс
«Поставка товара от поставщика».
При проведении этих работ встал вопрос,
что является границей этого бизнес-процесса.
Одна группа специалистов предложила в
качестве конечной границы бизнес-процесса
«Поставка» рассматривать факт
того, что поставленный товар находится
в свободной продаже, и сбытовые
подразделения могут его продавать.
Специалисты отдела закупок, которые в
большей степени участвовали в этом
бизнес-процессе пытались «натянуть»
этот бизнес-процесс под организационные
границы ответственности своего отдела
и доказывали, что границей процесса
«Поставка» является факт того, что
товар закуплен и доставлен к воротам
склада. Во втором варианте определения
границы бизнес-процесса «Поставка»
в качестве средства использовалась
действующая организационная структура,
что является не правильным, так как на
данном этапе ничего не известно о степени
ее оптимальности.
Правило
5. Избегайте излишней детализации
бизнес-процессов, особенно на схеме
«как есть».
Одной
из проблем возникающих при описании
бизнес-процессов является нарушение
оптимального уровня детализации, которое
приводит к значительному увеличению
объема работ. При этом излишняя детализация
не только не дает дополнительного
эффекта согласно закону Парето 20 на 80,
она приводит к отрицательным последствиям,
связанным с информационной перегруженностью
участников проекта, снижает качество
результатов работ и часто приводит к
не успеху всего мероприятия.
В
данном случае нужно помнить еще об одном
правиле – чем большие изменения
планируется провести при оптимизации
бизнес-процесса, тем менее детальное
описание бизнес-процесса «как есть»
должно быть разработано.
Правило
6. Избегайте составления схемы
бизнес-процесса ради схемы, не ведущей
к дальнейшему анализу и действиям.
Инструментарий
по описанию бизнес-процессов, который
был рассмотрен, является всего лишь
инструментом для достижения более
высоких целей оптимизации и улучшения
бизнес-процессов. При проведении данных
работ постоянно нужно помнить о настоящих
целях, а не зацикливаться на инструментарии
и разработке схем.
Довольно
часто встречается следующая ситуация.
В компании начинают описывать
бизнес-процессы, всем эта работа очень
нравится, все строят схемы бизнес-процессов
и организационной структуры и никому
не хочется прекращать это интересное
и приятное занятие. В данном случае
акцент смещается с решения проблем на
разработку схем. Поэтому нужно постоянно
помнить, что конечная цель — оптимизация,
а описание – это инструмент, который
нужно рассматривать как средство
достижения цели.
Давайте
рассмотрим пример описывания
бизнес-процессов в одной компании c
целью подготовки предприятия к внедрению
интегрированной информационной системы.
При описании бизнес-процессов
использовалась методология IDEF0.
Специалисты, занимающиеся описанием
бизнес-процессов долго выясняли между
собой отношения решая, возникший спорный
вопрос — к чему отнести накладную,
пришедшую с товаром от поставщика при
описании окружения бизнес-процесса
«Приемка товара». Одни считали, что
накладная является входом для
бизнес-процесса, другие считали, что
управлением. На спор ушло две недели
рабочего времени, при этом каждый остался
при своем мнении.
Правило
7. Не смешивайте понятия «как есть»,
» как должно быть», «как будет».
При
описании бизнес-процессов нельзя
смешивать понятия «как есть», «как
должно быть» и «как будет».
Согласно технологии оптимизации
бизнес-процессов первым шагом является
это описание процесса «как есть».
Поэтому нужно описывать только те
работы, только ту организационную
структуру, которая существуют на самом
деле, невзирая на их «кривизну».
Часто при интервьюировании сотрудники,
чья деятельность описывается, начинают
фантазировать и рассказывать вещи,
сильно отличающиеся от реальной
действительности. Когда их спрашиваешь
почему они поступают таким образом, они
отвечают, потому что именно так должно
быть, по их мнению. В результате этого
построенные схемы бизнес-процессов не
соответствуют действительности, что
искажает информацию и уменьшает
возможность проведения эффективной
оптимизации бизнес-процессов.
Описание бизнес процессов — типы описания
Создание бизнес процессов начинается с их описания. Описание бизнес процессов можно делать разными способами. Каждый имеет как плюсы, так и минусы. Можно выделить 3 типа описания – текстовый, табличный и графический. Естественно, в чистом виде они встречаются редко. В большинстве случаев мы комбинируем эти методы в том или ином виде. Но если вы делаете упор и берете за основу один из 3 элементов – описание текстом, таблицы или схему бизнес процесса, то тем самым вы выбираете один из типов описания.
Управление бизнес процессами без их описания крайне затруднительно.
Наверное, самый простой в реализации и распространенный вариант. Все происходящее в бизнес процессе описывается словами, т.е. в итоге у нас получается текст. Построение бизнес процессов требует описания довольно-таки большого количества элементов и вариантов развития бизнес процесса, текст может получиться весьма громоздким. Мне очень запомнился процесс, текстовое описание которого занимало 32 страницы, а схема – лишь 3.
Плюсы описания бизнес процессов текстом
- Очень просто сделать – просто садись и пиши.
- Не требует специальных навыков – темные времена прошли, теперь писать умеет каждый:)
Минусы
- Текст сложно обрабатывать – работа с массивами текста весьма сложна, ведь нам нужно найти суть, скрытую за словами.
- Затрудняет целостное восприятие процесса: читая вторую страницу, можно уже забыть, что было на первой. Очень тяжело читать текст, описывающий сложный, разветвленный процесс. Приходится постоянно возвращаться назад, чтобы понять, о чем речь. В итоге восприятие картины целиком нарушается.
- Сложно для восприятия – если текст готовит человек без писательских навыков, его прочтение превратится в пытку. У каждого свой язык, и порой он может быть очень сложен. Вы же встречали «плохие» книги? Описание процесса может быть еще хуже:)
- Сложно структурировать и анализировать – процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий мы выполняем разные действия в процессе. А теперь представьте, каково это – описывать текстом. Очень сложно сохранить простую структуру, когда у вас десяток «если» на одну страницу. В результате этого анализ потребует от вас огромных усилий и титанической предварительной работы.
Подсказка – используйте структурированные списки
Описание бизнес процессов в виде таблиц
Таблица – это здорово! Таблицы я люблю. Их можно рассматривать часами… и не найти ответ на свой вопрос:) Шучу. На самом деле описание бизнес процессов компании в виде связанных таблиц – это не такая уж плохая идея. По крайней мере, намного лучше текстового описания. Самая большая сложность заключается в том, чтобы подготовить хороший шаблон таблицы, в которую, собственно, потом уже внесут данные.
Плюсы описания бизнес процессов текстом в виде таблиц
- Относительно просто подготовить – подготовить шаблон не так сложно. Главное, чтобы он был понятен тем, кто будет его заполнять. Кроме того, все программы для работы с таблицами (например, Excel) позволяют добавлять описание к ячейкам таблицы. Используйте эту возможность для пояснений данных.
- Относительно просто заполнить шаблон – еще раз, если шаблон понятен, заполнить его не составит труда. Для этого не нужны специальные навыки и знания.
- Наличие структуры – таблица сама по себе уже предполагает некую структуру.
- Удобство обработки цифровых данных – с цифрами лучше всего работать в таблице. Так что для данного типа данных этот тип описания подходит лучше всего. Данные в таблице (даже текстовые) гораздо удобнее сравнивать и анализировать.
Минусы
- Некомпактно – описание больших процессов со всем множеством подпроцессов и элементов будет выглядеть как «простыня». Компактным такой вид назвать сложно.
- Отсутствует необходимая детализация – для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит, добиться необходимой детализации может стать непросто.
- Нет целостности восприятия – большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце, то лучше таблицы не придумать.
- Сложно отобразить ветвления – та же проблема, что и с текстом. Большое количество ветвлений и, что важно, развитие процесса исходя из условий ветвления довольно сложно отобразить наглядно.
- Требует подготовки – нужно потратить время на подготовку хорошего шаблона.
Подсказка – располагайте подпроцессы, операции в строках, а данные в столбцах. Это облегчает восприятие. Вместо одной большой таблицы используйте связанные таблицы.
Описание в виде схемы, модели бизнес процесса
Не буду тянуть кота за март. Графическое описание бизнес процессов предприятия в виде схемы, модели – лучший тип описания. Большинство специалистов уже давно отдают предпочтение именно графическому типу описания. Просто посмотрите на плюсы и минусы этого типа.
Плюсы описания бизнес процессов в виде модели
- Простота восприятия – наш мозг устроен таким образом, что картинку мы воспринимаем быстрее, чем что-либо. Поэтому схему воспринимать очень просто. Мозг «фотографирует» схему и обрабатывает ее на бессознательном уровне в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
- Целостность восприятия – 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности, о его границах, основных элементах и т.д. Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
- Необходимая и достаточная детализация – в то же время на схеме можно отобразить относительно большое количество деталей без потери качества восприятия.
- Наглядное отображение ветвлений и путей развития процесса – правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
- Удобство автоматизации – многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.
Минусы
- Требует специальных навыков – нужно знать, как правильно строить диаграммы. Знать разные нотации. А иногда даже самостоятельно сделать набор элементов и правил, которыми вы будете пользоваться для описания.
- Относительно большое время на подготовку описания – хорошо построенная модель процесса должна быть проста и понятна. Для того, чтобы сделать схему таковой, необходимо потратить кучу времени. Сложно может сделать каждый дурак, а вот простота требует мастерства;)
Инвестиции в графический тип описания окупаются весьма неплохо.
Подсказка – для описания бизнес процессов может быть достаточно 3-5 графических элементов (фигур).
В итоге
В итоге вы будете задействовать все типы описания. Документ под названием «Описание бизнес процесса…» будет содержать и графическую схему, и таблицы, и текст. Это нормально. Но мой вам совет – ориентируйтесь на графические модели и избегайте текста. Хорошая модель не нуждается в сопровождении текстом. В большинстве случаев.
Создание бизнес процессов начинается с их описания.
Введение в описание бизнес-процессов. Часть 1 — Бэкмология
Posted On 07.03.2018
Принципы всегда осуществляются медленно, но люди всегда торопятся. (О. Бальзак)
Золотые правила описания бизнес-процессов
Ковалев Сергей Михайлович
Ковалев Валерий Михайлович
(Журнал «Консультант директора», № 12, Июнь, 2004 г.)
Семь «золотых» правил описания бизнес-процессов
Сама по себе методология описания бизнес-процессов довольно проста, но ее эффективное применение на практике не является простой задачей. Подводные камни, появляющиеся при описании бизнес-процессов компании могут свести эффективность этой работы на нет. Возникновение подводных камней связано с человеческим фактором, так как большинство сотрудников компании не заинтересованы в проведение подобных работ в их организации.
Описание бизнес-процессов дает ответы на вопросы, кто чем занимается в компании и кто за что отвечает. Это делает компанию прозрачной и подконтрольной руководству. Прозрачность в первую очередь выгодна руководителям организации, при этом она заставляет всех сотрудников работать на цели организации в ущерб их личным интересам. Более того описание бизнес-процессов и повышение прозрачности позволяет выявить излишки финансовых и временных ресурсов, которые «припасли» сотрудники» на крайний случай. Поэтому основная часть сотрудников не заинтересована в этой работе и при описании деятельности компании постоянно возникают сопротивления, препятствующие получению реальной информации о том, кто чем в компании занимается и кто за что отвечает.
Что бы уменьшить сопротивления незаинтересованных сторон описанию бизнес-процессов нужно использовать «золотые» правила, которые были выведены из практического опыта проведения подобных работ.
Правило 1. Составляйте, уточняйте, подтверждайте схемы вместе с «владельцами»/»участниками» бизнес-процессов.
К работе по описанию бизнес-процессов нужно активно привлекать специалистов, которые участвуют в этом процессе и отвечают за эффективность их выполнения. Во первых, это ускорит работу и повысит качество результатов, так как кроме самих участников процесса никто другой лучше не знает как бизнес-процесс происходит на самом деле. Во вторых, на основании разработанный описаний в дальнейшем будет проводится оптимизация и проведение изменений бизнес-процессов. Одним из главных правил эффективного проведения изменений является вовлечение на ранних стадиях в эти работы сотрудников участвующих в процессе и чья деятельность будет затронута изменениями.
Правило 2. Используйте визуальные подходы описания бизнес-процессов, способствующие повышению эффективности работы в группе.
При описании бизнес-процессов нужно оперативно фиксировать и визуализировать полученную информацию. Работая в группах, можно использовать флипчарт или доску, на которых в процессе работы рабочей группы будет разрабатываться и фиксироваться описание бизнес-процесса. Большой эффективностью обладает подход, связанный с использование мультимедийного проектора при помощи которого изображение схемы бизнес-процесса разрабатываемого с помощью специализированного программного обеспечения выводится на экран в режиме реального времени.
Правило 3. Используйте язык, понятный «владельцам»/»участникам» бизнес-процесса.
При описании бизнес-процессов нужно использовать тот язык, ту терминологию, которые приняты в организации. В каждой компании есть своя специфика, есть свои устоявшиеся названия бизнес-процессов, функций, документов и отделов. Поэтому рекомендуется использовать устоявшуюся терминологию. Это сделает схемы бизнес-процессов понятными для всех участников процесса, что с экономит много времени при их согласовании, анализе и оптимизации.
Правило 4.
Визуальное моделирование бизнес-процессов
Создавайте схемы деятельности, а не организационных структур.
При описании бизнес-процессов нужно «забыть» про существующую организационную структуру и не использовать ее как средство выделения бизнес-процессов и работ. Бизнес-процессы строятся на основе стратегии, а организационная структура подстраивается под них, но не наоборот.
Именно поэтому организационная структура описывается и накладывается на бизнес-процессы в последний момент. Факт того что, она будет не состыковываться с процессами говорит об ее неоптимальности. Если пренебречь этим правилом и в качестве средства выделения бизнес-процессов и работ использовать действующую оргструктуру, то вероятность того, что разработанные описания бизнес-процессов будут искажены в случае неоптимальной организационной структуры достаточно велика.
Давайте рассмотрим пример одной компании, в которой сотрудники описывали бизнес-процесс «Поставка товара от поставщика». При проведении этих работ встал вопрос, что является границей этого бизнес-процесса. Одна группа специалистов предложила в качестве конечной границы бизнес-процесса «Поставка» рассматривать факт того, что поставленный товар находится в свободной продаже, и сбытовые подразделения могут его продавать. Специалисты отдела закупок, которые в большей степени участвовали в этом бизнес-процессе пытались «натянуть» этот бизнес-процесс под организационные границы ответственности своего отдела и доказывали, что границей процесса «Поставка» является факт того, что товар закуплен и доставлен к воротам склада.
Во втором варианте определения границы бизнес-процесса «Поставка» в качестве средства использовалась действующая организационная структура, что является не правильным, так как на данном этапе ничего не известно о степени ее оптимальности.
Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме «как есть».
Одной из проблем возникающих при описании бизнес-процессов является нарушение оптимального уровня детализации, которое приводит к значительному увеличению объема работ. При этом излишняя детализация не только не дает дополнительного эффекта согласно закону Парето 20 на 80, она приводит к отрицательным последствиям, связанным с информационной перегруженностью участников проекта, снижает качество результатов работ и часто приводит к не успеху всего мероприятия.
В данном случае нужно помнить еще об одном правиле — чем большие изменения планируется провести при оптимизации бизнес-процесса, тем менее детальное описание бизнес-процесса «как есть» должно быть разработано.
Правило 6. Избегайте составления схемы бизнес-процесса ради схемы, не ведущей к дальнейшему анализу и действиям.
Инструментарий по описанию бизнес-процессов, который был рассмотрен, является всего лишь инструментом для достижения более высоких целей оптимизации и улучшения бизнес-процессов. При проведении данных работ постоянно нужно помнить о настоящих целях, а не зацикливаться на инструментарии и разработке схем.
Довольно часто встречается следующая ситуация. В компании начинают описывать бизнес-процессы, всем эта работа очень нравится, все строят схемы бизнес-процессов и организационной структуры и никому не хочется прекращать это интересное и приятное занятие. В данном случае акцент смещается с решения проблем на разработку схем. Поэтому нужно постоянно помнить, что конечная цель — оптимизация, а описание — это инструмент, который нужно рассматривать как средство достижения цели.
Давайте рассмотрим пример описывания бизнес-процессов в одной компании c целью подготовки предприятия к внедрению интегрированной информационной системы. При описании бизнес-процессов использовалась методология IDEF0. Специалисты, занимающиеся описанием бизнес-процессов долго выясняли между собой отношения решая, возникший спорный вопрос — к чему отнести накладную, пришедшую с товаром от поставщика при описании окружения бизнес-процесса «Приемка товара».
Одни считали, что накладная является входом для бизнес-процесса, другие считали, что управлением. На спор ушло две недели рабочего времени, при этом каждый остался при своем мнении.
Правило 7. Не смешивайте понятия «как есть», » как должно быть», «как будет».
При описании бизнес-процессов нельзя смешивать понятия «как есть», «как должно быть» и «как будет». Согласно технологии оптимизации бизнес-процессов первым шагом является это описание процесса «как есть». Поэтому нужно описывать только те работы, только ту организационную структуру, которая существуют на самом деле, невзирая на их «кривизну». Часто при интервьюировании сотрудники, чья деятельность описывается, начинают фантазировать и рассказывать вещи, сильно отличающиеся от реальной действительности. Когда их спрашиваешь почему они поступают таким образом, они отвечают, потому что именно так должно быть, по их мнению.
В результате этого построенные схемы бизнес-процессов не соответствуют действительности, что искажает информацию и уменьшает возможность проведения эффективной оптимизации бизнес-процессов.
Также на сайте:
Идентификация процессов СМК
Интеграция реинжиниринга и системы менеджмента качества
Подготовлено при поддержке:
О проекте
quality.eup.ru — один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.
Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.
Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.
Добавить в «Избранное»
Рекомендуем
Наш новый проект:
Все о качестве менеджмента
Избранные книги
Реклама на сайте
Как сюда попасть?
Методы описания бизнес-процессов
Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат. В международном стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее время эти термины можно считать синонимами. Моделирование бизнес-процессов – это эффективное средство поиска путей оптимизации деятельности компании, позволяющее определить, как компания работает в целом и как организована деятельность на каждом рабочем месте. Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Для каждого объекта и связей характерны ряд параметров, или атрибутов, отражающих опредёленные характеристики реального объекта (номер объекта, название, описание, длительность выполнения (для функций), стоимость и др.).
Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки.
Основные типы методологий моделирования и анализа бизнес-процессов:
- Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.
- Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.
- Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
- Прочие методологии.
IDEF0
Модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса:
Тип интерфейса:
- Управляющая информация входит в блок сверху.
- Входная информация входит в блок слева.
- Результаты выходят из блока справа.
- Механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу.
Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Общее число уровней в модели не должно превышать 5-6.
Построение диаграмм начинается с представления всей системы в виде одного блока и дуг, изображающих интерфейсы с функциями вне системы. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.
На таких диаграммах не указаны явно ни последовательность, ни время. Метод обладает рядом недостатков: сложность восприятия (большое количество дуг на диаграммах и большое количество уровней декомпозиции), трудность увязки нескольких процессов.
IDEF3
Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции.
Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер (номер действия обычно предваряется номером его родителя, например, 1.1.). Все связи в IDEF3 являются однонаправленными и организуются слева направо.
Типы связей IDEF3:
- Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
- Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.
- Нечеткое отношение (Relationship), пунктирная стрелка.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса).
Ветвление процесса отражается с помощью специальных блоков:
- «И», блок со знаком &.
- «Исключающее ИЛИ» («одно из»), блок со знаком Х.
Что такое бизнес-процессы предприятия
- «ИЛИ», блок со знаком О.
Если действия «И», «ИЛИ» должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно — одной.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
DFD
Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки.
Также, как и в других моделях, поддерживается декомпозиция.
Основными компонентами диаграмм потоков данных являются:
- Внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад).
- Системы и подсистемы (например, подсистема по работе с физическими лицами).
- Процессы (преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом; физически это может быть, например, подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.).
- Накопители данных (абстрактные устройства для хранения информации).
- Потоки данных (на диаграмме — стрелки).
Необходимо размещать на каждой диаграмме от 3 (меньше нет смысла) до 7 (больше — не воспринимаемо) процессов, не загромождая диаграммы несущественными на данном уровне деталями. Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации. Для сложных систем (десять и более внешних сущностей, распределенная природа и многофункциональность системы) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных.
Каждый процесс на DFD может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования.
При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.
ARIS
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.
ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы.
Поддерживаемые типы моделей в ARIS:
- Организационные модели, представляющие структуру системы — иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений.
- Функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей.
- Информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы.
- Модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, UML. Процесс моделирования можно начинать с любого из типов моделей.
Основная бизнес-модель ARIS — eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты — «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.
Основные объекты нотации eEPC:
- Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
- Событие. Служит для описания реальных событий, воздействующих на выполнение функций.
- Организационная единица. Например, управление или отдел.
- Документ. Отражает реальные носители информации, например, бумажные документы.
- Прикладная система.
- Кластер информации. Характеризует набор сущностей и связей между ними.
- Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.
- Логический оператор. Оператор «И», «ИЛИ» или исключающее «ИЛИ», позволяет описать ветвление процесса.
Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования.
Для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Предусмотрены различные функции по администрированию базы данных, например, управление доступом. База данных представляет из себя иерархическое хранилище моделей.
Работа по созданию модели должна регламентироваться жёсткими и объёмными соглашениями по моделированию (стандартами), ARIS поддерживает механизм методологических фильтров, позволяющих пользователю использовать только определённый набор схем и объектов. Разработка таких соглашений требует значительного времени и высококвалифицированных специалистов. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, очень высока.
Подробная информация
Указанные нижепримеры бизнес-процессов компании используются в ознакомительных целях и не применяются на практике без дополнительной доработки. В качестве учебной модели бизнес-процесса будет представлен процесс «Управление проблемами».
Прописаны ли бизнес-процессы в вашей компании? Используетели вы приведенные ниже модели? Как данные модели могут помочь вам устарнить проблемы в вашем бизнес-процессе?
Процесс управления проблемами предприятия имеет цель устранения ошибок, своевременного обнаружения проблем и формирования комплекса мер по их решению. Здесь приведена общая схема работ для получения эффективного результата бизнес-процесса.
В начале бизнес-процесса поступает информация о зафиксированных ошибках по двум каналам:
- Система наблюдения.
- Service desk.
Процесс выполнения бизнес-процесса:
- Информационная «Система принятия решений» собирает данные о зафиксированных ошибках, присваивает категорию, выставляет приоритет и сохранят в базе данных.
- Администратор, отвечающий за информационную систему, назначает ответственный персонал за заявку о возникшей проблеме.
- Ответственный работник проводит меры по устранению проблемы и фиксирует в заявке конечный результат.
Окончание бизнес-процесса. Качественным результатом устранения проблемы является зафиксированное исполнение бизнес-процесса.
На данных примерах бизнес-процессов компании можно уловить связь используемых объектов моделирования, например, связи и общий функционал между ними. Однако есть и отличия, которые связаны с различным использованием в областях применения управления процессами предприятия.
IDEF
При помощи графического инструмента gliffy.com можно смоделировать бизнес-процесс в IDEF нотации. В этом случае модель читают слева направо. По моделям в IDEF0 и IDEF3 удобно проводить анализ процессов изменений (трансформации) состояния объектов и субъектов в бизнес-процессах. Однако, нотация IDEF0 практический никак, не отражает реакцию участников на события внешней среды в процессе. Из-за этого не получается оценить риски, связанные с изменениями во внешней среде и смоделировать варианты отката.
EPC
Обычно модель бизнес-процесса устранения проблем моделируют в визуальной EPC-совместимой нотации, в таком случае, чтение модели проходит сверху-вниз. По данной модели составляются не только требования к рабочему бизнес-процессу, но и формируется организационная структура для выполнения нескольких бизнес-процессов в компании. Широкий набор графических элементов является скорее недостатком, что оказывается сложным для понимания, в отличии от других нотацияий.
Примеры бизнес-процессов
Для разработки и чтения процессов в этой нотации необходима предварительная подготовка сотрудников.
BPMN
При моделировании бизнес-процесса в BPMN нотации с помощью сервиса bpmn.io, чтение модели происходит слева направо. Такую модель легко имплементировать в уже существующую информационную систему управления потоком работ (workflow tool). Нотация BPMN слишком сложная для восприятия , и даже специалистыс опытом ARIS/IDEF-моделирования вынуждены ее предварительно изучать.
ИС Дракон
С помощью языка ДРАКОН можно построить целостную модел бизнесс-процессов в компании. Основой ДРАКОН-схемы является простой и понятный чертеж. С помощью ДРАКОН возможно изобразить процесс в ясной и доходчивой форме. Такая форма позволяет сократить умственные усилия, необходимые для восприятия, понимания и принятия решения относительно характеристик процесса по заданным требованиям. Так же облегчается понимание описываемых процессов и обеспечивается их однозначное толкование.
Чем язык ДРАКОН для описания бизнес-процесса лучше, нежели другие схемы?
- Он понятный – легко воспринимается.
- Он простой – реально используется 5 значков, которые позволяют описывать всю логику.
- У других нотаций нет средств, которые хранят код разработки.
Данные нотации помогают заказчику принимать последовательные действия, позволяющие достичь идеального результата. Но самым простым и эффективным является Дракон, из-за простоты его восприятия, наглядностью действий и способностью получения запланированного результата.
Остались вопросы? Хотите достичь положительных результтов для вашей компании? Звоните по номеру 290-92-14, напишите нам на [email protected] или свяжитесь с нами по скайпу tubr221
Читайте также:
Схема бизнес-процессов: просто о сложном
Как оптимизировать бизнес-процесс в компании и заставить ее работать по-новому?
Как проанализировать бизнес-процессы?
Моделирование информационных систем. Позадачный и процессный подходы к моделированию информационных систем
В настоящее время существуют два подхода к построению информационных систем: позадачный и процессный. Эти подходы отражают различные взгляды на систему управления предприятием, организацией, корпорацией, офисом. Первый подход, исторически появившейся ранее, базируется на функциональной модели управления предприятием, отражающей выполнение сотрудниками своих должностных обязанностей согласно целям и функциям управления. В структуре таких ИС выделяют функциональную часть, отражающую цели и задачи управления, и обеспечивающую часть, содержащую средства решения задач
В соответствии с данным подходом ИС создается как инструмент, предназначенный для автоматизации функций управления, типовыми среди которых являются прогнозирование, планирование, учет, анализ, регулирование.
Для реализации одной функции или ее части создаются функциональные подсистемы.
Позадачный подход в управлении обладает рядом недостатков:
— размытость, а иногда и отсутствие ответственности на различных стадиях производства и реализации продукции за конечный результат управления;
— сложность увязки всех функций производства и управления в единую технологию.
В настоящее время постепенно развивается новый подход к управлению – процессный. Этот подход ориентирует на управления не отдельными структурными подразделениями предприятия, выполняющими свои функциональные обязанности, а сквозными бизнес-процессами. Эти процессы связывают воедино деятельность определенных структурных подразделений, предназначенных для производства конкретного конечного продукта или услуги. Процессный подход к управлению изменяет структуру ИС. Функциональная часть не исчезает, но принимает форму бизнес-процессов, которые поддерживаются обеспечивающими подсистемами.
Под бизнес-процессом понимается совокупность действий, выполнение которых позволяет получить конечный результат (товар или услугу). Поэтому важнейший шаг при создании ИС на основе данного подхода – выделение бизнес-процессов, которые делятся на следующие классы: основные, вспомогательные, сопутствующие.
Основные бизнес-процессы – это процессы, которые создают то главное, ради которого и существует предприятие (товар, услуга). В большинстве случаев они отражают выпуск продукции и обслуживание конечных потребителей, материально-техническое снабжение, производство, сбыт готовой продукции, послепродажные услуги и т.д.
Вспомогательные бизнес-процессы, как правило, соответствуют управленческой деятельности: планирование, учет, процессы на складе, маркетинг, финансовая деятельность и т.д.
Сопутствующими бизнес-процессами являются процессы, предназначенные для жизнеобеспечения основных и вспомогательных процессов.
Введение в бизнес-процессы. Часть 2
Например, процессы обеспечения кадрами, юридическое обеспечение и т.д.
Бизнес-процессы состоят из бизнес-операций, выполняемых с помощью АРМ. Каждый бизнес-процесс характеризуется определенными во времени началом и концом, интерфейсом с другими процессами, последовательностью выполнения бизнес-операций, а также владельцем бизнес-процесса, т.е. лицом, которое несет ответственность за его выполнение. Их выделение и их увязка позволяют получить единую многоуровневую бизнес-модель предприятия, под которым понимается структурированное графическое описание сети процессов и операций, связанных документами, информационными потоками и организационными предписаниями. Такая информационная сеть отражает деятельность структурных подразделений предприятия.
Моделирование бизнес-процессов состоит в последовательном отражении всех бизнес-операций. Управление бизнес-процессами называется инжинирингом бизнеса. Исследования последних лет показали, что повышение производительности за счет использования информационных технологий достигается очень редко. Главная причина в том, что новые информационные технологии часто являются зеркальным отображением предыдущих методов и процессов. Осознание того привело к появлению нового направления в области управления – реинжиниринга бизнес-процессов, под которым понимается улучшение или совершенствование уже существующего бизнес-процесса за счет использования информационных технологий с параллельным фундаментальным осмыслением радикальной переориентацией деловых процессов для достижений резких улучшений важных показателей (повышение производительности, улучшение качества, снижение себестоимости).
12Следующая ⇒
Дата добавления: 2014-01-04; Просмотров: 676; Нарушение авторских прав?;
Читайте также:
Бизнес-процесс
Бизнес-процесс(Business Process) – установленная последовательность действий, требующая определенного входа, достигающая определенного выхода и использующая определенные ресурсы, которая служит для реализации работы или услуги для клиента.
Бизнес-процессы предприятия — схемы
В англоязычной литературе бизнес-процесс представляется как множество из одной или нескольких связанных операций или процедур, в совокупности реализующих некоторую цель производственной деятельности, осуществляемой обычно в рамках заранее определенной организационной структуры, которая отражает отношения между участниками.
Схема 1. Общее представление бизнес-процесса.
Понятие бизнес-процесса
Понятие получило распространение в связи с переходом к процессно-ориентированной организации и процессно-ориентированному менеджменту предприятия. Характерными для компаний бизнес-процессами являются выполнение заказа, разработка продукта, управление компанией, доставка продукции. На практике в каждой компании существуют типичные для их сферы и взаимосвязанные друг с другом бизнес-процессы, имеющие своей целью создание и реализацию стоимости продуктов и услуг. Обязательно ознакомьтесь со статьей «Как построить бизнес-процесс в компании – инструкция в 4 шага«, чтобы понять, как создаются бизнес-процессы на практике. Сложное станет наглядным и понятным.
В соответствии со стандартом ENISO 9001:2000 процесс – это набор взаимосвязанных средств и действий, преобразующих вход в результат. Процессы вызывают изменения соответствующего объекта.
В компаниях существуют процессы различных видов, которые могут зависеть друг от друга и в то же время различаться по многим параметрам. Такими параметрами являются:
Бизнес-процессы часто представляют собой комбинацию ключевых, управленческихи поддерживающих процессов (см. схему 2).
Ключевые процессы (создания стоимости) объединяют задания и работу для выполнения определенных требований клиента с применением ключевых производственных компетенций. Они являются стратегически важными и в то же время специфическими (уникальными, так как, например, вследствие применения фирменных знаний их сложно скопировать). К ним относятся:
- обработка и выполнение заказа;
- разработка, проектирование и дизайн продукта;
- производство и монтаж и др.
Управленческие процессы содержат в себе задачи и деятельность, направленные на долгосрочное развитие компании и реализацию целей компании. К ним относятся:
- стратегическое развитие компании;
- долго- и среднесрочное планирование в компании;
- развитие персонала;
- инвестиционное планирование;
- мотивация персонала и др.
Поддерживающие процессы содержат необходимые задания и работы для поддержания ключевых процессов, но не приводящие к непосредственной ценности для клиента, например:
- обработка данных;
- техническое обслуживание;
- логистика;
- административные процессы и др.
На схеме дана основная типология бизнес-процессов на предприятии, а также представлена их взаимосвязь.
Схема 2. Взаимосвязь бизнес-процессов предприятия
Формирование и структурирование предполагает рассмотрение не только типологии, но и учет уровня процесса (см. схему).
Схема 3: Уровни бизнес-процессов.
Уровни процессов | Примеры |
Процессы 1 уровня Цепочка предприятий | Организация внешних процессов, например, цепочка производственной кооперации. Пример: процесс логистики поставок по предприятиям производственной сети |
Процессы 2 уровня Предприятие | Организация прохождения заказа на предприятии. Пример: процесс закупок на предприятии |
Процессы 3 уровня Структурное подразделение | Организация прохождения заказа в структурном подразделении: Пример: разработка заказа в отделе закупок |
Процессы 4 уровня Рабочая система | Организация прохождения заказа в отдельной рабочей системе: Пример: согласование сроков поставки заказа сотрудником N. |
Для описания процесса с качественно-количественной, пространственно-организационной и технически-технологической точек зрения используются характеристики (параметры), которые заданы стандартом ENISO 9001:2000. Параметры процесса – данные для обозначения результативности и эффективности, например, затраты, время выполнения, качество, точность.
Схожие термины:
Введение в бизнес-процессы. Часть 2
В первой части мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.
Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.
Для моделирования рекомендуется использовать следующие методы сбора информации:
- интервьюирование;
- работа с законодательством, документами организации;
- методы мозгового штурма и т.д.
Процесс моделирования бизнес-процессов уникален в рамках организации. Перед началом работы рекомендуется уточнить наличие и содержание данного процесса в организации.
Ниже мы рассмотрим пример алгоритма моделирования бизнес-процессов. Итак, для моделирования бизнес-процесса необходимо:
- Определить результат и владельца бизнес-процесса.
- Определить набор и порядок действий, составляющих бизнес-процесс.
- Определить исполнителей бизнес-процесса: на данном шаге необходимо произвести разделение зон ответственности, выделить какие сотрудники каких подразделений несут ответственность за выполнение действий процесса, привязать исполнителей к действиям.
- Определить события бизнес-процесса. Определить типы событий: начальное, конечное, промежуточное. Привязать промежуточные события к действиям.
- Определить ресурсы: документы, информацию, и др. потребляемые действиями бизнес-процессов. Привязать ресурсы к действиям.
Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:
По завершению алгоритма рекомендуется произвести анализ «что – если». Пример: что будет, если на вход действия попадет документ, содержащий ошибки; что будет, если согласующий руководитель отклонит документ. Есть два способа учитывать результаты анализа:
- дополнить существующую модель ответвлениями;
- предусмотреть отдельно действия «альтернативного» процесса.
Если мы однозначно не можем предложить действия ответвления / альтернативного процесса, мы записываем альтернативное условие в список «открытых вопросов». Данный список затем рекомендуется предоставить экспертам предметной области и Владельцу процесса.
Не рекомендуется анализировать все возможные и невозможные случаи процесса. Ситуациями, не предусмотренными процессом, как правило, занимается функциональный руководитель подразделения (в зоне ответственности которого возникла ситуация).
Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».
Нотации не рекомендуется воспринимать как догмы, сотрудники организаций используют нотации наиболее удобным для них образом. Рекомендуется всегда уточнять используемые нотации в организации.
Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.
1. Сбор исходного материала.
1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы
По семейным обстоятельствам и другим уважительным причинам работнику по его письменному заявлению может быть предоставлен отпуск без сохранения заработной платы, продолжительность которого определяется по соглашению между работником и работодателем.
Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:
- участникам Великой Отечественной войны — до 35 календарных дней в году;
- работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
- родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
- работающим инвалидам — до 60 календарных дней в году;
- работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;
в других случаях, предусмотренных настоящим Кодексом, иными федеральными законами либо коллективным договором.
1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».
Применяются для оформления и учета отпусков, предоставляемых работнику(ам) в соответствии с законодательством, коллективным договором, локальными нормативными актами организации, трудовым договором.
Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».
Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме):
1. Результат бизнес-процесса — оформленные согласно законодательству РФ и стандартам организации документы.
2. Владелец бизнес-процесса: руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.
3. Набор и порядок действий:
написание заявления -> составление приказа -> подписание приказа у руководителя инициатора -> подписание приказа у инициатора –> оформление кадровых документов.
В последовательности действий отсутствует расчет заработной платы, т.к. статья Трудового Кодекса, согласно которой оформляется отпуск, – Отпуск без сохранения заработной платы.
4. Исполнители бизнес-процесса.. Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:
№ действия | Наименование действия | Исполнитель | № след. действия |
1 | Написание заявления | Инициатор | 2 |
2 | Составление приказа | Сотрудник кадровой службы | 3 |
3 | Подписание приказа у руководителя инициатора | Сотрудник кадровой службы | 4 |
4 | Подписание приказа у инициатора | Сотрудник кадровой службы | 5 |
5 | Оформление кадровых документов | Сотрудник кадровой службы | (конец) |
5. События. Дополним вышеуказанную таблицу информацией о событиях:
№ действия | Входящее событие | Наименование действия | Исполнитель | Исходящее событие | № след. действия |
1 | Инициатору необходим отпуск за свой счет | Написание заявления | Инициатор | Составлено заявление на отпуск за свой счет | 2 |
2 | Составлено заявление на отпуск за свой счет | Составление приказа | Сотрудник кадровой службы | Составлен приказ об отпуске | 3 |
3 | Составлен приказ об отпуске | Подписание приказа у руководителя инициатора | Сотрудник кадровой службы | Приказ об отпуске подписан руководителем инициатора | 4 |
4 | Приказ об отпуске подписан руководителем инициатора | Подписание приказа у инициатора | Сотрудник кадровой службы | Приказ об отпуске подписан инициатором | 5 |
5 | Приказ об отпуске подписан инициатором | Оформление кадровых документов | Сотрудник кадровой службы | Оформлены кадровые документы на отпуск | (конец) |
6. Ресурсы, документы и информация. В данном примере мы не учитываем такие ресурсы, как время исполнителей, материалы и оборудование, т.к. нам важны документы, оформленные согласно законодательству РФ и стандартам организации (см. результата процесса). Нам надо проанализировать, какие документы принимают участие в процессе. Дополним существующую таблицу информацией:
№ действия | Входящее событие | Наименование действия | Документ, информация | Исполнитель | Исходящее событие | № след. действия |
1 | Инициатору необходим отпуск за свой счет | Написание заявления | Заявление на отпуск за свой счет | Инициатор | Составлено заявление на отпуск за свой счет | 2 |
2 | Составлено заявление на отпуск за свой счет | Составление приказа | Приказ на отпуск | Сотрудник кадровой службы | Составлен приказ об отпуске | 3 |
3 | Составлен приказ об отпуске | Подписание приказа у руководителя инициатора | Приказ на отпуск | Сотрудник кадровой службы | Приказ об отпуске подписан руководителем инициатора | 4 |
4 | Приказ об отпуске подписан руководителем инициатора | Подписание приказа у инициатора | Приказ на отпуск | Сотрудник кадровой службы | Приказ об отпуске подписан инициатором | 5 |
5 | Приказ об отпуске подписан инициатором | Оформление кадровых документов | Т-2, Т-54а | Сотрудник кадровой службы | Оформлены кадровые документы на отпуск | (конец) |
7. Проведем анализ «что если».
- Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
- Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
- Что если руководитель не подпишет приказ и инициатор:
- имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
- не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.
- Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
- Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.
Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:
Открытые вопросы
- Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
- Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса
Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):
Схема, отображающая взаимодействие элементов показана ниже:
Графическое отображение процесса предоставлено выглядит следующим образом:
Графическое и табличное отображение процесса подлежат согласованию у экспертов и Владельца процесса. Аналитик бизнес-процессов зачастую не может знать всех тонкостей рассматриваемой предметной области, поэтому рекомендуется всегда согласовывать свои модели с экспертами предметной области и Владельцем процесса.
После написания статьи, но до её опубликования, мне довелось пообщаться с хорошим знакомым, я ему изложил тему и суть статьи. Знакомый задал несколько интересных вопросов, я решил опубликовать нашу беседу, думаю, наша беседа будет интересна читателям:
— Не сомневаюсь, ты написал интересную статью. Но к чему такие сложности? Зачем нужны бизнес-процессы, неужели без них нельзя?
— Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.
— Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.
— Хорошие исполнители, уже обеспечены работой, их труд стоит дорого. Ты не думаешь об оптимизации расходов организации, найма толковых специалистов, и обеспечения специалистов методической поддержкой. Еще один фактор – масштабирование работы. Представим, что в нашей организации работает 2 000 сотрудников. В данном случае у нас будет несколько специалистов кадровой службы и у них будет разный опыт. Наша задача в данном случае – предоставить инструмент обучения, осуществления операций и контроля операций со стороны руководителя подразделения.
— Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.
— Во первых, я привел пример бизнес-процесса. Бизнес-процессы могут охватывать самую различную деятельность предприятия, будь то финансы или производство. Во вторых, даже неправильно оформленные кадровые документы могут привести к штрафам организации от контролирующих органов.
Спасибо читателям, что дошли до этого места. Можно было бы многое сказать дополнительно: рассказать про инструменты, используемые при описании бизнес-процессов, подробнее коснуться нотаций… Но это всё продолжение введения в бизнес-процессы.
Автор
Евгений Пономарёв
примеры построения, как описывать, из чего состоят, какие бывают, составляющие предприятия, описание, формирование внутренних этапов
Этот термин часто можно встретить на различных форумах, порталах и даже в обычных разговорах. И неудивительно, ведь стремительное развитие бизнес-индустрии непременно связано с необходимостью его автоматизации. Многие люди не вкладывают в него специальный смысл и не дают ему определение, а используют банально «по умолчанию», так как значение этого слова понятно на интуитивном уровне даже людям, далеким от этого вида деятельности. Однако для большей осведомленности, повышения своей продуктивности и расширения кругозора стоит более детально ознакомиться с тем, что такое бизнес-процессы предприятия, компании или фирмы.
Определение
Сегодня существует большое количество определений термина, однако наиболее популярными являются эти.
- Это совокупность взаимосвязанных мероприятий или работ, нацеленных на создание конкретного товара или услуги для потребителей. Проще говоря, это любая логическая последовательность действий, которая стабильно зациклена и приводит к определенной конечной цели, поставленной перед компанией. Важно уточнить, что коммерческая составляющая не является обязательным элементом в этом вопросе. К примеру, процессы контакта между сотрудниками внутри предприятия (отпуск, перевод, увольнение и т.д.) также могут относиться к бизнес-процессам.
- Это логическая последовательность человеческих действий (или группы лиц) в рабочем коллективе. Целью его описания является анализ и регламентация определенных событий в штате работников.
Именно последнему определению стоит уделить внимание. В этом описании бизнес-процессов компании делается акцент на сотрудниках и коллективе. Это обосновывается следующим.
- Человек принимает участие в любом бизнес-процессе. Если работа выполняется в полностью автоматизированном режиме (при помощи различных ПО или систем оптимизации), то это не более, чем технологический прогресс. В таком случае используются другие стандарты, способы и нюансы реализации.
- Обязательное задействование нескольких людей в открытой или скрытой форме. Даже при наличии одного работника (к примеру, художник), у него в любом случае есть клиенты (картинные галереи) и потребители (покупатели). Помимо этого, продавец не осуществляет трудовую деятельность в «вакууме» — у него есть множество лиц, которые принимают определенное участие в развитии его труда.
Описание
Важно знать, что модель бизнес-процесса не может быть без описания, так как реализация одного без другого не представляется возможным в современных реалиях. Однако несмотря на эту зависимость, вся деятельность должна быть логичной, а ее реализация — приводить к желаемому результату. Описание нередко является творческим занятием, потому что описывая даже «то, что есть», всегда возникают определенные недочеты, возникает сглаживание острых углов и т.п. А вот при необходимости описать «то, что должно быть», приходится создавать кое-что новое уже на созданной базе.
№ | Шаг | Начало | Ответственный | Действие №1 | Действие №2 | Результат |
1 | Звонок клиента | Входящий звонок | Оператор контакт-центра | Поиск клиента по номеру телефона или Ф.И.О. | Регистрация новой карточки (если нет записи) | Идентификация клиента или регистрация новой карты |
2 | Проверка товарного наличия | Клиентский заказ | Оператор контакт-центра Сотрудник складского помещения | Проверка наличия по базе данных, уточнение у работника склада | Озвучивание наличия, текущей цены, способов и сроков доставки | Переход к презентации товара или к ожиданию его поступления |
3 | Презентация товара | Заказ клиента + товар в наличии | Оператор контакт-центра Технический специалист | Проведение презентации, озвучка главных характеристик, ответы на вопросы клиента | Перевод в продажу, перевод в возвращение, отказ от продажи | Переход на этап оформления или завершения бизнес-процесса |
4 | Оформление заказа | Подтверждение заказа от клиента | Оператор контакт-центра Сотрудник склада | Резерв товара на складе, оформление заявки на доставку, подготовка документации | Оповещение клиента о примерном или точном времени доставки | Окончание оформления и передача в службу доставки |
Создание, построение, разработку бизнес-процессов можно сравнить с попыткой найти баланс на тонкой нити идеальной творческой комбинации, искусства и четких математических вычислений. Но нужно адекватно осознавать, что в природе нет идеала, поэтому не стоит надеяться на полное соответствие реальности и отсутствие любых недочетов. В любом деле присутствуют ошибки и упущения, даже при строгом выполнении всех правил регламента.
Помимо этого, не стоит забывать о возможности будущего улучшения. Даже при желании создать безукоризненный продукт, будут выявлены коррективы, которые можно внести в любой момент. Здесь необходимо своевременно остановиться, так как дополненный процесс реализуется различными лицами, которым намного комфортнее работать по старым методикам. А также нужно учитывать их косвенное мышление и уровень обучаемости. Кроме этого, и автоматизация, чаще всего входящая в состав модернизации, нуждается в некоторых инвестициях. Поэтому стоит всегда рассчитывать реальные возможности клиента.
Из чего состоят и какие бывают бизнес-процессы
Сегодня существует 2 основные классификации: расширенная и упрощенная. Каждая из них имеет свои особенности и отличительные черты. К первой относятся такие процессы:
- Основные — направлены на предоставление товаров или услуг, которые являются предпочтительными объектами компании и ответственны за получение прибыли.
- Сопутствующие — нужны для создания товаров или услуг, которые служат следствием основной предпринимательской деятельности и обеспечивают заработок.
- Вспомогательные — применяются для реализации главных процессов и поддержания их специфических черт.
- Обеспечивающие — необходимы для нормального функционирования прочих процессов и нацелены на поддержание их универсальных характеристик.
- Управление — одновременно охватывают несколько управляющих функций на всех уровнях. Это дальновидное, быстрое и нынешнее планирование, формирование и реализация воздействиия управления.
- Развитие — улучшение создаваемого товара или услуги, оснащения, улучшение оборудования.
Упрощенные составляющие бизнес-процесса делят на: управляющие, основные и вспомогательные.
Подробная классификация процессов | Простая классификация |
Основные Сопутствующие | Основные |
Вспомогательные Обеспечивающие | Вспомогательные |
Управляющие Процессы развития | Управляющие |
История появления термина
Его первые упоминания были в далеких 70-х годах ХХ века. Именно в этот период началась активная эксплуатация информационных систем, для которых и нужны были нотации, а также применяемся сам термин. Это связано с тем, что после их введения наблюдалось значительное увеличение сложностей в вопросе рабочей организации. Техника не могла справиться с абстракциями, так как для ее функционирования требовался четкий алгоритм и установленный порядок информационной обработки. Еще до момента автоматизации существовали проблемы с человеческой коммуникацией, из-за чего потребовалось принимать конкретные решения для всеобщего взаимодействия. Обычных инструкций было недостаточно, поэтому появилось острая нужда в стандартизации.
Первая методологическая разработка и формирование бизнес-процессов организации было у военнослужащих в США. Это объясняется их активным использованием удаленных соединений, которая впоследствии превратилась в мировую сеть. Внедрение такого количества информационных систем вынудило создать действенные нотации, благодаря которым удалось получить инструмент описания человеческого взаимодействия с компьютерными технологиями. Это позволило оптимизировать предпринимательство, получая при этом лучшую производительность при аналогичных затратах.
Бизнес-процесс — основные характеристики
Выделяют 3 главные характеристики: цена, продолжительность, удовлетворенность потребителя товаром или услугой. Более подробная информация будет представлена в таблице, расположенной ниже.
Длительность | Стоимость | Удовлетворенность |
Чем выше скорость выполнения процесса, тем лучше продуктивность предприятия. Но важно помнить, что качество результата должно соответствовать высокому показателю с меньшими временными затратами. Для их снижения времени выполнения процесса применяются разные технические и IT-методы, ускоряющие бизнес. | Стоимость выполнения бизнес-процесса должна стремиться к минимуму. Этот подход относится как к производственному процессу, так и к предоставлению услуг. Фирма, оптимизирующая и снижающая цену, имеет значительно больший заработок. | Результатом бизнес-процесса является продукт. От качества финального результата зависит успех предприятия и лояльность клиентской базы. Нужно собирать обратную связь для уличения контроля качества. |
Главные задачи
Для того чтобы правильно подготовить и реализовать все этапы выстраивания бизнес-процесса, стоит заранее ознакомиться с его основными задачами. Справиться с этим поможет компания Клеверенс, реализующая качественную продукцию на протяжении многих лет:
- выполнение последовательности операций в четко установленном порядке, что позволяет предотвратить срывы всей цепи событий;
- обеспечение максимально допустимой скорости реализации;
- поиск и утилизация дублирующих или лишних операций;
- соблюдение временных рамок, благодаря чему удается поддерживать беспрерывное производство.
Отличие бизнес-процесса от технологического
Их главной отличительной чертой является конечный результат. К примеру, если говорить о производстве, то на выходе заказчика хочет получить продукт, имеющий определенные характеристики. Безусловно, даже при использовании технического оборудования есть риск получения бракованных товаров, однако не один из закономерных вариантов, а следствия несоблюдения технологического процесса. В бизнесе, в отличие от предыдущего описания, конечный результат разнится, исходя из выполнения некоторых условий в самом «теле», реализуемый без отклонений от намеченного плана.
Для лучшего понимания приведем наглядный пример технологического процесса:
- Взять заготовку А.
- Соединить ее с Б.
- Обработать под параметром Г.
- Получить готовый продукт.
Все действия достаточно однозначны и отсутствуют так называемые «вилки».
Пример внутреннего бизнес-процесса в компании выглядит следующим образом:
- Получение вводных данных А. После этого возможны 2 исхода: переход на следующий этап — при соответствии данных условию Б — выполнение действия Г (при несоответствии условию В).
- Передача результата на выход.
Исходя из этого можно сделать логичное умозаключение о том, что в данном алгоритме изначально присутствует возможность постановки условий и выполнения различных действий, которые напрямую зависят от первоначальных и промежуточных сведений.
Зачем моделировать бизнес-процессы
Моделирование является крайне эффективной и популярной методикой, значительно ускоряющей понимание происходящего вокруг для штатных сотрудников. Она позволяет результативно решить 2 задачи:
- Изучение предпринимательской деятельности. Графические изображения (схемы) дают возможность быстро ознакомиться с рабочими нюансами предприятия и найти ее наиболее уязвимые места.
- Наглядность. Не зря говорят, что «1 картинка стоит 1000 слов». Схематическая визуализация значительно сокращает время понимания сути проблемы, а также дает возможность дать оценку предложенным путям их решения. Бизнес-консультант должен максимально детально объяснить клиенту все возможные варианты, однако не меньшей важность служит обратная связь. Вторая сторона должна увидеть и понять слабые стороны еще на стадии обсуждения, за счет чего удастся избежать неприятных сложностей и внесения коррективов «на ходу».
Как описывать
Разобрав на простом примере, как описывать бизнес-процессы в компании, можно получить действительно эффективный инструмент. Для этого рекомендуется тщательно ознакомиться с последовательностью действий всего рабочего персонала. После сбора достаточного количества информации она передается в графическую инструкцию. Но для личного пользования она может быть создана в любом формате (даже в виде текста), но для партнеров и работников лучшим выбор станет графика. Это связано с хорошим восприятием и более быстрым пониманием, достигающим благодаря изучению на нескольких уровнях детализации.
- Оптимальный цикл действий состоит из следующих этапов:
- Сбор участников (рабочий штат), входящих сведений, применяемых для старта.
- Применяемые системы.
- Определение желаемого результата.
- Выбор последовательности, выполняемой работником.
- Вычленение условий.
- Описание информации в графическом виде.
Правила описания бизнес-процесса: что это такое
Определенные рамки и правила устанавливают индивидуально, с учетом личных предпочтений заказчика и предпринимательской деятельности. Но существуют обязательные пункты, которые можно расценить как залог успеха. Это:
- Завершенность. На финишной черте должен располагаться ответ на вопрос, который ставился в самом начале пути.
- Лаконичность. Несмотря на необходимость предоставить максимальный объем информации, ее нужно излагать компактно, вычленяя только главные моменты. Наличие большого количества деталей тяжело воспринимаются, что сводит эффективность проделанной работы практически к нулю.
- Привлечение стандартных нотаций. Не стоит создавать свои обозначения. Лучше использовать то, что практикуется во всем мире.
- Учет и прямое указание каждого участника. Для этого не рекомендуется пользоваться сносками с нумерациями и прочими инструментами.
- Максимально понятное описание. Важно подготовить материал так, чтобы потребитель мог понять его без сторонней помощи.
Схема бизнес-процесса
Распространенные мифы и ошибочные мнения
Примеры и описание того, что такое бизнес-процесс в организации поможет развеять наиболее популярные ложные мнения, касающиеся этого вопроса. Среди них:
- Самодеятельность — это успех. Подобное решение потребует создания своих обозначений и стандартов, что сильно замедляет работу и снижает шансы на достижение нужной цели.
- Описание бизнес-процесса предприятия и IT-системы не имеет отличий. В реальности у них есть ряд особенностей, которые крайне важно учитывать.
- Обязательно должна появиться прибыль. Не все бизнесы ведут прямые продажи, которые и влияют на видимый показатель дохода. Некоторые виды деятельности невозможно оценить по этому критерию. Более того, процессоориентированный подход, прежде всего, внедряется для получения высокой производительности при предыдущих инвестициях.
- Можно создать идеал. Не стоит надеяться на разработку безукоризненного плана, гарантирующего отсутствие даже малейших ошибок или сложностей, которые достаточно часто возникают по мере продвижения к конечной цели. Даже гениальному специалисту с многолетним опытом не получится охватить весь материал сразу, поэтому он в любом случае будет содержать небольшие недочеты, которые будут своевременно и эффективно решаться при совместной заинтересованности обеих сторон.
Нужно понимать, что зная, как составить бизнес-процесс, получится добиться отличного результата с минимальными потерями, также приобрести бесценные знания в этой теме, которые можно использовать в дальнейшем. Но при его разработке важно учитывать, что он обязан решить поставленную перед заказчиком задачу (любой степени сложности) и ответить на вопрос, который обсуждается в пределах этого проекта. Остальные проблемы решаются при будущем плодотворном сотрудничестве. Это нужно понять всем потенциальным клиентам, у которых возникает непонимание того, почему отсутствует детализация определенных действий и многого другого, касающегося обсуждений. Только такой подход к делу поможет увеличить производительность своей предпринимательской деятельности, повысить лояльность клиентской базы, привлечь новых партнеров, поднять конкурентоспособность на современном рынке и приумножить показатели дохода.
Количество показов: 146