1. Описание бизнес-процессов без определенного заказчика
Самая распространенная ошибка при описании бизнес-процессов — это описание ради самого описания. Отсутствие заказчика описания приводит к тому, что созданные модели никому, кроме специалистов их создавших, не нужны. В таком случае ставится «крест» на самом процессном подходе и больше к этой теме не обращаются.
Для того, чтобы избежать данную ошибку, уже на этапе планирования проекта по описанию процессов нужно определить заказчиков этого описания. В большинстве случаев это могут быть следующие подразделения — подразделения связанные с информационными технологиям; подразделения, отвечающие за систему менеджмента качества; департамент развития. Но лучше всего, если заказчиками описания бизнес-процессов будут бизнес- подразделения, которые хотят совершенствовать свою деятельность или перейти на процессное управление.
2. Неправильный выбор инструмента описания бизнес-процессов
Можно отметить, что использование инструмента для описания бизнес-процессов во многих случаях обеспечивает необходимое качество описания, минимизирует затраты на сопровождение позволяет использовать это описание для различных целей. В случае неправильного выбора возникает ситуация, когда крупный проект ведут с использованием visio, или наоборот, в небольшой проект закупается такое серьезное средство как ARIS. В данном случае нужно четко понимать, что если в проекте моделей более 200, то простыми средствами, не поддерживающими групповую работу и дальнейший анализ, не обойтись и необходим серьезный инструмент. Использование текстовой формы описания процессов дает очень низкое качество описания и в случае минимальных бюджетов лучше использовать таблицы MS Excel и PowerPoint, чем MS Word.
ТОП-5 ошибок при описании и внедрении бизнес-процессов
3. Слишком детальное описание бизнес-процессов «как есть»
Практика показывает, что многие проекты заканчиваются неудачей по причине того, что описание бизнес-процессов «как есть» проводится на слишком детальном уровне. Детальность описания требует повышенных трудозатрат, и поэтому бизнес-результат может быть отодвинут на неопределенный срок. Как правило, к этому моменту у заказчиков проекта уже кончается терпение, и проект останавливается. Поэтому в проекте описания бизнес-процессов необходимо четко определить перечень необходимых моделей и глубину детализации, и сделать это необходимо так, чтобы трудозатраты на описание процессов были минимальные и время получения бизнес- результата было не более трех месяцев.
4. Отсутствие единой методологии описания бизнес-процессов
Описание бизнес-процессов является вспомогательной деятельностью, направленной на совершенствование деятельности компании. Отвлекая бизнес — экспертов на интервью с бизнес -аналитиками вы отвлекаете их от основной деятельности, что негативно отражается на эффективности компании. Поэтому перед тем как приступать к описанию процессов необходимо определить все требования к будущему описанию и стандартизовать используемую методологию описания. Это нужно сделать потому, что второй раз с задачей описания процесса или уточнения определенных параметров по процессу в бизнес — подразделения придти скорее всего не удастся. Наиболее эффективен подход, в рамках которого создается методология описания процесса, а сами бизнес-процессы описывают сотрудники бизнес — подразделений, определяя направления для совершенствования или требования к автоматизации, тогда как бизнес — аналитики помогаю им в этом вопросе.
5. Описание бизнес-процессов без совершенствования
Созданные в проекте модели должны стать основой для совершенствования деятельности, иначе через небольшой период времени процессы изменятся и их описание станет неактуальным. Поэтому уже на этапе описания процессов совместно с владельцем процесса и его участниками необходимо формировать направления для совершенствования процесса и пытаться внедрять процессы «как должно быть» с учетом этих мероприятий. Если через описание процессов будут уменьшены издержки или уменьшено среднее время выполнения процесса, то такой результат станет востребованным. Но если в результате проекта будет сформирован отчет с множеством моделей, то скорее всего эти результаты никому не будут нужны.
6. Описание бизнес — процессов без привлечения бизнеса
Если говорить о процессном управлении, то это в первую очередь инструмент повышения эффективности компании. В первую очередь этим инструментом должны пользоваться владельцы и участники процесса, тогда его использование будет максимально эффективным. Создание специализированных подразделений по процессным технологиям должно становиться началом для постепенной передачи технологий процессного управления в бизнес — подразделения. Однако практика показывает, что данные подразделения сосредотачиваются на задачах описания процессов и при отсутствии бизнес — результата их влияние в компании уменьшается, и о процессном управлении постепенно забывают. Только если описание процесса станет инструментом бизнеса можно говорить о внедрении процессных технологий в компании.
7. Описание бизнес — процессов без автоматизации
Многие компании пытаются внедрять процессное управление и в большинстве случаев инструментом «закрепления» бизнес-процесса является регламент, что не позволяет осуществлять полноценный контроль и анализ процесса, поэтому вслед за описанием процесса должна идти его автоматизация. Для этих целей существует отдельный класс информационных систем Workflow / BPM с помощью которых это можно сделать наиболее эффективно и обеспечить не только автоматизацию процесса, но и его контроль, что в целом поднимает уровень зрелости бизнеса и уровень исполнительской дисциплины.
Источник: koptelov.info
Вредные советы опытного бизнес-аналитика. Часть 1: не топите за нотации
Правила моделирования соблюдать нельзя нарушить
Подробно о том, что такое нотация моделирования бизнес-процессов и какие они бывают, мы говорили в этой статье. А сейчас сосредоточимся на вопросе практического использования этих правил графического описания деятельности и ответственности аналитика за их строгое соблюдение.
Когда я преподавала в ВУЗе, мои студенты могли запросто получить «неуд», отправив 2 потока управления в один функциональный блок EPC напрямую, вместо того, чтобы объединить их с помощью соответствующего логического оператора (AND, OR, XOR). Однако, жизнь гораздо интереснее учебных примеров. Чаще всего разработанная по всем правилам схема бизнес-процесса в нотации EPC или BPMN, покажется представителю Заказчика или эксперту предметной области слишком громоздкой и сложной для понимания. А разработчик ПО может посчитать разработанную аналитиком диаграмму последовательностей UML слишком примитивной и не отражающей технических особенностей, связанных с синхронными и асинхронными вызовами.
Поэтому, перед тем, как представлять конечному потребителю описание проанализированного вами бизнес-процесса, задайте сами себе простой вопрос и дайте на него честный ответ: собеседник поймет вашу схему? Если потребитель информации, представленной аналитиком, не понимает ее, это – проблема аналитика. Когда диаграмма отражает все необходимые детали и особенности реального бизнес-процесса для уровня абстракции, нужной конкретному стейкхолдеру, будь то эксперт предметной области, менеджер проекта или разработчик, – она уже выполняет свое предназначение в качестве описательного инструмента и, потому имеет право на жизнь. Не бойтесь нарушать формальные правила, чтобы быть ближе к своему клиенту и показать ему, что вы поняли его бизнес-процессы и готовы говорить с ним на одном языке.
Разумеется, подобные вольности с нотациями допустимы, если речь не идет об автоматизации ваших процессных схем, как это бывает в случае BPMN-диаграмм, отправляемых на исполнение в BPMS-систему. Некорректно нарисованная диаграмма, точнее, ее отображение в виде XPDL или BPEL-файлов просто не будет понято потребителем – исполняющим движком прикладной системы, будь то BPMS, СЭД, ERP, CRM и пр. Аналогичные ошибки могут возникнуть при имитационном моделировании бизнес-процессов, например, в Business Studio. Поэтому, когда аналитик разрабатывает диаграмму бизнес-процесса для его последующей автоматизации в виде workflow-схемы потока действий, правила нотаций BPMN и EPC нарушать нельзя.
В случае структурной нотации IDEF0, которая сегодня не очень часто используется из-за своих особенностей и прикладной специфики проектов, о которых мы говорили здесь, рекомендую все же придерживаться правил по наименованию блоков и стрелок, а также их ориентации относительно друг друга. Впрочем, вероятность того, что начинающий бизнес-аналитик в первый год своей работы столкнется с необходимость практического применения этой нотации не слишком высока. А вот детально описать процесс в BPMN (реже EPC) и UML activity – вполне тривиальная задача при разработке и внедрении ПО, которую чаще всего и решает junior-аналитик.
Источник: babok-school.ru
