Отсутствие заказчика описания бизнес- процессов (БП) – подобная ошибка приводит к тому, что разработанные модели практического применения не имеют. Чтобы избежать подобных ошибок, уже в ходе планирования описания следует точно определиться с его заказчиками.
Они могут быть связаны с информационными технологиям, отвечать за менеджмент качества, департамент развития, но самый лучший вариант, — это конкретные бизнес- подразделения, стремящиеся совершенствовать свою деятельность либо перейти на процессное управление.
Правильное использование инструмента описания БП во многих случаях обеспечивает должное его качество, минимизирует затраты, позволяет использовать описание для самых разных целей. В случае неудачного выбора возникает такая ситуация, когда солидный проект ведется с использованием visio, и наоборот, в довольно скромный проект закупается, к примеру, ARIS.
В данном случае следует учитывать тот факт, что если в проекте участвует свыше 200 моделей, то средствами простыми, которые не поддерживают групповую работу и последующий анализ, здесь не обойтись. Текстовая форма описания процессов дает весьма низкое качество, а потому в случае скромного бюджета лучше использовать не MS Word, а PowerPoint и таблицы MS Excel.
Топ-14 ошибок в бизнес-процессах
Еще одна распространенная ошибка — детальность описания, которая требует неоправданно больших трудозатрат и приводит к отсроченному на неопределенный период бизнес-результату.
В проекте описания БП желательно четко определять перечень моделей и степень детализации, с тем, чтобы трудозатраты были минимальные, а время получения конкретного бизнес- результата не превышало трех месяцев.
Следует также помнить о том, что описание БП, направленное на совершенствование деятельности компании, является деятельностью вспомогательной, а потому бизнес –аналитикам отвлекать бизнес — экспертов от их основной деятельности, а это не совсем благоприятно отражается на эффективности деятельности компании.
Перед тем как приступить к описанию БП, необходимо определиться со всеми требованиями к нему и стандартизовать применяемую методологию описания. В этом случае БП будут описываться сотрудниками бизнес — подразделений, в то время как бизнес — аналитики помогают им в этом.
Созданные модели должны быть положены в основу дальнейшего совершенствования деятельности, в противном случае через некоторое время процессы изменятся, а их описание станет вовсе не актуальным.
Создание специализированных подразделений процессных технологий должно стать началом для постепенной передачи им технологий процессного управления. Однако, как показывает практика, данные подразделения обычно сосредотачиваются на задачах описания БП и в случае отсутствия бизнес — результата влияние их в компании уменьшается, а о процессном управлении со временем постепенно забывают.
Таким образом только в случае, если описание БП станет инструментом ведения бизнеса, можно будет говорить о внедрении в компании процессных технологий.
ТОП-5 ошибок при описании и внедрении бизнес-процессов
В заключение скажем о том, что внедрять процессное управление пытаются многие компании, в большинстве случаев его инструментом является регламент, не позволяющий осуществлять полноценный анализ и контроль за БП. Поэтому вслед за его описанием должна идти автоматизация.
Для достижения этих целей существует специальные информационные системы Workflow / BPM, с их помощью можно обеспечить автоматизацию БП и его контроль, что поднимает уровень как самого бизнеса, так и исполнительской дисциплины.
ЖИЛАЯ НЕДВИЖИМОСТЬ
В настоящее время в Воронеже наблюдается активное строительство новостроек — как полноценных жилых комплексов, так и отдельно стоящих домов. Купить квартиру-студию можно за сумму до 1 миллиона рублей. Часть жилых комплексов представлена на нашем сайте.
СЛУЧАЙНОЕ ФОТО
ДЛЯ БИЗНЕСА
Деловой центр «Икар» — один из немногих бизнес-центров Воронежа, который может похвастаться выгодным расположением с доступными по цене офисами.
Количество офисов — 100.
Площадь офисов от 13 до 105м 2 .
Бизнес-центр «Арсенал» расположен в историческом центре Воронежа, в 5 минутах ходьбы от проспекта Революции, рядом с гостиницами «Украина» и «Петровский Пассаж».
Количество офисов — 125.
Площадь офисов от 15 до 100м 2 .
Деловой центр «Икар» предлагает в аренду залы для переговоров, которые подойдут организаторам семинаров, конференций, презентаций, мастер-классов, совещаний и других аналогичных мероприятий.
Площадь основного — 218м 2 .
Вместимость — до 100 человек.
В БЦ имеются еще 2 конференц-зала вместимостью 40 и 15 человек.
Аренда конференц-зала в БЦ Арсенал позволит Вам в максимально комфортных условиях провести семинар, деловую встречу или совещание.
Площадь — 65м 2 .
Вместимость — до 60 человек.
ИНФОРМАЦИОННЫЕ ПАРТНЕРЫ
- — Жилые комплексы
- — Деловой Воронеж
- — Истории успеха
- — Финансы
- — Недвижимость
- — Сфера B2B
- — Бизнес
- — Реклама
- — Автомобили
- — Hi-Tech и интернет
- — Образование
- — Мнения экспертов
- — Бизнес-новости
- — Бизнес-форумы
- — Авторские колонки
- — Банки
- — Бухгалтерский аудит
- — Юридическая помощь
- — Курсы и тренинги
- — Консалтинговые услуги
- — Рекламные агентства
- — Агентства недвижимости
- — Курьерские услуги
- — Услуги переводчика
- — Бизнес-центры
- — Конференц-залы
- — Гостиницы
- — Достопримечательности
- — Музеи
- — Театры
- — Парки и сады
- — Развлечения
- — Квесты
- — Кинотеатры
- — Рестораны
- — Суши-бары
- — Сауны и бани
- — Торговые центры
- — Гипермаркеты
- — Продуктовые маркеты
- — Новый год
- — История города
- — Службы города
- — Почтовые индексы
- — Телефонные коды
- — Пресс-релизы
- — Фотогалерея
- — Такси
- — Автомойки
- — Ветеринарные клиники
- — Культурные события
- — Новости Воронежа
- — Аналитика
- — Рецензии
- — ПроЧтение
- — Материалы
- — О проекте
- — Новости проекта
- — Партнеры
- — Сотрудничество
- — Рекламодателям
- — Вакансии
- — Контакты
Полное или частичное копирование информации с сайта без письменного согласия редакции запрещено. 18+.
Источник: www.camcomp.com
Ошибки описания бизнес процессов
Добрый день, дорогие друзья!
Сегодня в рассылке:
Ошибки описания бизнес-процессов
Описание бизнес-процессов стало широко используемым средством повышения результативности и эффективности бизнеса. При выполнении этой работы иногда совершаются ошибки, снижающие эффект от описания бизнес-процессов. В этой статье я расскажу о некоторых из этих ошибок.
1. Ошибки структуризации бизнес-процессов
Иногда заказчики описания бизнес-процессов не хотят описывать все бизнес-процессы (например, из соображений экономии), а выбирают только некоторые, самые важные или самые проблемные. Важно при выборе бизнес-процессов для описания учесть общую структуру системы бизнес-процессов, иначе результат может разочаровать.
Например, недавно ко мне обратился руководитель торговой компании с пожеланием описать бизнес-процесс «Документооборот» (весь обмен документами с внешним миром, не только бухгалтерский документооборот).
Давайте подумаем, что из этого получится. Ниже представлен фрагмент иерархии бизнес-процессов типичной торговой компании.
Неправильная структуризация бизнес-процессов для описания – это распространённая, но далеко не единственная ошибка описания бизнес-процессов. Поэтому продолжение темы следует …
Копирование и цитирование материалов рассылки возможны только при условии указания авторства и активной ссылки на оригинал статьи — https://piter-consult.ru/home/Articles/Consulting-myths-legends/business-processes-description-error.html .
Моделирование бизнес-процессов в нотации BPMN начинающими: типовые ошибки
В статье Владимира Репина рассмотрены типовые ошибки, которые допускают сотрудники организации, начинающие осваивать моделирование бизнес-процессов в среде Business Studio с использованием нотации BPMN. Обсуждается вопрос о возможности и целесообразности использования данной нотации для комплексного описания бизнес-процессов организации силами собственных сотрудников.
Введение
Задача «описания всех бизнес-процессов» компании многими специалистами рассматривается как нецелесообразная в силу того, что она крайне трудоемка и не дает очевидного практического результата в краткосрочной перспективе, например, явного прироста прибыли компании. Тем не менее, собственники и топ-менеджеры многих крупных компаний именно так ставят задачу: «описать все процессы». Причины такой постановки задачи различны: желание сделать «прозрачной» компанию, подготовиться к автоматизации, радикально снизить затраты, провести реинжиниринг и проч.
Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.
Методология комплексного описания процессов организации с использованием конкретного инструмента – это не просто описание нотации моделирования в части используемых значков. Это более сложный объект для разработки. Отмечу, что Методология в целом не является предметом этой статьи (будет рассмотрена позже). Методология комплексного описания процессов должна быть подробно описана в «Соглашении по моделированию» компании.
С человеческими ресурсами все тоже довольно сложно. Другими словами, их просто нет. Найти на рынке готового специалиста со знаниями методологии и инструмента, навыками моделирования в нотации BPMN, опытом в предметной области (например, сварка танков под вакуумом рентгеновским лазером) невозможно. Вывод один – массовое обучение и вовлечение в проект описания бизнес-процессов руководителей и специалистов подразделений.
В данной статье рассматриваются типовые ошибки, которые допускают сотрудники, впервые занявшиеся моделированием процессов вообще и, в частности, в нотации BPMN.
Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.
Исходные данные для анализа
Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25-30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio – это нотация «Процедура) или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.
Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В.В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN.
Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.
Во второй день рассматривались более сложные примеры и выполнялось комплексное задание на описание группы связанных между собой процессов. Это задание выполнялось в небольших рабочих группах по 2-3 человека. После описания процессов группы выполняли анализ качества моделей на основе чек-листа. Проводился разбор ошибок.
Далее сотрудники, прошедшие обучение, включались во временные рабочие группы по описанию процессов. ВРГ разрабатывали графические схемы процессов. Выполнялся анализ качества этих схем и разбор ошибок (дистанционно или на рабочих сессиях).
Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.
Несмотря на проведенное обучение, разбор ошибок и наличие «Соглашения по моделированию», по ходу практической работы сотрудники допускали ряд ошибок, что вполне нормально для людей, делающих что-то в первый раз.
Многие из выявленных ошибок являются типичными, т.е. повторяются от модели к модели. Причем ряд этих ошибок можно назвать содержательными, т.е. они не связаны с нотацией BPMN, как таковой. Нужно хорошо знать предметную область и саму методологию моделирования (не рисование одной схемы, а именно комплексное моделирование системы процессов компании), чтобы не допускать такие ошибки.
Ряд ошибок возникает из-за произвольного, интуитивного использования (трактования) значков нотации BPMN, что приводит к серьезному искажению смысла моделей. Ниже подробно рассмотрены ошибки, допускаемые новичками в моделировании процессов.
Типовые ошибки моделирования, допускаемы начинающими
Проблема мышки
Первая и, вероятно, самая главная проблема при моделировании процессов в нотации BPMN начинающими – это проблема «Мышки» (я использую этот термина на обучении вместо токена). Для многих сотрудников понимание сути потока работ и мышки, которая бегает от одной операции процесса к другой по стрелкам типа sequence flow, является довольно сложным.
Но если не концентрировать внимание на потоке и не отслеживать мысленно различные пути мышки, то можно упустить из вида многие детали реального процесса. Модель в этом случае становится весьма неточной. В ней упускается множество практически важных моментов. В результате, схема вроде как нарисована, но ни выполнить ее анализ, ни обосновать изменения нельзя. Это одна из причин разочарования некоторых руководителей в графических схемах бизнес-процессов как в практическом инструменте развития бизнеса.
Оборванные входы-выходы
Следующая проблема – это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.
Как правило, это означает, что сотрудники не изучили процесс в достаточной степени и не могут сказать, какие документы/информация нужны для выполнения операций, откуда они берутся и куда передаются.
Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.
Второй аспект содержательный. Довольно часто сотрудники показывают выход в другой процесс, но на графической схеме этого процесса нет соответствующего входа. Если подняться на уровень выше – на диаграмму в нотации IDEF0, там тоже нет соответствующих стрелок.
Бывает обратная ситуация – на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие – низкое качество модели компании в целом.
Вообще говоря, модель процесса в BPMN в первую очередь должна показывать поток операций, последовательно выполняемых по определенной логике. Но отображение документов (информации, баз данных, модулей информационных систем) на схеме является практически важным.
Во-первых, это заставляет сотрудников продумать каждый шаг и выявить необходимую для выполнения работы информацию и документы. Определить, в чем заключается результат каждой операции, куда и в какой форме он передается. Тоже самое касается и процессов. Между ними тоже должна быть выполнена «стыковка по входам/выходам».
На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.
На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.
Некорректная логика процесса
Вторая проблема – это довольно легкомысленное отношение к логике процесса, что ведет к появлению логических ошибок на схеме. Процесс нарисован, но работать (исполняться) не будет — остановится на какой-то операции и дальше не пойдет. Хотя на обучении подробно рассматриваются примеры логических ошибок (некорректное применение шлюзов, например), на практике сотрудники их довольно часто допускают. На первых порах необходим постоянный контроль схем со стороны опытного бизнес-аналитика или методолога проекта.
Непонимание межпроцессного взаимодействия
Моделирование межпроцессного взаимодействия при помощи отправки-получения сообщений является наиболее сложным аспектом для начинающих.
Во-первых, многие интерпретируют маркер в виде конверта как некоторый документ, отправляемый от одной операции процесса к другой. Это понимание на основе бытового здравого смысла приводит к некорректному использованию событий отправки сообщения между операциями одного процесса, без отправки в другой процесс. Некоторые искренне удивляются, почему это ошибка – «ведь результат работы (конверт) отправлен из одной операции в другую?!».
Вторая проблема состоит в том, что отправку сообщений между разными процессами начинают показывать везде, где только можно, причем без всякого содержательного смысла:
• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) – с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное – через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 – отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.
Понятно, что при дальнейшем использовании моделей для автоматизации в конкретной BPMS нужно будет уточнять ситуации, возникающие при отправке-получении сообщений. Но для проекта комплексного моделирования процессов очень важно, чтобы сотрудники понимали, для чего, как и когда они «запускают» на выполнение другие процессы, как синхронизируют свой процесс с ними.
Использование таймеров
Событие-таймер используется как по ходу процесса, так и в виде граничного события. Как пример типичной ошибки начинающих приведу следующую формулировку события-таймера: «Не позднее 2-го числа месяца». Когда должен сработать таймер – непонятно. Другой пример – «Ежедневно» (см. рис. 4).
Так же, часто используют граничные события-таймеры, в названии которых указывают нормативную длительность выполнения процесса. Но при этом данный таймер не прерывает выполнение операции и не передает управление на другую операцию процесса.
Описание процесса для одного объекта, которых в реальности множество
Начинающим рисовальщикам процессов довольно тяжело осознать эту проблему. Она состоит в описании процесса для одного объекта обработки, которых на самом деле несколько (счета, заявки и т.п.). Необходимость работы с ними возникает в разное время. Перед обработкой нужно выяснить сколько документов нужно обработать, в каком порядке и т.д. Таким образом, довольно существенный кусок работы, от понимания которого зависит качество модели, остается «за кадром».
Процесс в процессе (рекурсия)
Довольно часто можно наблюдать такую картину. Берем для анализа процесс под каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс!
Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные, сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.
Красота схемы
Здесь все печально. Только 10-15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы – залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.
Накопление опыта и исправление ошибок
По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2-3 модели процессов в неделю), через 1-1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.
Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.
Выводы
При использовании минимального набора объектов и маркеров, нотация BPMN вполне доступна для изучения сотрудниками, не имеющими опыта графического описания бизнес-процессов.
Очень важно провести базовое обучение, акцентирующее внимание на важнейших правилах и типовых ошибках использования нотации BPMN для описания процессов. В первую очередь важно обратить внимание на следующее:
- «мышка» или идеология исполняемых процессов;
- информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
- корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
- соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
- корректное использование событий-таймеров;
- четкое отслеживание множественных объектов для обработки;
- визуальная наглядность схемы («Красота схемы»).
Ошибки, неизбежно возникающие при описании процессов начинающими, нужно своевременно выявлять. По ходу проекта очень важен постоянный методический контроль работы временных рабочих групп. Несмотря на большое количество ошибок, допускаемых сотрудниками на первом этапе, в дальнейшем качество моделей улучшается. Это возможно при постоянном методическом контроле и помощи со стороны Процессного офиса компании.
Критически важно иметь в организации хорошо проработанное Соглашение по моделированию, в котором представлены все требования, необходимые для комплексного описания большого количества процессов на разных уровнях иерархии.
Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ – так же критически важные аспекты моделирования бизнес-процессов.
В целом, с учетом опыта выполненных проектов, можно сделать вывод, что комплексное описание бизнес-процессов силами собственных сотрудников организации в нотации BPMN в среде Business Studio возможно и практически целесообразно.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Сентябрь 2018 г.
Средняя оценка 0 / 5. Количество оценок: 0
Оценок пока нет. Поставьте оценку первым.
Источник: repin.guru
