С чего начать разработку бизнес процессов / Хабр
Специалисты знают, что прежде, чем автоматизировать бизнес процессы приходится эти самые процессы разрабатывать заново или оптимизировать, потому как автоматизация хаоса дело неблагодарное да, по сути, и не возможное.Устанавливая задачу персоналу типа «опишите свою деятельность», или «каков результат вашей деятельности» в буквальном смысле сводит его (персонал) с ума. Возникает непонимание, а как следствие раздражение, соответственно речь о сотрудничестве уже не стоит. Некоторые скачивают из Интернета инструкции совершенно не применимые на практике, некоторые в интеллектуальных муках что-то рожают, однако на коррекцию уже нет сил и желания.
В связи с этим встала задача, как быстро, но эффективно донести идею описания последовательности действий должности, которая, собственно, приводит к желаемому результату. К тому же способ донесения должен отвечать определенным принципам: что-то, что известно практически каждому плюс простота формулирования.
Получилось следующее: «Как приготовить яичницу»? Причем «зачет» описания процесса приготовления сотрудник получает в том случае, если другой сотрудник выполняет только те действия, которые написаны в инструкции по приготовлению и не делает ничего другого. Таким образом, человек получал обратную связь от своего же сослуживца, что позволяло более критично отнестись к собственному творению, к тому же в некоторых моментах было просто весело. Кто-то забывал зажечь огонь, кто-то вместо удара тыльной стороной ножа по скорлупе, писал «разрезать скорлупу».
Итак, в общем случае задание было следующим:
1. Напишите, какие ресурсы требуются для приготовления яичницы.
Ниже привожу сверочный список, кому интересно, составьте свой и сравните. В ресурсах и технических операциях сознательно пропущено несколько пунктов, буду рад, если заметите.
Ресурсы: 1. Два яйца. 2. Столовая ложка подсолнечного масла. 3. Плита. 4. Газ. 5. Соль. 6. Вилка. 7. Столовая ложка. 8. Тарелка для второго блюда. 9. Мусорное ведро.
Технические операции: 1. Зажечь газ. 2. Поставить сковороду на зажженную конфорку и через минуту убавить газ до минимума. 3. Налить подсолнечное масло в столовую ложку и добавить его в сковородку. 4. Распределить масло по всей поверхности сковородки. 5. Достать из холодильника два яйца. 6. Взять нож из кухонного гарнитура. 7. Взять первое яйцо в левую руку, а нож в правую. 8. Ударить тыльной стороной ножа по скорлупе так, чтобы появилась трещина на скорлупе. 9. Положить нож. 10. Разъединить половинки скорлупы над сковородкой на расстоянии примерно 5 – 10 сантиметров над поверхностью. 11. Повторить шаги с 7 по 10 со вторым яйцом. 12. Двумя пальцами правой руки взять «щепотку» соли и посолить яичницу. 13. Выждать семь минут. 14. Выключить газ. 15. Поставить на стол тарелку для второго блюда. 16. Взять сковородку в правую руку.
После этой несложной на первой взгляд процедуры, сотрудники компаний в буквальном смысле расцветали на глазах, приговаривая «Ах вон оно, что от нас требуется»!
Разработка бизнес процессов
Для начала, перед тем как внедрить современные решения в работу предприятия, необходимо их создать. Для этого нужно установить основные задачи сотрудников производства, а также провести анализ созданных ранее процессов и оценить их влияние на качество функционирования предприятия.
Разработка бизнес-процессов компании дает возможность снизить затраты на совершенствование системы и сократить задачи, которые выполняются людьми. Можно также перераспределить функции сотрудников и уменьшить количество ошибок, которые происходят в производственном процессе. В результате нововведения приведут к быстрой и успешной реализации задуманных задач.
Усовершенствованные бизнес-процессы гарантируют ряд преимуществ:
- Управление совершается прозрачно. Это улучшает уровень работы предприятия.
- Принимаются обдуманные решения о процедурах, которые подлежат автоматизации.
- Сотрудники предприятия лучше осознают род своей деятельности.
- Повышается уровень управляемости процессами.
- Качество внедренных технологий имеет высокий уровень.
Порядок действий по разработке бизнес-процессов для предприятия и их реализации следующий:
- инициация;
- планировка;
- внедрение;
- контроль над выполнением;
- завершающий этап.
В первую очередь, проводится глубокий анализ текущих проектов, при помощи которых осуществляется управление компанией. Вслед за этим идет этап планирования и определения задач по оптимизации всего процесса производства.
Проектирование бизнес-процессов предприятия. Этапы создания нововведений
Чтобы достичь высоких результатов, вывести предприятие на новый уровень и повысить конкурентную способность продукции, проектирование бизнес-процессов предприятия необходимо проводить в несколько последовательных этапов, которые следуют друг за другом в установленном порядке:
- Создание модели, в которых представляются функции производства. Созданный прототип отображает сложности и проблемы, с которыми сталкивается предприятие. Это поможет провести анализ и принять решение по устранению трудностей.
- Формирование ключевых бизнес-процессов. Это необходимо для увеличения конкурентоспособности, чтобы вывести производимую продукцию на новый уровень.
- Разработка структуры предприятия способствует внедрению стратегических планов организации, решению возникших проблем и трудностей.
- Проектирование логической поддержки, которая основывается на технических, организационных и управленческих мероприятиях.
- Подготовка предприятия к внедрению современных процессов. Для этого формируются потоки производства и поставки сырья для изготовления товаров.
После окончания подготовительных этапов необходимо оптимизировать и реализовать новые процессы, и только затем начинается внедрение созданной системы управления.
Ликбез для руководителей: моделирование бизнес-процессов на раз-два-три
Антон Тимохин
Руководитель проектов дирекции по развитию НПО «ЭЛСИБ»
В условиях современной бизнес-среды, в целях повышения операционной эффективности все больше и больше компаний принимает решение о реализации проектов по описанию и оптимизации своих бизнес-процессов. Тем не менее, такие проекты, как и любая другая деятельность по совершенствованию, могут привести как к положительным, так и к отрицательным результатам.
Начало начал
Повторюсь, что результат реализации проекта по описанию, оптимизации и внедрению новых версий бизнес-процессов может быть как положительным, так и отрицательным, с финансовыми потерями для компании в случае неправильной организации работ. Почему начинаются такие проекты?
Можно выделить ряд первопричин, по которым в результате диагностики руководители компаний принимают решение о старте работ по формализации и оптимизации бизнес-процессов:
- Выполнение ненужных (не добавляющих ценность) работ, большая вариабельность циклов работ;
- Отсутствие стандартизации и унификации бизнес-процессов, произвольная структура бизнес-процессов, отсутствие документации, регламентирующей их выполнение;
- Неэффективная архитектура информационных потоков (сбор, анализ, хранение данных), недостаточный уровень автоматизации;
- Избыточное число подразделений и департаментов, дублирование функций, неэффективное взаимодействие между ними;
- Размытие зон ответственности, отсутствие ответственного за бизнес-процесс и его результат в целом;
- Концентрация всех полномочий на высшем уровне иерархии, отсутствие практики делегирования полномочий;
- Излишние трудозатраты на контрольно-отчетную деятельность, существенные потери времени на согласованиях;
- Мистема оценки труда не мотивирует сотрудников к снижению затрат и повышению качества, мотивационные показатели подконтрольны мотивируемому.
Список можно продолжить.
Получив по итогам диагностики сигнал о том, что в компании существуют такого рода проблемы, руководитель может сделать вывод — «нам нужно описать и оптимизировать наши процессы, и это поможет нам избавиться от всех проблем:)». При этом четкой задачи и критериев оптимизации не формулируется. Такой подход к постановке задачи на проект сам по себе имеет несколько проблемных зон, которые неизбежно приведут к негативным последствиям, а вероятность получения положительного результата минимальна:
- Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
- Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании;
- Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.
Несколько слов об оптимизации
Описание бизнес-процессов в большинстве случаев воспринимается как «лекарство от всех болезней», но мало кто из руководителей задумывается о том, зачем необходимо описывать существующие бизнес-процессы? Ведь круг проблем, которые могут быть решены простой формализацией процессов ограничен, а в остальных случаях требуется оптимизация бизнес-процессов компании.
Как правило, к оптимизации относятся как к некоторому абстрактному понятию, не несущему никакой другой нагрузки, кроме эмоциональной: «теперь мы решим все проблемы», при этом, не уделяя никакого внимания критериям оптимизации — какой процесс, насколько улучшить и в каких допустимых пределах.
Если с определением направлений улучшений обычно затруднений не возникает (например, «необходимо сократить время выполнения процесса согласования заявки заказчика»), то с определением и оцифровкой показателей улучшений возникают проблемы. Во многих компаниях не используются системы сбалансированных показателей, и определить «насколько улучшить» становится невозможным, т. к. показатели, характеризующие функционирование конкретного процесса, не определены и не рассчитываются. Таким образом, измерение улучшений зачастую происходит субъективно, «по ощущениям».
Отдельный момент — установление допустимых пределов для изменений. Не секрет, что руководитель или собственник компании на этапе начала работ по совершенствованию устанавливает ряд ограничений и запретов, сводя своими действиями оптимизацию на уровень косметических изменений, неспособных что-либо кардинально улучшить в сложившейся ситуации.
Про инструменты и методологии
Как правило, вопросу выбора инструментов и методологий при инициации работ по формализации бизнес-процессов уделяется минимум внимания. Подразумевается, что нет большой разницы в том, какие системы бизнес-моделирования и какие методологии использовать. Тем не менее, определяющим фактором в вопросе выбора программного обеспечения и методологии должны быть цели, которые планируется достигнуть при реализации проекта по описанию и оптимизации бизнес-процессов.
В зависимости от поставленных целей, фазы развития организации и состояния системы управления можно выделить два подхода к формированию бизнес-модели компании:
- Выделение и описание набора отдельных бизнес-процессов компании — позволяет в сжатые сроки выявить причинно-следственные связи и временную последовательность выполнения действий, формализовать процессы и процедуры с акцентом на определение участников, исполнителей, начальных и конечных событий, последовательность действий, движение потоков объектов;
- Создание комплексной модели бизнес-процессов — позволяет создать комплексную непротиворечивую бизнес-модель компании с акцентом на создание описания системы, выделение и описание объектов управления.
Данные подходы не являются взаимоисключающими, опыт показывает, что возможны ситуации, когда необходимо решение задач как описания системы в целом, так и описания отдельных (локальных) бизнес-процессов. В данном случае следует двигаться от общего к частному: сначала создавать модель системы в целом и только потом, используя ее как базис, формировать модели отдельных бизнес-процессов.
Вопрос выбора программного обеспечения обычно относится к узкоспециальным и часто передается для решения специалистам ИТ-подразделений с минимальным участием руководителя компании. Тем не менее, не стоит забывать, что методики и инструменты описания бизнес-процессов специализированы и не подходят для решения задач, для которых они не предназначены. Попытка использования для формирования комплексной модели бизнес-процессов выбранной техническими специалистами системы, предназначенной для описания алгоритмов и взаимосвязей операционного уровня, с большой долей вероятности потребует дополнительных финансовых затрат на доработку системы, сделает выполнение задачи сложным, длительным по срокам или просто невозможным.
Что можно получить в итоге
В большинстве случаев руководитель компании, инициируя проект по описанию бизнес-процессов, не учитывает все то, что было описано выше, а сама идея реализации подобного проекта получена им откуда-то извне.
В сложившейся ситуации формулировка задачи на проект сводится к «нам необходимо в сжатые сроки описать бизнес-процессы нашей компании». Если попытаться определить данную необходимость и задать несколько уточняющих вопросов, то ответ скорее будет логически не связанным с поставленной задачей.
Следующим шагом в компании создается структурное подразделение, в штат которого входят аналитики, или принимается решение о привлечении сторонних консультантов для реализации проекта. Возможные варианты дальнейшего развития событий следующие:
- Исполнитель (аналитики компании или внешние консультанты), не задавая лишних вопросов, добросовестно приступают к выполнению работ по проекту. При этом, т. к. четких указаний, что описывать, на этапе начала работ не было, описываются либо все процессы подряд, либо те, которые определяет руководитель компании. Дни проходят один за другим, проект, казалось бы, успешно реализуется, вот только полученный результат не оправдывает вложенных средств. Бизнес-процессы описаны так, как это действительно происходит в компании, полученные модели сложные, запутанные и зачастую не пригодны для дальнейшего использования. Несмотря на это исполнитель предпринимает попытку оптимизации процессов, но в силу недостаточного опыта работы в компании, используя мнение узкого круга лиц, не принимая во внимание взаимосвязи между процессами, по факту не улучшает ничего. В результате потрачено значительное количество времени и ресурсов, текущие проблемы бизнеса не решены, а у руководителя появляется негативный опыт, не позволяющий ему вернуться к подобной работе в дальнейшем;
- Исполнитель начинает задавать вопросы, уточняя, зачем необходимо описание бизнес-процессов, какой результат планируется достигнуть, какие критерии оптимизации установлены. На этом этапе может быть получен серьезный негатив от руководства компании, потому что, во-первых, ответов просто нет, а во-вторых, задача описания процессов формальная, не подкрепленная логической цепочкой выводов и подзадач. Выясняется ряд «особенностей» бизнеса, которые неприятны руководителю компании и на которые раньше он «закрывал глаза»:
- Вдруг выясняется, что описание процессов «как есть» невозможно, просто потому, что их в компании нет — деятельность выполняется на основании опыта сотрудников, решения принимаются по ситуации, и даже регулярные процессы выполняются не так, как закреплено в регламентах, а так, как удобно исполнителям;
- Бизнес подвержен внешним или внутренним рискам, отсутствуют целевые показатели, система мотивации не способствует повышению качества продукции/услуг, учет затрат ведется не в полном объеме или отсутствует;
- При описании процессов выявляется необходимость проведения существенных изменений в модели бизнеса.
Не стоит забывать про то, что если процессы в ходе описания оптимизированы, то после завершения проекта по описанию и оптимизации бизнес-процессов необходим еще один проект — внедрение новых версий бизнес-процессов в практику применения персоналом компании. Вот только этот проект потребует гораздо больше усилий для того, чтобы изменить сложившиеся годами устои на новые, необычные, разработанные без участия большинства сотрудников.
Таким образом, описание и оптимизация бизнес-процессов — задача, требующая, кроме опыта и знаний аналитиков, личной заинтересованности, готовности к изменениям, четкого понимания необходимости проекта, а также способов достижения установленных целей со стороны руководителя компании. В противном случае, столкнувшись с описанными выше проблемами и вопросами, когда будет необходимо внести изменения в действующий бизнес — проект закончится, не успев начаться.
Лучшие практики
Задачи описания бизнес-процессов сегодня актуальны для многих крупных российских компаний, независимо от отраслевой принадлежности. В большинстве случаев для их решения формируются аналитические подразделения, которые создают модели действующего бизнеса, отражающие особенности функционирования внутренних бизнес-процессов.
Формирование полноценной бизнес-модели компании — высокотрудоемкая задача, требующая внимательной проработки ключевых этапов до начала работ. Бизнес-задача, сетевой график, отчетность и регламентация, глубина и методология описания — базовые вопросы, которые должны быть решены до начала работ, иначе полученный результат не оправдает ожидания.
Настоящий раздел содержит рекомендации по подготовке и реализации проекта по описанию и оптимизации бизнес-процессов. Раздел подготовлен на основании личного опыта автора статьи по итогам реализации проекта на предприятии энергетического машиностроения, а также с учетом лучших практик других компаний, примененных в ходе выполнения работ.
Допущения: проект реализован силами внутреннего аналитического подразделения компании, специалисты подразделения имеют опыт реализации проектов в области организационного развития, на момент начала работ в компании функционирует система менеджмента качества, в качестве системы бизнес-моделирования используется система Business Studio.
Этап первый — инициация проекта
Для реализации проекта формируется группа управления проектом, назначается куратор проекта, издается приказ о начале работ по описанию и оптимизации бизнес-процессов компании.
Куратором проекта рекомендуется назначать должностное лицо из числа заместителей генерального директора, руководителей департаментов, реализующих функции, связанные с развитием компании. Куратор должен быть наделен всеми необходимыми полномочиями для решения вопросов, связанных с выполнением работ по проекту.
Группа управления проектом включает в себя специалистов-аналитиков, которые образуют в дальнейшем Центр компетенции по бизнес-процессам компании. Если в компании внедрена и функционирует система менеджмента качества или интегрированная система менеджмента, специалисты подразделения, реализующего данные функции, также должны быть включены в группу управления проектом. Это позволит использовать накопленную базу знаний по процессам и проблемным зонам, интегрировать функции по описанию, оптимизации и внутреннему аудиту бизнес-процессов. Также в состав групп включаются технические эксперты по различным направлениям деятельности для получения экспертных мнений и оперативного решения спорных вопросов по функционированию отдельных процессов
Этап второй — бизнес-задача
На начальном этапе работ по описанию и оптимизации бизнес-процессов группой управления проектом должна быть проведена организационная диагностика. Цель — определение недостатков в работе компании, проблемных зон и причин неэффективности бизнес-процессов; повышение качества планирования работ по проекту.
Диагностика может проводиться классическим способом (интервьюирование, стратегическая сессия, анализ показателей эффективности) или с применением онлайн-системы BIZDIAGNOSTICS. Система BIZDIAGNOSTICS — управленческий инструмент, который позволяет быстро и с минимальными ресурсными затратами провести внутренний аудит компании и получить достоверную и объективную информацию о качестве системы управления компании, идентифицировать проблемные зоны и получить рекомендации по их устранению. Результаты организационной диагностики являются основой для формулирования бизнес-задачи на проект.
Типовой ошибкой является описание бизнес-процессов ради самого описания. Подобный подход приведет к негативной реакции бизнеса, который не получит значимых результатов после работы аналитиков, т. к. разработанная модель бизнес-процессов сама по себе значимым результатом не является. Это подрывает веру руководителя и топ-менеджмента компании в процессный подход в целом и процессное управление в частности, с последующими организационными решениями в части «оптимизации» численности внутренних аналитиков или полной остановки работ в данном направлении.
Для исключения данной ситуации на этапе организации работ необходимо определить потребителя и формализовать его требования к разрабатываемой модели бизнес-процессов. Лучше, если таких потребителей будет несколько. Например:
- Структурные подразделения компании, заинтересованные в регламентации и оптимизации своих бизнес-процессов;
- Подразделения, реализующие функции по поддержанию функционирования и развития систем менеджмента (системы менеджмента качества, интегрированной системы менеджмента), т. к. без процессного управления эффективное функционирование систем затруднительно;
- IT-подразделения, для которых модель процессов упрощает определение алгоритмов работы и формализацию требований к внедряемым информационным системам.
Требования потребителей также позволяют установить набор документов, которые будут формироваться на основе разработанной бизнес-модели компании. Это позволит определить информацию, (например, данные, необходимые для проведения функционально-стоимостного анализа), которая должна быть собрана в рамках проекта.
Формализация требований потребителей в виде технического задания позволит исключить большую часть «лишней» работы в проекте, выбрать программный продукт, наилучшим образом соответствующий поставленной задаче, а также получить значимый для бизнеса результат с меньшими временными, финансовыми и трудовыми затратами.
На основании результатов организационной диагностики и технического задания группой управления проектом после проведения сессии с руководителем и топ-менеджментом компании сформулирована бизнес-задача на проект — определены функциональные области для улучшений, критерии оптимизации (что и насколько улучшить), формализованы требования потребителей разрабатываемой модели бизнес-процессов компании. Также в бизнес-задаче должны быть однозначно определены четкие пределы для изменений (какие изменения бизнеса приемлемы, какие недопустимы). После утверждения бизнес-задачи разрабатывается сетевой график реализации проекта.
Этап третий — программное обеспечение
Следующим важным шагом является выбор программного обеспечения, необходимого для успешной реализации проекта — системы бизнес-моделирования.
Система бизнес-моделирования — программный продукт для создания и анализа бизнес-модели компании, проектирования новых бизнес-процессов, разработки и поддержания в актуальном состоянии пакета регламентирующей документации. Система играет большую роль в проекте по описанию бизнес-процессов, т. к. она обеспечивает единое информационное поле для совместной работы аналитиков, предоставляя им необходимый инструментарий для описания, анализа и оптимизации бизнес-процессов.
Выбор программного продукта осуществлялся по следующим критериям:
- Возможность выполнения полного комплекса работ по организационному проектированию;
- Автоматизированная система сбора и анализа результатов измерений эффективности бизнес-процессов компании;
- Автоматическое формирование пакета регламентирующей документации;
- Использование популярных нотаций моделирования бизнес-процессов, дружелюбный к пользователю интерфейс, не требующий проведения специализированного обучения пользователей;
- Поддержка системы менеджмента качества;
- Возможность гибкой настройки системы «под себя» (возможность ввода пользовательских параметров и справочников).
После анализа рынка систем бизнес-моделирования было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.
Этап четвертый — методология
Проект по описанию бизнес-процессов в крупной компании приводит к разработке большого количества моделей процессов. Если представить, что все диаграммы нарисованы по-разному, то полученный результат не будет представлять никакой практической ценности для компании. Именно поэтому важно определить четкие правила моделирования бизнес-процессов в компании. Для этого разрабатывается Соглашение о моделировании бизнес-процессов — документ, определяющий методологию описания бизнес-процессов, порядок взаимодействия участников процесса описания и оптимизации бизнес-процессов, а также механизмы ввода в действие формируемого пакета регламентирующей документации, поддержания актуального состояния разработанных моделей бизнес-процессов.
Соглашение о моделировании бизнес-процессов определяет используемые нотации моделирования, количество уровней декомпозиции (уровней последовательного разделения бизнес-процесса на составляющие подпроцессы для получения более детального представления), взаимосвязь моделей процессов между собой, пакеты формируемой документации, устанавливает правила работы с объектами и справочниками в системе бизнес-моделирования, определяет параметры, подлежащие заполнению в системе. После ввода в действие данного документа группа управления проектом обязана контролировать его соблюдение всеми сотрудниками компании, вовлеченными в проект по описанию и оптимизации бизнес-процессов. Это обеспечит унификацию разрабатываемых моделей, сведет к минимуму временные затраты на устранение возникающих «ошибок», в т. ч. при работе в системе бизнес-моделирования, позволит получить пакет регламентирующей документации, наиболее соответствующей требованиям потребителей описания бизнес-процессов.
При определении уровней декомпозиции бизнес-процессов следует акцентировать внимание на требованиях потребителей описания бизнес-процессов, их обоснованности, необходимости и достаточности детализации при описании. Очень часто модели бизнес-процессов декомпозируются до уровня отдельных действий сотрудников там, где это нецелесообразно. Это приводит к увеличению количества разрабатываемых моделей, значительному росту трудоемкости без увеличения ценности моделей для развития бизнеса, т. к. излишняя детализация не всегда дает информацию для оптимизации процессов.
Практика показывает, что каждый новый уровень декомпозиции увеличивает объем моделей на порядок. Поэтому, если необходимо оптимизировать процессы и определить зоны ответственности между структурными подразделениями компании, следует ограничиться детализацией до уровня подразделений. Выход на уровень элементарных действий применяется, только если модель разрабатывается для целей автоматизации или регламентации деятельности отдельных исполнителей.
Начиная проект, вместе с определением требований его потребителей, необходимо установить, какие элементы окружения необходимо описать. Среди предметных областей, подлежащих формализации, следует выделить:
- Организационную структуру;
- Информационные системы, поддерживающие выполнение бизнес-процессов;
- Носители информации, используемые в процессах.
В ряде случаев формируемую модель могут дополнять показатели эффективности, требования к информационным системам и т. п. Таким образом, бизнес-модель, кроме собственно описания процессов, интегрирует в себе различные предметные области, что значительно повышает ее практическую ценность для дальнейшего анализа и оптимизации.
Этап пятый — бизнес-модель, рабочие группы
Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.
Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации бизнес-процессов
Итак, следующий шаг — разработка модели бизнес-процессов верхнего уровня. Она позволяет получить единый взгляд на устройство бизнеса. Формирование модели лучше проводить с акцентом на создание ценности, используя принципы определения и построения цепочек создания ценности. Разработка модели проводится в формате стратегической сессии или деловой игры с участием руководителя и топ-менеджмента компании. Для разработки модели бизнес-процессов верхнего уровня наиболее удобно использовать нотацию IDEF0.
При разработке модели рекомендуется использовать информацию по структуре бизнес-процессов компаний аналогичной отрасли, отраслевые референтные модели. Готовая модель должна системно показать бизнес-процессы верхнего уровня компании, а также наиболее важные взаимосвязи между ними, необходимые для понимания функционирования бизнеса.
На основании утвержденной бизнес-модели происходит назначение владельцев бизнес-процессов (с ориентацией на действующую организационную структуру компании), а также формирование рабочих групп по описанию и оптимизации бизнес-процессов по каждому из бизнес-процессов верхнего уровня. В целях регламентации деятельности владельцев бизнес-процессов, определения полномочий и разграничения ответственности разрабатывается Должностная инструкция владельца бизнес-процесса. Цель — установление ответственности за результат процесса, определение должностных обязанностей, а также полномочий для распоряжения ресурсами, необходимыми для выполнения процесса.
В рамках проекта владельцы бизнес-процессов отвечают за обеспечение выполнения работ по:
- Описанию и оптимизации своих бизнес-процессов;
- Выработке предложений по оптимизации бизнес-процессов;
- Анализу и согласованию предложений по оптимизации бизнес-процессов, сформированных участниками рабочих групп.
Группой управления проектом совместно с владельцами бизнес-процессов проводится формирование рабочих групп по описанию бизнес-процессов верхнего уровня. В состав групп включаются руководители и специалисты структурных подразделений компании, имеющие, в силу своего опыта работы в компании или состава должностных обязанностей, достаточное представление о бизнес-процессе, подлежащем описанию и оптимизации. Рабочие группы возглавляет руководитель рабочей группы. Он назначается из числа руководителей структурных подразделений, принимающих участие в выполнении соответствующего бизнес-процесса. Численность рабочей группы варьируется в зависимости от «объема» и сложности конкретного бизнес-процесса.
В рамках проекта на участников рабочих групп возлагаются обязанности по разработке модели бизнес-процессов, подготовке предложений по оптимизации бизнес-процессов, подготовке и проведению согласования разработанного пакета регламентирующей документации. Для эффективного выполнения работ по проекту рабочее время участников групп распределяется в соотношении 30/70 (проект/должностные обязанности) приказом руководителя компании.
После выполнения всех вышеперечисленных подготовительных мероприятий и установки системы бизнес-моделирования на рабочие станции пользователей проводится обучение участников рабочих групп и, при необходимости, руководителей среднего и высшего звена компании методикам и принципам описания и оптимизации бизнес-процессов. Обучение рекомендуется разделять на теоретическую (для всех) и практическую (для участников рабочих групп) части. Большее время необходимо уделять практике описания бизнес-процессов и работе с системой бизнес-моделирования, отрабатывая на простых примерах навыки работы и демонстрируя «классические» ошибки.
Обучение может проводиться как сторонней организацией, так и членами группы управления проектами при наличии достаточных компетенций и опыта работы с используемой системой бизнес-моделирования.
Этап шестой — моделирование, оптимизация
После обучения рабочими группами проводится анализ деятельности структурных подразделений, идентификация и структурирование бизнес-процессов, которые в них выполняются. Информация вносится в дерево процессов системы бизнес-моделирования с указанием наименования процесса, руководителя, ответственного за его выполнение, участников, инициирующих/завершающих событий и результатов.
После идентификации процессов в формате деловой игры проводится перекрестное согласование процессов, представляющих собой 1-й уровень декомпозиции бизнес-процессов верхнего уровня, при необходимости производится доработка полученной структуры.
Следующим шагом является установление взаимосвязей между подпроцессами 1-го уровня декомпозиции через входы и выходы, наполнение модели информационными потоками и потоками объектов. Переход на 2-й уровень декомпозиции, введение информации в систему бизнес-моделирования и согласование структуры подпроцессов проводится аналогично.
Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации бизнес-процессов назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).
После завершения работ на 2-м уровне декомпозиции моделей бизнес-процессов верхнего уровня выполняется согласование границ подпроцессов и бизнес-процессов верхнего уровня по входам/ выходам, началу и результату процесса. Чтобы минимизировать временные затраты на согласование, рекомендуется проводить его в формате деловых игр, построенных по принципу докладов, в которых рабочие группы «моделируют» свой процесс, проговаривают его от момента начала до получения итогового результата, а остальные участники (владельцы процессов, представители группы управления проектом, куратор проекта, технические эксперты) вносят необходимые корректировки. При необходимости в ходе деловых игр участники игры вырабатывают совместные решения по спорным вопросам, возникающим в ходе описания бизнес-процессов. Как правило, в результате согласования происходит корректировка структуры процессов в бизнес-модели компании.
Полученная первая версия бизнес-модели компании подлежит дальнейшей декомпозиции — разрабатываются модели 3-го, 4-го уровня. Согласование данных моделей проводится в формате деловой игры с привлечением владельца процесса, представителей группы управления проектом, владельцев процессов-потребителей результатов бизнес-процесса, технических экспертов. В ходе согласования уточняется движение информационных потоков и потоков объектов, уточняются должности руководителей, ответственных за выполнение процессов, состав участников на уровне структурных подразделений и должностей сотрудников.
После получения второй версии бизнес-модели проводится ее финальное согласование, результатом является третья, основная рабочая версия, которая будет являться базисом корпоративной базы знаний по бизнес-процессам компании. На основе этой базы знаний будут проводиться мероприятия по дальнейшей оптимизации бизнес-процессов или разработке методик и процедур уровня элементарных действий.
Для бизнеса важно получение быстрого результата от вложенных инвестиций. Проект по описанию и оптимизации бизнес-процессов — не исключение, тем более что он направлен на повышение эффективности деятельности компании в целом. Для того чтобы показать значимый результат в приемлемые сроки, на этапе описания бизнес-процессов рекомендуется сформировать предложения по оптимизации бизнес-процессов с использованием инструментов выявления и устранения потерь, принципов и методов оптимизации бизнес-процессов. Предложения по оптимизации бизнес-процессов рассматриваются в ходе деловых игр с участием представителей группы управления проектом, владельцев процессов и всех заинтересованных лиц и, в случае согласования, отражаются в разрабатываемой бизнес-модели.
Этап седьмой — внедрение
После согласования финальной версии модели бизнес-процессов компании деятельность по описанию и оптимизации бизнес-процессов переводится на постоянную основу — как говорилось ранее, группа управления проектом становится Центром компетенций по бизнес-процессам компании, участники рабочих групп по описанию и оптимизации бизнес-процессов продолжают совмещать свою текущую деятельность в структурных подразделениях компании с моделированием, анализом и регламентацией своих бизнес-процессов.
Разработанные модели бизнес-процессов и регламентирующая документация вводится в действие приказом руководителя компании. Информация доводится до сотрудников в соответствии с правилами, установленными в компании, а также с использованием HTML-навигатора, размещенном на корпоративном сетевом ресурсе.
Соблюдение требований введенных в действие регламентов и процедур проверяется в ходе внутренних аудитов, проводимых внутренними аудиторами (если в компании действуют системы менеджмента) или специалистами внутреннего аналитического подразделения. Порядок и сроки проведения аудитов устанавливаются соответствующим регламентирующим документом. Эффективность деятельности компании оценивается по результатам организационной диагностики, а также по данным мониторинга показателей эффективности бизнес-процессов.
Практика показывает, что на момент начала работ по описанию и оптимизации бизнес-процессов в компаниях уже имеется большой пакет регламентирующей документации (особенно характерно для компаний, в которых действуют системы менеджмента). Часть документов из данного пакета зачастую нецелесообразно переносить в систему бизнес-моделирования для будущего формирования в автоматическом режиме ввиду больших временных и трудозатрат. Для синхронизации имеющихся документов с новыми версиями процессов компании на этапе описания процессов необходимо проводить их анализ на предмет актуальности. После согласования финальной версии бизнес-модели выполняется полная актуализация имевшейся документации с привязкой к новым версиям бизнес-процессов.
Вместо заключения
Резюмируя вышесказанное, хочется отметить, что, как и в любом сложном деле, при улучшении деятельности компании важно точное понимание причин инициирования проекта и использование в проекте наилучших методик и инструментов. Надеемся, что эта статья снимет множество вопросов, которые возникают у руководителей, и позволит легче решиться на начало изменений. Уверены, что результат не заставит себя ждать!
Опубликовано по материалам:
Журнал E-xecutive.ru
Январь 2013г.
Рекомендуемые материалы по тематике
Документооборот — отдельный фрагмент общей картины
Управление рисками: модель процесса и компетенций
Процессный подход: простая методика внедрения
Глоссарий
Разработка бизнес-процессов Битрикс24 — Axbit
Бизнес-процессы Битрикс24 — функциональность системы, многократно расширяющая ее возможности. В доброй половине случаев автоматизация бизнес-процессов позволяет закрыть потребности в функциях, не входящих в стандартную поставку продукта, даже не прибегая к программированию.Автоматизация бизнес-процессов даёт вам возможность:
- отладить документооборот;
- автоматизировать процесс продаж;
- выполнять в системе сложные отраслевые задачи.
Разработка бизнес-процессов — это комплексная работа:
Разработка бизнес-процессов производится в несколько этапов:
Этап | Описание |
Аудит бизнес-процессов | Наши специалисты анализируют бизнес-процессы вашей компании, выявляют те, которые могут быть автоматизированы, опрашивают участников и готовят описание процессов. |
Моделирование бизнес-процессов | Схемы бизнес-процессов моделируются при помощи встроенного графического дизайнера процессов Битрикс 24 — визуального инструмента, позволяющего создавать бизнес-процессы без помощи программирования. Созданные таким образом процессы вы в любой момент можете изменить. |
Отладка и тестирование | Процессы проверяются на группе ключевых пользователей на предмет удобства использования, вносятся правки, после чего процесс масштабируется на всех сотрудников, участвующих в нем. |
Обучение или поддержка | Возможны два варианта постпроектного обслуживания. Мы можем как продолжать сотрудничество с вами в рамках сопровождения, автоматизируя новые процессы и обновляя существующие, так и провести обучение для ваших администраторов Битрикс24 по дизайну и разработке бизнес-процессов. |
Оптимизация бизнес-процессов
Успех требует стратегического подхода к расстановке приоритетов, выстраиванию и поддержанию на должном уровне хозяйственной деятельности. Мы поможем вам разработать стратегию вашей компании и донести её до заинтересованных сторон. Для этого у нас имеются проверенные на практике методики и инструменты. Разработанная нами стратегия будет тесно увязана с операционной деятельностью вашей компании и тем самым обеспечит вашему бизнесу устойчивый результат в долгосрочной перспективе.
Вопросы, стоящие перед Вами сегодня
- В результате бурного роста вашей компании некоторые функции стали дублировать друг друга, круг обязанностей руководства приобрел нечеткие границы и значительно возросли затраты на бизнес-процессы.
- Отсутствуют чёткие стандарты выполнения ряда бизнес-процессов, что привело к необходимости усовершенствования этих процессов.
- Вы хотите узнать, как работают наиболее успешные компании в вашей отрасли, и освоить передовой опыт.
Мы предлагаем
Усовершенствование бизнес-процессов
- Пересмотр существующих бизнес-процессов
- Выявление областей, в которых необходимы улучшения
- Использование специального инструментария для оценки зрелости вашего бизнеса
- Оценка передового опыта других стран с точки зрения его применимости в конкретных условиях и способности обеспечить желаемый результат
- Определение областей, требующих надзора и контроля
- Реорганизация бизнес-процессов и согласование новой модели бизнес-процессов с ответственными лицами и заинтересованными сторонами
Моделирование существующих процессов
- Определение критериев и выбор соответствующего программного обеспечения для моделирования бизнес-процессов
- Разработка целевой модели для иерархических процессов
- Проведение собеседований с сотрудниками для разработки процедур картирования бизнес-процессов
- Моделирование непрерывного процесса контроля качества
- Обучение сотрудников методике моделирования
Преимущества работы с нами
- Сокращение затрат и повышение качества бизнес-процессов.
- Для руководителей, аудиторов, внешних партнеров и инвесторов бизнес-процессы становятся более понятными и прозрачными.
- Ясные и понятные процедуры взаимодействия между подразделениями и сотрудниками.
- Стандартизация бизнес-процессов и повышение эффективности деятельности на всех уровнях и во всех подразделениях организации.
- Упрощение модели обучения для новых сотрудников.
- Максимальное повышение эффективности процессов управления рисками.
Автоматизируя бизнес процессы: как упорядочить хаос
Автоматизация бизнес-процессов порой представляется руководителю волшебной палочкой. Только как автоматизировать бизнес-процессы наилучшим образом? Чтобы работа спорилась, бумаги не терялись, регламент помогал, команда действовала, как отлаженный механизм?
В статье разберем нюансы построения и автоматизации бизнес-процессов, рассмотрим, как избежать ошибок, каковы цели и задачи автоматизации бизнес-процессов и с чего начать. Если Вы задумываетесь об улучшении бизнес-процессов и, возможно, о внедрении электронной системы управления ими, внимательно прочтите статью. И берите на карандаш!
Три кита хаоса в бизнесе: как автоматизировать процессы, которых нет
Прежде, чем говорить о том, какие возможности открывает автоматизация бизнес-процессов, давайте подумаем, с какими трудностями Вы сталкиваетесь сейчас.
Три нехороших «кита», на которых держится хаос в бизнесе, универсальны. Скорее всего, Вы с ними тоже знакомы:
- Регулярные ошибки. Петров сделал опечатку, Сидоров завизировал непроверенный документ, Васечкина отправила счет с неправильными реквизитами. Подобные ошибки приносят временные и финансовые потери, дергающийся глаз и работу по ночам.
- Простои. Документ на согласовании неделю, потом вторую, работа стоит. Ключевой сотрудник в отпуске или уволился, не передав дела.
- Общая неразбериха. Куда делась нужная бумага? Почему секретарь в кипе листов не заметил срочный документ? Куда бежать специалисту при обращении клиента, если нужный человек отсутствует? Эта путаница и беготня по коридорам с пачками бумаг раздражают и уж точно не способствуют продуктивной работе.
Еще 10 лет назад моделирование бизнес-процессов большинству компаний казалось трудом дорогим, долгим и потому излишним. Некоторые думают так и сейчас, начитавшись страшных историй о незаконченных проектах и потраченных миллионах, а то и сами подойдя к автоматизации не с того бока. Но оказалось, что компании, работающие над автоматизацией бизнес-процессов, быстрее растут, лучше преодолевают кризисные времена и обходят конкурентов. В таких компаниях сотрудники чувствуют себя комфортнее, что создает правильную рабочую атмосферу в команде. Примерами могут послужить истории Toyota, Amazon, McDonalds, а также — наших клиентов, чьи отзывы об автоматизации бизнес-процессов можно почитать.
Сегодня умение строить бизнес-процессы и знание, как их автоматизировать, становятся важным конкурентным преимуществом.
Бизнес-процессы: что автоматизируем, товарищи?
Иногда менеджмент компании, занятый стратегическими вопросами, пребывает в заблуждении: у нас все отлажено. Но если Петров знает, что в случае возникновения задачи по маркетингу нужно обратиться к Ивановой, это не бизнес-процесс. А вот конкретная карта действий, универсальным образом описывающая шаги, которые проходят сотрудники для достижения конкретного результата, это уже на бизнес-процесс похоже.
Схема действий, чтобы называть ее бизнес-процессом, должна учитывать три фактора:
- Устойчивость описанных связей: учтены множественность выбора действий, переходы, условия.
- Регламентирование действий по ходу процесса: звонки, письма, вложения, обращения, визирования.
- Логическое завершение: конкретная досягаемая цель.
Четко смоделированный бизнес-процесс позволит и видеть результат, и контролировать работу на всех этапах, чтобы предотвратить потери и ошибки «на низком старте».
В зависимости от возникновения «тонких мест» бизнес-процесс меняют, корректируют его этапы, смотрят, какие звенья слабы. Если же у Вас возникают трудности с разработкой алгоритмов, мы готовы оказать Вам помощь. Ведь разработка бизнес-процессов — это подготовка к проекту их автоматизации.
Здорово ли сердце вашего бизнеса?
Обратитесь сегодня и получите индивидуальное предложение Бизнес-процессы — сердце компании. Как узнать, в форме ли ваш бизнес? Обратитесь к нам и узнайте, как получить максимум от бизнес-процессов и раскрыть полный потенциал вашей компании.
Заказать консультацию
Основная цель разработки бизнес-процессов — это волшебное превращение хаотично сплетенных цепочек внутрифирменных взаимодействий в упорядоченные, согласованные и понятные алгоритмы. Да будет порядок в работе, офисе, в головах сотрудников и в умах руководителей!
Ури, где кнопка? Цели автоматизации бизнес-процессов
Теперь вопрос: как всем этим управлять? Это ж нужен целый штат сотрудников — держать руку на пульсе и внимательно следить за «тонкими местами», «слабыми звеньями» и исполнением всего, что должно исполняться!
Четверть компаний по такому пути и идет, разворачивая отделы качества, расширяя управленческий и секретарский состав. Но гораздо полезнее задаться вопросом, как автоматизировать бизнес-процессы и перенести функцию контроля над ними в одно пространство. Такая система управления бизнес-процессами будет и конструктором, и механизмом мониторинга, и контролером, подающим сигналы, когда что-то идет не по плану. Но чтобы «волшебная кнопка» заработала, все-таки придется потрудиться.
Конечно, цели автоматизации бизнес-процессов заключаются не только в удобном способе контроля. В итоге использование автоматизированной системы управления бизнес-процессами поможет:
- Упорядочить регулярные задачи.
- Минимизировать человеческий фактор.
- Четко разделить зоны ответственности внутри процессов.
- Держать под контролем все детали процесса.
- Включить в схему взаимодействия клиентов.
- Создать единую ИТ-инфраструктуру с различными правами доступа.
- Экономить время, свое и сотрудниковю.
- В итоге — экономить средства на управлении компанией.
Как видите, цели автоматизации бизнес-процессов во многом совпадают и с вашими!
Управление бизнес-процессами — система одной компании
Чтобы было еще понятнее, разберем конкретные функции системы управления бизнес-процессами — «1С:Документооборот 8» — на примерах.
- Настройка прав доступа не дает специалисту Петрову провернуть сделку напрямую, лишив компанию доли прибыли. Еще Петров не может скачать клиентскую базу компании и начать маленькую, но гордую предпринимательскую деятельность.
- Секретарь Бантикова знает, сколько документов пришло и ушло, сколько на согласовании у начальника, сколько поступило писем клиентов. Благодаря системе Бантикова в курсе, по каким документам сроки горят или уже сгорели. Начальник Бантиковой тоже в курсе.
- Руководитель филиала Береговский знает, на каком этапе работа с каждым клиентом. С кем в ближайшую неделю будет заключен договор, а с кем работа застопорилась и по каким причинам.
- Руководитель проекта Сидорова оперативно видит этапы сложного согласования с использованием условий маршрутизации, с резолюциями занятых в процессе лиц и контрагентов.
- Менеджер Утюжкин заключает типовой договор. Для этого он в несколько кликов соединяет данные контрагента с шаблоном договора. За 3–4 секунды Утюжкин получает договор, текст которого уже проверен и согласован, и даже подпись стоит (если настроена функция электронной подписи).
- Архивариус Семируков не переживает, что с бумажными документами случится хаос. Все документы он заносит в систему, знает, где какой лежит, какой номер для договора следующий, от какого клиента какая бумага когда пришла или придет.
- Руководитель Рулькин, работая с системой документооборота, удобно и быстро рассчитывает план проекта, движется по нему вместе с командой и контролирует сроки реализации. Рулькин знает, что происходит в каждом проекте компании.
- Бухгалтеру Канарейкиной не нужно требовать от коллег закрывающих документов. Ведь Канарейкина работает в программе «1С:Бухгалтерия», которая обменивается данными с системой «1С:Документооборот» (кстати, как и другие типовые программы линейки «1С:Предприятие 8»). А туда коллеги информацию давно занесли. А если бы не занесли, то им об этом давно напомнили бы секретарь Бантикова, руководитель Рулькин и менеджер Утюжкин, заинтересованные в данной процедуре.
- Кстати, менеджер Утюжкин, выезжая на переговоры, не таскает с собой тяжелый ноутбук, а обходится планшетом или даже смартфоном. Ведь у него настроен доступ к нужной информации с мобильных устройств.
Наглядно мы увидели, чем автоматизированный бизнес-процесс отличается от «сверстанного на коленке». Остается понять, как же прийти к такому уровню автоматизации.
Секретный ингредиент: как автоматизировать бизнес-процессы без потерь
Наверняка Вы слышали истории о компании N, которая внедрила у себя суперсистему, повозилась с ней и, плюнув, вернулась к Excel. Так случается, когда компания сталкивается с непредвиденными сложностями. То сотрудники саботируют непривычный способ работы. То устоявшиеся процессы никак не поддаются регламентации. То бюджет внедрения выходит за рамки желаемого. То сама система тяжела и непонятна, а нужно чтобы «вот тут была кнопка, я ее нажимаю, и все работает».
Руководители часто забывают правило: первый этап, из которых строится автоматизация бизнес-процессов, — задачи. У системы управления документооборотом огромный функционал, способный удовлетворить требования самого прихотливого бизнеса. Но ведь для начала эти требования нужно предъявить.
Наши исследования подтверждают: 70 % трудностей у бизнеса возникает как раз на этапе фиксирования требований и результатов. Поэтому мы оказываем первичные консультации, а также предлагаем услугу предпроектного исследования. Этот этап помогает:
- выявить «тонкие места» в компании,
- определить, какие цели стоят перед системой автоматизации,
- понять, подойдет ли компании типовой функционал или нужно вносить изменения,
- выяснить, какой набор функций будет для бизнеса оптимален,
- определить, какие процессы автоматизировать в первую очередь, а что можно и отложить. Например, участки, тормозящие работу всей компании, нужно ставить в приоритет, даже если работа по ним предстоит не самая простая.
Грамотное фиксирование требований к системе и результатов — это секретный ингредиент успеха проекта автоматизации. Иногда на этом этапе становится понятно, что с бизнес-процессами беда. Тогда нужно их доработать или построить с нуля.
Определившись с задачами, которые стоят перед автоматизацией бизнес-процессов, переходим к формированию проектной команды и к реализации проекта.
Хотите узнать, каких результатов сможет достичь конкретно Ваш бизнес? Обращайтесь к нам для бесплатной консультации — расскажем!
Анализ и разработка бизнес процессов: курсовая работа
Как написать курсовую работу на тему анализа, проектирования и разработки бизнес процессов. Актуальность цели и задач исследования во введении курсового проекта, суть и особенности, а также готовый образец плана, содержания и возможность бесплатно скачать.
Актуальность анализа бизнес-процессов в курсовой работе обусловлена необходимостью синхронизации потребностей бизнеса и возможностей инфраструктуры в целом и информационных технологий в частности. В контексте анализа, проектирования и разработки бизнес-процессов необходимо тщательно исследовать ключевые процессы и информационные потоки, в том числе с использованием таких инструментов, как декомпозиция функций/процессов или анализ бизнес-событий. Для более глубокого понимания сути в данной статье представлены рекомендации по написанию таких тем курсовых работ по анализу бизнес-процессов, пример которых приведен в таблице ниже.
1. Курсовая работа: Стандарты описания и анализа бизнес-процессов | 2. Курсовая: Проектирование бизнес-процессов обновленной модели деятельности организации |
3. Курсовой проект: Анализ бизнес-процессов как один из элементов управления | 4. Курсовая работа: Методы описания и анализа бизнес-процессов |
В качестве предмета изучения в курсовой работе по разработке бизнес-процессов рекомендуется выбрать деятельность предприятия, а в качестве объекта исследования непосредственно бизнес-процессы. Как правило, целью курсовой по анализу бизнес-процессов является снижение издержек и повышение эффективности работы посредством проектирования и разработки оптимальных бизнес-процессов. Для достижения поставленной цели, необходимо решить следующие задачи:
1. Исследовать понятие и технологию описания бизнес-процессов.
2. Провести анализ возможности снижения издержек посредством проектирования и разработки оптимальных бизнес-процессов (подробно об этом изложено здесь).
3. Исследовать организационную структуру и бизнес-процессы предприятия.
4. Провести анализ бизнес-процессов.
5. Оптимизировать бизнес архитектуру и усовершенствовать технологическую архитектуру предприятия.
6. Оценить экономическую эффективность проектирования и разработки оптимальных бизнес-процессов предприятия.
Во введении курсовой работы следует отразить научную новизну и практическую ценность исследования. Так, практическая значимость курсового проекта по бизнес проектированию может заключаться в разработке проекта усовершенствованной архитектуры малого предприятия, которое приведет к снижению издержек и повышению эффективности работы.
Таким образом, в курсовой работе по анализу бизнес-процессов рекомендуется рассмотреть такие вопросы, как:
1. Теоретические сведения о подходах к анализу, проектированию и разработке бизнес-процессов.
2. Описание деятельности предприятия, исследование ключевых бизнес-процессов и анализ базовых показателей деятельности.
3. Проект по совершенствованию бизнес-процессов предприятия.
По сути, анализ бизнес-процессов в курсовой работе заключается в анализе всей доступной информации по бизнес-процессам, измерении их показателей, а также проведении сравнительного анализа. Приведем классификацию видов анализа бизнес-процессов на рисунке 1.
Рисунок 1 – Классификация методов анализа бизнес-процессов в курсовой работе
В первую очередь в курсовой по анализу бизнес-процессов следует определить структуру организации и выделить границы участия каждого из участников в процессе работы. В качестве примера приведем организационную структуру барбершопа на рисунке 2. Такая организационная структура состоит из десяти человек: директор, бухгалтер-экономист, администратор, 6 барберов, менеджер по продвижению барбершопа.
Рисунок 2 – Модель организационной структуры барбершопа
Далее следует выделить основные подсистемы в структуре и описать их функции. В качестве примера приведем таблицу ниже.
На базе полученной информации, в курсовой работе следует подробно описать выявленные бизнес-процессы и исследовать их в разрезе подразделений барбершопа (рисунок 3).
Рисунок 3 – Анализ бизнес-процессов в разрезе подразделений барбершопа
Анализ бизнес-процессов в курсовой работе реализуется также посредством разработки моделей бизнес-процессов в различных нотациях. В качестве примера на рисунке 4 приведен бизнес-процесс обслуживания клиента в барбершопе с использованием нотации EPC.
Рисунок 4 – Описание бизнес-процесса обслуживания клиента с использованием нотации EPC
Анализ финансовой деятельности является неотъемлемым этапом анализа бизнес-процессов и позволяет объективно оценить результаты деятельности организации, ее структурных подразделений, а также определить влияние факторов на основные показатели финансово-хозяйственной деятельности. Основными составными частями финансово-экономического анализа являются:
1. Анализ прибыли, доходов и затрат.
2. Анализ бухгалтерской отчетности.
3. Расчет финансовых коэффициентов.
4. Оценка значений финансовых коэффициентов.
В качестве примера приведены рисунки 5 и 6, на которых представлена информация о движении денежных средств и структура выручки организации.
Рисунок 5 – Движение денежных средств организации
Рисунок 6 – Структура выручки организации
На основании проведенного всестороннего анализа бизнес-процессов в результате рекомендуется сделать вывод о необходимости улучшения финансового состояния, снижения издержек и повышения эффективности работы за счет проектирования и разработки в курсовой работе бизнес-процессов, отвечающих современных условиям экономики.
В заключение следует отметить, что написать качественную курсовую работу по анализу бизнес-процессов Вам поможет полный перечень актуальных статей и рекомендаций по моделированию и реинжинирингу бизнес-процессов, изложенный здесь.
Гибкая разработка бизнес-процессов: почему, как и когда — применение теории трансформации знаний Нонака к разработке бизнес-процессов
Как было указано во введении, исследование, представленное в этой статье, было основано на нашем собственном опыте построения программных систем. / услуги по поддержке бизнес-процессов и внедрению их в организационную практику. Опыт был получен в ряде проектов, которые начинались с картирования бизнес-процессов и заканчивались системой, внедренной на практике в нескольких организациях.Анализ нашего опыта в этой статье касается не принципов, на которых были разработаны процессы и системы, а цикла разработки процесса и системы. В этом разделе мы представим два разных подхода, используемых в нашей практике: первый — это традиционный подход, а второй можно рассматривать как гибкий подход.
Традиционный подход, которому мы следовали, состоял в следующих этапах: (а) построение относительно подробной модели бизнес-процесса посредством проведения семинаров, (б) проектирование и «изготовление» системы поддержки с использованием модели в качестве спецификации требований и (в) внедрение системы в организационную практику.В гибком подходе этап детального моделирования процессов был пропущен в пользу непосредственной разработки системы и предоставления пользователям возможности протестировать ее на практике. В следующих подразделах мы представляем примеры применения этих двух подходов в нашей практике.
Традиционная разработка бизнес-процессов: пример некоммерческой организации
Самым крупным проектом, в котором наша команда принимала участие Footnote 1 при использовании традиционной схемы, была процессно-ориентированная ориентация регионального офиса некоммерческой организации, называемой Ассоциация арендаторов, регион Западная Швеция (на шведском языке: Hyresgästföreningen, Region Västra Sverige) и сокращенно HGF.Организация объединяет более 60 000 арендаторов, а цель регионального офиса, в котором работает около 60 сотрудников, — защита интересов своих членов. Это делается в ряде областей, таких как предоставление юридических и практических советов своим членам, ведение переговоров об аренде от имени своих членов и лоббирование.
Проект под названием ProBis был начат в 2002 году после успешного внедрения в организационную практику HGF системы под названием ReKo (Andersson et al.2002), который поддерживал рекрутинговую деятельность в организации. Проект ProBis был амбициозным и затронул несколько ключевых процессов HGF, таких как обработка отзывов из местных офисов, поддержка этих офисов и лоббирование. Ожидания были высокими, в основном из-за успеха предшественника ProBis ReKo , который помог организации повысить эффективность набора новых членов.
Разработка процессов и внедрение системы поддержки в организационную практику в проекте ProBis более или менее следовали стандартной практике разработки процессов и систем поддержки.Перед началом разработки системы мы провели ряд проектов по анализу бизнес-процессов в главном офисе Ассоциации арендаторов в Западной Швеции. Проанализированные процессы включали услуги (например, консультации, управление конфликтами), предоставляемые главным офисом своим полевым (низовым) организациям, обработку отзывов (например, жалоб), лоббирование (например, влияние на решения других) и некоторые другие. . Проекты по анализу бизнес-процессов проводились путем проведения семинаров с участниками процесса; По каждому процессу было проведено не менее трех семинаров.Более подробно формат этих проектов описан в Andersson et al. (2002), Perjons et al. (2007).
Помимо отчета, включающего модель бизнес-процесса, в каждом проекте анализа процесса была представлена имитация процесса, выполненная с помощью специально разработанного инструмента ProVis (Process Visualizer). Дамп экрана этого инструмента, относящийся к проекту, представлен на рис. 2. Моделирование проводилось на основе примеров из опыта участников, предоставленных ими.Моделирование преследовало двоякую цель:
Рис. 2Дамп экрана из визуализатора процессов для одного из процессов ProBis
Убедитесь, что модель процесса, созданная в проекте, охватывает реальные примеры из практики участников. Моделирование выполнялось итеративно вместе с моделированием процесса. Как только моделирование показало, что модель не соответствовала примерам, представленным участниками, модель была исправлена.
Дайте будущим пользователям понять, как будет выглядеть система, поддерживающая данный процесс.
Участники процесса были единственным источником информации в аналитических проектах. Поскольку аналитики не были экспертами в деловой деятельности HGF, они не имели большого влияния на определение того, как процессы (или должны) выполняться; они отвечали только за разработку модели процесса в соответствии с полученной информацией.Участники каждого проекта согласились с тем, что разработанная модель правильно отражает деятельность в их бизнесе.
После того, как весь анализ проектов был завершен, мы получили заказ на разработку системы с использованием отчетов по аналитическим проектам и результатов моделирования в качестве системных требований. Система поддержки, также называемая ProBis (Андерссон и др., 2005), была разработана и доставлена по модулю, где каждый модуль отвечал за определенный процесс или группу процессов.Предусматривалась модуляция, чтобы облегчить внедрение. Все модули были построены на одних и тех же принципах и имели общий пользовательский интерфейс. Мы полагали, что к тому времени, когда будет представлен следующий модуль, пользователи уже будут знать, как работать с системой, изучив предыдущий модуль. Однако это намерение так и не было реализовано, поскольку процесс внедрения не был хорошо спланирован. После первоначального обучения конечных пользователей просто попросили использовать систему. Результат такого упрощенного процесса внедрения был отрицательным, т.е.е., на самом деле очень немногие использовали эту систему. Было проведено расследование причин сбоя, в результате которого была подвергнута критике удобство использования системы, т. Е. Конструкция системы была недостаточно интуитивно понятной и удобной для пользователя.
После этого открытия пользовательский интерфейс системы был полностью переработан, и пользователям снова было предложено использовать систему. Результат был и на этот раз отрицательным, т. Е. Очень немногие использовали систему. Однако больше никто не критиковал удобство использования системы.Ситуация была четко объяснена заявлением одного из предполагаемых пользователей: «Я уверен, что система очень хорошая, но я не знаю, для чего мне ее использовать». Поскольку никто не обвинял саму систему, внимание нашей группы было переключено на поиск причин сбоя в другом месте, а именно в качестве процесса внедрения. Наше исследование этого вопроса привело к созданию общей структуры под названием A 3 , поддерживающей внедрение ИТ-систем в организационную практику (Bider et al.2012). Эта структура была принята руководством и частично реализована. ProBis был в конечном итоге представлен в организации. Однако сфера его использования так и не достигла намеченного уровня.
Несмотря на задержки и уровень использования ниже ожидаемого, система ProBis , введенная в эксплуатацию в октябре 2004 года, продолжает работать до момента написания. И это несмотря на то, что мы прекратили поддержку продукта в 2010 году.На 31 мая 2012 года база данных ProBis содержала 1686 завершенных экземпляров процессов и 783 активных (некоторые из последних были завершены, но не заархивированы). База данных также содержала 6148 документов, 393 организации, 1528 контактных лиц и 18 193 событий, зарегистрированных для всех процессов. Сноска 2
ProBis Разработка системы была завершена с помощью самодельного инструмента высокого уровня, который повысил производительность и упростил внесение изменений.Однако этот инструмент был разработан для людей с техническими навыками. Персонал HGF не обладал достаточной компетенцией для использования этого инструмента, поэтому все изменения в процессе и системе были сделаны поставщиком системы.
Традиционная разработка бизнес-процессов: пример из банка
В этом разделе рассказывается о провале проекта BPM в банке, Footnote 3 , в котором использовался традиционный жизненный цикл BPM. Банк передал ИТ-компании на аутсорсинг проект разработки системы поддержки всех процессов в Международном подразделении.Проект включал 17 подпроектов, таких как «Управление аккредитивом», «Управление казначейством», «Управление SWIFT» и др. Каждый из подпроектов касался ряда бизнес-процессов. Проект начался с трех основных рабочих потоков, а именно «Видение бизнеса», «Бизнес-процесс текущего состояния» и «Технологии текущего состояния».
Business Vision было направлено на: (1) документирование бизнес-видения и стратегии подразделения; (2) понимание потребностей бизнеса. Текущий государственный бизнес-процесс был нацелен на: (1) документирование на высоком уровне существующих банковских процессов; (2) обнаружение новых потенциальных процессов и уточнение существующих. Current State Technology был нацелен на: (1) сбор информации, понимание и документирование существующей технологической архитектуры; (2) обзор всех соответствующих направлений деятельности и функциональных областей с точки зрения современных технологий; (3) определение возможностей, сильных и слабых сторон, рисков и ограничений; (4) оценка качества существующих приложений, технологий и связанных операций, а также процессов и методологий разработки систем.
После завершения описанных выше рабочих потоков были определены три других рабочих потока, а именно: «Пробелы в документах», «Будущие технологии» и «Приоритезация и разработка вариантов». После их завершения руководитель проекта выбрал бизнес-процессы для дальнейшего развития в соответствии с таблицей приоритетов и наличием ресурсов.
Разработка процесса проводилась циклами, которые включали: (1) изучение текущих документов и проведение первичных собеседований; (2) разработка моделей процессов; (3) анализ; (4) реализация; (5) конфигурация; (6) пилотное исполнение; (7) диагностика результатов.Когда разработка системы была завершена, команда разработчиков опубликовала результаты подпроекта для использования клиентами.
Циклы разработки процессов, хотя формально были хорошо организованы, оказались проблематичными. В начале разработки процесса и заинтересованные стороны, и ИТ-персонал согласовали, как должен выглядеть каждый процесс, а также какие требования и цели он должен охватывать. ИТ-персонал также имел доступ ко всем документам, полученным на предыдущих этапах цикла.Дизайн, анализ и внедрение проводились ИТ-отделом без взаимодействия с заинтересованными сторонами. Проблема возникла во время выполнения пилотного проекта. Заинтересованные стороны обвинили ИТ-персонал в непонимании требований и отвергли внедрение процесса. Для каждой модели процесса было много итераций, и бюджет проекта был превышен. В конце концов, руководство банка решило прекратить проект, поскольку невозможно было оценить, сколько времени потребуется для его успешного завершения.
Гибкая разработка процессов: пример муниципалитета
Наш опыт разработки гибких процессов начался с проекта внедрения так называемого процесса BBiC в социальном офисе муниципалитета Йёнчёпинг (Швеция). Сноска 4 BBiC означает «Потребности ребенка в центре» («Barnens Behov i Centrum» на шведском языке) и занимается расследованием, принятием решений и последующими решениями в случаях предполагаемого жестокого обращения с детьми или семей, которые не могут позаботиться о своих нуждах. дети. Руководящие принципы для этого процесса были составлены Национальным советом здравоохранения и социального обеспечения, и шведским муниципалитетам им настоятельно рекомендовалось следовать. Поскольку процесс уже был определен, проект касался только его организационной реализации, которая включала разработку системы для его поддержки.
Получив приглашение участвовать в проекте в качестве поставщика системы, мы решили не начинать с разработки системы для поддержки процесса BBiC , а разработать инструмент, который позволил бы относительно быстро настроить такую систему, а также любая другая подобная система. Одним из основных требований к инструменту было то, что человек со знаниями в предметной области и минимум технических знаний мог использовать его для настройки поддержки нового бизнес-процесса.Разработка началась в 2007 году и привела к созданию инструмента под названием iPB (Bider et al. 2010), который сейчас находится в версии 6.0. Footnote 5 В этом проекте процесс BBiC служил и продолжает служить пилотным для разработки инструмента. Процесс BBiC претерпел несколько серьезных изменений после первого введения, в которых сложность карты процесса постепенно увеличивалась. В настоящее время в процессе BBiC насчитывается около 266 активных участников, в том числе 80% активных пользователей, которые работают с системой BPS ежедневно, и 20% случайных пользователей, которые работают с ней редко и выполняют лишь несколько операций.
Наша роль в этом проекте была более технической по сравнению с проектом ProBis , где мы провели полный анализ бизнес-процессов HGF. В этом проекте мы предоставили только инструмент, который помог собственным сотрудникам заказчика создать систему для поддержки процесса BBiC . Это было сделано одним человеком, который продолжает разработку системы BBiC при постоянной поддержке второго уровня с нашей стороны. Этот человек является профессионалом в своей области, который приобрел некоторые технические знания, чтобы стать посредником между техническими специалистами и деловыми людьми.
Помимо завершения проекта BBiC без серьезных проблем, муниципалитет Йёнчёпинга получил в свое распоряжение инструмент, который позволил им реструктурировать около десятка других процессов. Это было и делается системным администратором, работающим следующим образом. Обнаружив необходимость внедрения структурированного процесса, поддерживаемого IT-системой, он:
- 1.
Обсуждает потребности с персоналом.
- 2.
Рисует систему непосредственно в iPB , избегая формального моделирования.
- 3.
Представляет систему группе будущих пользователей и собирает их комментарии.
- 4.
Вносит изменения и снова показывает черновик (шаги 3, 4 можно повторять несколько раз).
- 5.
Включает систему в работу (после ее принятия).
- 6.
Постоянно вносит изменения в зависимости от фактического использования системы, не организуя никаких обширных проектов по реинжинирингу процессов.Некоторые из этих изменений связаны с изменениями в процессе, другие — с новыми возможностями, представленными в следующей версии iPB .
Моделирование бизнес-процессов | Определение, зачем, методика и преимущества
Моделирование бизнес-процессов не является радикальной концепцией — оно существует уже давно. Однако изменения, которые он может вызвать в производительности и эффективности бизнеса, являются не чем иным, как революционными.
Но что это такое и зачем оно вам?
Что такое моделирование бизнес-процессов (BPM)?
Моделирование бизнес-процессов (или) моделирование процессов — это аналитическое представление или просто иллюстрация бизнес-процессов организации. Моделирование процессов — важнейший компонент эффективного управления бизнес-процессами.
Программное обеспечение для моделирования процессов дает аналитическое представление о процессах «как есть» в организации и противопоставляет его процессам «как есть», чтобы сделать их более эффективными.
Многие инструменты моделирования бизнес-процессов выдают что-то вроде этого:
Зачем использовать моделирование бизнес-процессов?
Ваш первый шаг в моделировании — это ручка и бумага. Однако для того, чтобы действительно запустить бизнес-процесс, вам необходимо оцифровать этот процесс таким образом, чтобы его мог понять механизм рабочего процесса.
Программное обеспечение для моделирования бизнес-процессов позволяет представить ваш процесс в цифровом виде, который затем может быть перенесен в текущий автоматизированный процесс.
Моделирование бизнес-процессов дает множество преимуществ:
- Дает всем четкое представление о том, как работает процесс
- Обеспечивает согласованность и контролирует процесс
- Выявляет и устраняет дублирование и неэффективность
- Устанавливает четкое начало и конец процесса
Моделирование бизнес-процессов также может помочь вам сгруппировать похожие процессы и предвидеть, как они должны работать.Основная цель инструментов моделирования бизнес-процессов — проанализировать, как обстоят дела сейчас, и смоделировать, как их следует выполнять для достижения лучших результатов.
Kissflow, наше программное обеспечение для управления бизнес-процессами, оптимизируйте ваш бизнес с помощью сверхмощных процессов.Методы моделирования бизнес-процессов
Моделирование бизнес-процессов может быть выражено посредством блок-схем, программ, гипертекста или сценариев. Не существует единственного способа реализовать моделирование бизнес-процессов; Фактически, вы можете выбирать из 12 техник.
Вот некоторые из наиболее распространенных методов моделирования бизнес-процессов:
Нотация моделирования бизнес-процессов (BPMN)
BPMN 2.0 стала чем-то вроде стандартного синтаксиса, используемого аналитиками процессов и теми, кто создает инструменты бизнес-моделирования. Это относительно простое использование линий, стрелок и геометрических фигур, которые передают ход и нюансы процесса. Консультант по процессам может взглянуть на модель BPMN 2.0 и точно знать, как она должна функционировать.
«В конце концов, когда [эти] компании начнут поставки своих продуктов и запустят свои маркетинговые машины, BPMN станет неоспоримым стандартом для моделирования и выполнения процессов.Но сейчас мы все еще находимся между новостями и реальностью ». — Брюс Сильвер, консультант по процессам и автор книги «Метод и стиль BPMN
».Однако BPMN 2.0 все еще изучаемый язык, и хотя он относительно прост, он не сразу становится интуитивно понятным для обычного бизнес-пользователя. Это отличный инструмент для консультантов по процессам, но он не поможет тем, кто хочет создавать свои собственные приложения.
Универсальная нотация процесса
Вместо того, чтобы изучать новый язык, более интуитивно понятная система — это универсальная нотация процессов или UPN.
UPN предоставляет простой блок для каждой задачи, которую необходимо выполнить. Поле показывает, что происходит, кто назначен для этого и когда это происходит в последовательности. Для ИТ-отдела чрезвычайно полезно разрабатывать и анализировать процессы, чтобы руководство соответствовало бизнес-нормам, и, что еще более важно, для конечных бизнес-пользователей понимать процессы, как задумано. Kissflow использует UPN в своем моделере.
Блок-схема метода
Блок-схемыобъясняют сложные потоки процессов простым, но эффективным способом.Они иллюстрируют этапы процесса в их последовательном порядке, от входов к фактическому процессу и к выходам. Фактически, блок-схемы обеспечивают базовую структуру для BPMN для отображения расширенных потоков процессов.
Диаграммы Ганта
Вместо того, чтобы показывать шаги последовательно, диаграммы Ганта могут отображать весь процесс, используя «затраченное время» в качестве одной из главных осей. Он лучше показывает общее время, затраченное на выполнение проекта, чем другие варианты.
Сети Петри
Сети Петри, традиционно являющиеся методом моделирования в математике, также используются для моделирования бизнес-процессов.Сети Петри классифицируют или выделяют цветом сложные этапы рабочего процесса, пользователей и маршруты разными цветами.
Что мне нужно в программном обеспечении для моделирования процессов?
Большинство пакетов BPM включают в себя инструменты моделирования бизнес-процессов. Однако в некоторых моделлер представлен в виде отдельного приложения.
Разработчик моделей — один из самых важных элементов в BPMS, и вам следует потратить много времени на его изучение, прежде чем покупать пакет.
Отличные инструменты бизнес-моделирования должны:
- Легкость обучения для бизнес-отделов
- Упростите взаимодействие ИТ-специалистов с другими отделами
- Быть недорогим и соответствовать отраслевым требованиям
- Имеют встроенный редактор рабочего процесса с графическим интерфейсом
- Уметь смоделировать рабочий процесс перед внедрением.
Узнайте больше о средствах моделирования процессов.
? Узнайте, почему это программное обеспечение 6 BPM является лучшим среди конкурентов!Заключение
Возможности моделирования процессов неоспоримы для предприятий любого размера и отраслевой вертикали. Воспользуйтесь возможностями моделирования повседневных процессов в своей компании уже сегодня и подпишитесь на бесплатную пробную версию.
Тебе также может понравиться,
Как разработать бизнес-процесс
Хотя разработка процесса может показаться простой задачей, существует ряд ловушек, которые ждут, чтобы вас поймать.Эта статья предлагает несколько советов.
Модель не процесс
Разработка бизнес-процесса означает, что люди выполняют свою фактическую работу в соответствии с этим процессом. Влияние на то, как люди выполняют свою работу, — сложная проблема, которая требует высоких зарплат и называется менеджментом.
С другой стороны, разработка модели бизнес-процесса настолько проста, что вы рискуете потратить на нее слишком много времени и разработать модель процесса, которую вы не сможете преобразовать в рабочий процесс.
Следовательно, первый шаг — сосредоточиться на конечной цели. Это не диаграмма.
Старт простой
Теперь, моделируете ли вы с нуля или смотрите, как люди на самом деле выполняют свою работу, начните с простейшей возможной версии процесса, которую вы имеете в виду. Это не более чем заявление о конечной цели, например, отгрузка продукта покупателю.
Затем, прежде чем вы продолжите добавлять детали к модели, вовлеките всех.
Вовлекать всех
Модель технологического процесса в башне из слоновой кости нравится некоторым, но рискует не выдержать контакта с реальностью.Вместо этого используйте тривиальную модель, с которой вы начали, чтобы вовлечь людей в разговор о том, как на самом деле работает эта работа. Люди, которые больше всего знают о работе, — это (в совокупности) люди, которые ее делают.
«Все» не обязательно означает всех, но вы не узнаете, кто участвует в бизнес-процессе, пока модель не станет более подробной. В любом случае, это определенно включает больше организационных ролей, чем аналитик процессов.
На практике, однако, есть разница между тем, что люди говорят, что они делают, и тем, что они делают на самом деле.
Получите обратную связь от реальной работы
Хороший способ привлечь людей, выполняющих работу, к разработке модели процесса — это использовать инструмент управления рабочим процессом или управления делами для обеспечения программной поддержки выполнения процесса.
Когда в исходной модели процесса есть только один шаг, представляющий весь процесс, поддержка инструментов позволяет отслеживать все дела по мере их запуска и завершения. Следующим шагом будет добавление задач и интеграций внутри этих кейсов.
Итерировать модель вместе с реальной работой
Только теперь, когда у вас есть (тривиальная) модель процесса, которую вы действительно можете использовать на практике, и участие людей, разбирающихся в работе, вы можете безопасно добавлять детали в модель.
Поскольку управлять людьми, иначе говоря, «пасти кошек», и любые изменения сложнее, чем моделировать, вы можете получить больше пользы от внесения изменений в фактическую работу перед обновлением модели, чтобы отразить эти изменения, а не наоборот.
Самое главное, что каждый раз, когда вы работаете над делом (т. Е. Выполняете процесс), вы потенциально обновляете модель в результате либо для добавления полезных деталей, либо для автоматизации, либо для улучшения модели процесса.
Выбирайте гибкие инструменты
Вы не можете достичь вышеуказанного с помощью программных инструментов, основанных на создании схемы модели и реализации модели с помощью разработки специального программного обеспечения, изменение которого требует больших затрат времени и средств. Вместо этого вам понадобится программное обеспечение, которое:
- позволяет быстро начать работу без дополнительной настройки
- прост в использовании, поэтому вам не нужно тренироваться перед тем, как начать работу с .
- позволяет выполнять итерацию между проектированием и выполнением модели процесса
- позволяет вам работать с несколькими людьми в вашей организации.
Signavio Workflow — это результат этой долгой истории: упрощенное моделирование и выполнение рабочего процесса, которые можно использовать для разработки не только модели процесса, но и реального работающего бизнес-процесса.
(PDF) Гибкая разработка бизнес-процессов: почему, как и когда
Гибкая разработка процессов 31
Ссылки
Адамс, MJ, Тер Хофстеде, AH, Эдмонд, Д. и ван дер Аалст, WM, 2005. Обеспечение гибкости и динамическая
обработка исключений в рабочих процессах через рабочие листы.В CAiSE’05.
Андерссон Т., Андерссон-Седер А. и Бидер И., 2002. Поток состояний как способ анализа бизнес-процессов — пример
исследований. Управление логистической информацией, 15 (1), стр. 34-45.
Андерссон, Т., Бидер, И. и Свенссон, Р., 2005. Отчет об опыте согласования людей с бизнес-процессами. Программное обеспечение
Процесс: Улучшение и практика, 10 (4), стр. 403-13.
Беккер, Дж., Кугелер, М. и Роземанн, М., ред., 2011. Управление процессами: руководство по проектированию бизнеса
Процессы.2-е изд. Springer.
Бидер, И., 2014. Анализ гибкой разработки программного обеспечения с точки зрения трансформации знаний. В
Johansson, B., ed. Принять участие в 13-й Международной конференции по перспективам исследований в области бизнес-информатики
(BIR 2014). Лунд, Швеция. Спрингер, LNBIP.
Бидер, И., Беллинджер, Г. и Перджонс, Э., 2011. Моделирование гибкого предприятия: согласование систем и процессов
Мышление. В практике моделирования предприятий, LNBIP, Vol.92. Springer, стр. 238–52.
Бидер, И., Йоханнессон, П. и Перджонс, Э., 2010. В поисках Святого Грааля: интеграция социального программного обеспечения с BPM.
Отчет об опыте работы. В области моделирования предприятий, бизнес-процессов и информационных систем, LNBIP, Vol. 50. Springer,
pp.1-13.
Бидер, И., Йоханнессон, П., Перджонс, Э. и Йоханссон, Л., 2012. Наука о дизайне в действии: разработка концепции
для внедрения ИТ-систем в операционную практику.В материалах Международной конференции по информационным системам
, ICIS. Орландо, Флорида, США.
Бидер И. и Страй А., 2008. Управление гибкостью экземпляра бизнес-процесса с помощью правил планирования. IJBPIM, 3 (1),
pp.15-25.
Box, G.E.P. & Дрейпер, Н. Р., 1987. Построение эмпирической модели и поверхности отклика. Нью-Йорк, штат Нью-Йорк: Джон Вили
и сыновья.
Бруно, Г. и др., 2011. Ключевые проблемы, связанные с внедрением гибкого BPM с социальным программным обеспечением.Журнал программного обеспечения
Обслуживание и развитие: исследования и практика, 23 (4), стр. 297-326.
Конант Р. и Эшби Р., 1970. Каждый хороший регулятор системы должен быть моделью этой системы. Int. J. Systems Sci.,
1 (2), стр 89-97.
Конбой, К. и Фицджеральд, Б., 2004a. К концептуальной основе гибких методов: изучение гибкости в различных дисциплинах
. В материалах семинара ACM 2004 г. по междисциплинарным исследованиям в области программной инженерии.
Ньюпорт-Бич. ACM, стр.37-44.
Конбой, К. и Фицджеральд, Б., 2004b. К концептуальной основе гибких методов. В экстремальном программировании
и Agile Methods-XP-Agile Universe 2004. Springer, pp.105-16.
Фаулер М. и Хайсмит Дж., 2001. Манифест Agile. Разработка программного обеспечения, 9 (8), стр.28-35.
Гонг, Ю. и Янссен, М., 2011. От реализации политики к управлению бизнес-процессами: принципы создания
гибкости и маневренности.Government Information Quarterly, 29, pp.S61–71.
Gram Consulting, 2009. «Ba» за развитие менеджмента. [Онлайн] Доступно по адресу:
http://gramconsulting.com/2009/04/ba-for-management-development/ [Доступно 17 августа 2013 г.].
Хайсмит, Дж., Орр, К. и Кокберн, А., 2000. Доставка приложений электронного бизнеса, стр. 4-17. [Онлайн] Доступно по адресу:
www.cutter.com/freestuff/ead0002.pdf.
Почему вашей компании необходимо разработать план управления бизнес-процессами — необычная лига
Каковы преимущества BPM?
Помимо большей ясности в операциях вашего бизнеса, использование BPM дает значительные дополнительные преимущества.Эти преимущества будут различаться в зависимости от вашей отрасли и того, как вы используете управление процессами, но многие из них будут частично совпадать в командах и отделах.
Устранение обходного пути
Вы можете не осознавать это сначала, но большинство процессов внутри компаний удерживаются вместе с метафорическими «клейкой лентой и жевательной резинкой», которые сотрудники используют для быстрого решения проблем для выполнения своих задач.
«В идеале управление бизнес-процессами устраняет 90% или более обходных путей, которые ваши сотрудники используют для выполнения задач», — поясняет команда Panorama Consulting Solutions.«Сотрудники используют обходные пути, когда процессы плохо определены. Иногда текущая технология в любом случае не может поддерживать эффективные процессы ».
Как только вы начнете понимать, почему что-то делается определенным образом, вы действительно сможете увидеть необходимость улучшения процесса.
Снижение риска
Команда поставщика программного обеспечения для интрасети Claromentis подчеркивает, как BPM снижает риски. Это позволяет компаниям следить за соблюдением государственных нормативных требований и следить за их соблюдением в своих процессах.
Здесь также могут помочь обходные пути. Действующий из лучших побуждений сотрудник может найти обходной путь для достижения своих целей, но в итоге компания не сможет выполнить нормативные требования. Команда управления изменениями может проанализировать эти процессы и при необходимости внести исправления.
Оптимизация ресурсов
Несколько лет назад большинству компаний приходилось сокращать отходы, чтобы сэкономить деньги и ресурсы. Однако, поскольку все больше компаний работают с ограниченными бюджетами, сокращение — не вариант.
«Просто нечего вырезать», — говорит деловой писатель Камилла Никсон. «Однако для того, чтобы процветать, организациям по-прежнему необходимо максимально повысить эффективность понесенных ими затрат и получаемой прибыли».
Развитие и внедрение культуры постоянного совершенствования позволяет компаниям делать больше с меньшими затратами, не чувствуя, что единственный способ сдвинуть с мертвой точки — резкие сокращения.
Повышение морального духа сотрудников
Хотя ваша команда может поначалу сопротивляться изменениям, большинство сотрудников приветствуют более эффективные процессы и более ясные способы ведения дел.«Оптимизируя определенные процессы и рабочие процессы в организации, вы можете быть удивлены, обнаружив, насколько это может улучшить удовлетворенность сотрудников, поскольку это может привести к изменению их ролей и обязанностей», — пишут сотрудники AppWright.
Они объясняют, что более эффективное управление процессами — не лучшее решение для счастливых сотрудников, но оно может создать пространство для сотрудников, чтобы выделить те части своей работы, которыми они недовольны и которые можно улучшить. Кроме того, создание более эффективно функционирующей компании создает меньше трений внутри команд.
Это лишь некоторые преимущества плана BPM. Кроме того, управление процессами можно применить практически к любому отделу или команде.
Деловой писатель Джейми Джонсон приводит несколько примеров того, как BPM может изменить различные отделы за пределами мира ИТ. Один из них — это область человеческих ресурсов, в которой есть множество документов и процессов, в которых задействовано несколько сотрудников. Сотрудник должен отправить форму отпуска, менеджер должен ее утвердить, а отдел кадров должен ее зарегистрировать. Если компаниям удастся сократить количество этих шагов или найти способы их упростить, тогда сотрудники будут меньше раздражаться существующими процессами, и менеджеры по персоналу смогут сосредоточиться на более важной работе, чем рассмотрение отпуска.
Полное руководство по управлению бизнес-процессами — Smartsheet
Интегрированные комплекты BPM разработаны для использования концепций BPM. Компании могут осуществлять непрерывное улучшение бизнес-процессов с помощью инструментов BPM, механизмов бизнес-правил, механизмов рабочих процессов, инструментов моделирования и тестирования, комплексной обработки событий и мониторинга деловой активности.
«Мы можем сотрудничать по четко определенным задачам, устанавливать сроки для работы и эффективно общаться, не находясь в одном месте.Интеграция таких сервисов, как Google Apps и Dropbox, значительно упрощает нам задачу. Сотрудничество — ключ к успеху каждой команды, и BPM-пакеты, такие как Smartsheet или Promapp, могут облегчить эту часть вашей жизни ».
Доступное программное обеспечение является успешным только из-за репозиториев, в которых хранятся метаданные и разрешены запросы данных. Эти репозитории используют общую метамодель хранилища (CWM) в качестве архитектуры со спецификациями, также установленными Группой управления объектами. CWM основан на UML, MOF и XMI, которые, соответственно, относятся к моделированию, метамоделированию и хранению метаданных, а также обмену данными.
Некоторые из разрозненных программных полей, которые объединились для создания BPMS, включают следующее:
Механизм бизнес-правил : Механизм бизнес-правил (BRE) позволяет пользователям BPMS изменять свою бизнес-логику, в том числе для обновлений или новых политик или процедур.
По словам Джеффа Тиндалла из Tindall Media, LLC, «Хотя многие бизнес-процессы можно автоматизировать за счет сбора требований, некоторые из них являются открытыми и требуют гибких правил, которые можно настраивать во время выполнения в зависимости от потребностей клиента и текущих данных.Вот где бесценны механизмы правил. Большинство механизмов правил бывают двух видов: оценка или выполнение. Правила оценки отвечают на вопрос «да» или «нет». Они отлично подходят для поддержки сложных или меняющихся условий, таких как выполнение задачи. С другой стороны, правила выполнения позволяют выполнять одно или несколько действий в рамках правила. Они отлично подходят для определения рабочего процесса, например, какую задачу выполнять дальше ».
Модель и нотация бизнес-процесса (BPMN) : BPMN становится частью приложения BPMS и управляет работой бизнес-процесса при его запуске.
Мониторинг деловой активности (BAM) : Используя BAM, компании могут отслеживать свои бизнес-процессы и видеть, где могут быть сбои и проблемы. Отчеты BAM точно показывают, как (и насколько хорошо) работают бизнес-процессы и потоки. BAM фокусируется на четырех атрибутах: объемах транзакций, скорости, ошибках и особых условиях.
Человеческий рабочий процесс : Это программное обеспечение систематизирует задачи, которые должны выполняться людьми. Для этого необходимо назначить задачу конкретному человеку, определить другие заинтересованные стороны и отметить, когда задача должна быть завершена, а также то, как задача должна быть выполнена.Оптимизация процессов, связанных с людьми и динамическими изменениями, исторически была сложной задачей, но это программное обеспечение выросло как часть BPMS.
На что обращать внимание в пакетах BPM
При поиске пакета BPM главное, что нужно искать — это лидерство в отрасли. Ваш пакет BPM должен быть хорошо зарекомендовавшей себя программой, которая постоянно обновляется, чтобы добиться успеха в отрасли, а не просто конкурировать. Ниже приведен список возможностей и функций, которые могут быть найдены в пакете BPM:
Разрешить корпоративное сотрудничество-обмен сообщениями
Разрешить видимость событий
Правила автоматизации
Строительные услуги
Захват ключевых показателей эффективности (KPI)
Объединение информации на предприятии
Создать аналитику
Создание форм
Дизайн приборной панели
Разработка мобильного приложения
Среда конечного пользователя
Интегрировать контент
Локальное решение
Вариант программного обеспечения как услуги (SaaS)
Обнаружение процессов и оценка проекта
Моделирование процессов
Возможности быстрого развертывания
Интеллектуальные пакеты управления бизнес-процессами (iBPMS)
Рекомендации по выбору пакетов BPM
Доступно непропорционально большое количество вариантов BPMS, и выбор системы должен основываться на передовом опыте.Компании должны заручиться поддержкой пользователей перед покупкой; Чтобы добиться заинтересованности сотрудников, привлекайте к анализу продукта представителей отделов всего бизнеса. Другие передовые методы включают обеспечение участия всей компании в процессе внедрения и обеспечение надлежащего обучения.
Обученные и сертифицированные поставщики внушают доверие своим продуктам. Кроме того, участие сотрудников сокращает теневые ИТ — бизнес-процессы, которые явно не являются частью процесса компании и не упорядочены в комплексном программном пакете.По прогнозам Gartner, «20% теневых бизнес-процессов будут поддерживаться облачными платформами BPM». Теневые процессы существуют в подвешенном состоянии, часто скрытые от ИТ и поддерживаемые любым подключаемым модулем или электронной таблицей, к которым имеет доступ обычный персонал. BPM может избавить вашу компанию от значительной части теневой обработки.
Все специалисты рекомендуют опробовать систему перед покупкой. Успех BPMS зависит от анализа и тестирования функций, необходимых вашему бизнесу. Некоторые эксперты даже рекомендуют нанять консультанта, чтобы оценить потребности вашего бизнеса и поговорить с поставщиками, чтобы определить наиболее подходящего.При рассмотрении вашего бизнес-варианта использования, также известного как проблема, которую вы пытаетесь решить, вы должны помнить, как он будет работать с вашей корпоративной служебной шиной (ESB). По мнению экспертов, вам следует изучить следующее:
Только BPMS : Ваш бизнес в основном состоит из человеческого взаимодействия и лишь небольшого количества транзакций и требований к производительности.
Только для ESB : Ваш бизнес в первую очередь включает транзакции, требующие масштабируемости и гибкости по мере вашего роста и развития.
BPMS и ESB вместе : Вашему бизнесу требуется большое количество человеческих взаимодействий и транзакций, которые могут нуждаться в масштабируемости и гибкости для роста.
По словам Джима Синура, «Как все мы знаем, BPM во всех его вариациях направлен на улучшение операций, лучшее взаимодействие и оптимизацию ресурсов. Для этого BPM должен иметь возможность хорошо отслеживать ход работы, поэтому он должен иметь множество панелей мониторинга, аналитику процессов (бизнес-аналитику для процессов) и возможности прогнозирования для следующего наилучшего действия.Он также должен иметь гибкую, визуальную и быструю среду разработки и композиции. Кроме того, ему придется обратиться к большим данным и другим системам, чтобы справиться с гибридным и составным поведением.
Синур продолжает: «В идеале BPM должен иметь возможности оптимизации ресурсов, которые могут распознавать сигналы, события и шаблоны; помогают принимать решения в полете; и принять новый курс действий через людей, системы или машины. Существует множество технологических функций, которые делают это возможным, но моделирование, имитация, когнитивная деятельность, разработка, аналитика, интеграция, большие данные, Интернет вещей, боты, агенты и технологии визуализации — все это скрыто в различных комбинациях.”
Что такое управление бизнес-процессами?
Управление бизнес-процессами (BPM) — это практика моделирования, анализа и оптимизации сквозных бизнес-процессов для достижения ваших стратегических бизнес-целей, таких как улучшение структуры обслуживания клиентов. Методология BPM может применяться к часто повторяющимся, текущим или предсказуемым задачам и процессам.
Бизнес-процесс — это набор действий, которые помогают бизнесу достичь определенной цели. Используя BPM, вы можете оценивать свои бизнес-процессы, чтобы найти способы повышения эффективности, а также снижения затрат и ошибок.
BPM — это непрерывный процесс, который со временем приводит к улучшениям. С помощью BPM вы можете исключить специальные методы управления рабочими процессами и оптимизировать бизнес-операции, чтобы предоставлять лучшие продукты и услуги своим клиентам.
Методология BPM
- Спроектируйте и проанализируйте: В качестве первого шага вам необходимо проанализировать процесс в том виде, в каком он существует в настоящее время. Подумайте, что работает или где существуют проблемы, а также как это связано с другими задачами или процессами.
- Модель: Ищите способы улучшить процесс и спроектируйте, как это должно происходить в идеале. Затем смоделируйте, как этот процесс будет работать, с множеством потенциальных сценариев и переменных.
- Выполнить: После того, как процесс смоделирован, вы можете вносить изменения. Обязательно задокументируйте, что изменилось и почему.
- Монитор: После того, как ваш новый процесс будет внедрен, вам нужно будет отслеживать его, чтобы увидеть, есть ли улучшения. Ищите данные, подтверждающие, есть ли прогресс.Вы видите повышение эффективности? Снизились ли расходы? Продукты доставляются быстрее?
- Оптимизация и автоматизация: После того, как вы применили методологию BPM к процессу, вам нужно будет продолжать отслеживать и оптимизировать его с течением времени. BPM — это непрерывный процесс, и вы должны регулярно искать способы его улучшения. Если новый процесс работает хорошо, подумайте, можно ли автоматизировать какие-либо задачи.
BPM и автоматизация
BPM — это не технология, это практика, выполняемая людьми.Тем не менее, программное обеспечение BPM и технологии автоматизации можно использовать для реализации выявленных улучшений процессов. BPM — это первый шаг к повсеместной автоматизации бизнес-процессов.
Автоматизация помогает сделать ваш бизнес более эффективным за счет использования программного обеспечения для выполнения задач, чтобы снизить затраты, сложность и количество ошибок. В то время как BPM — это методология, которая позволяет вам лучше понимать ваши сквозные бизнес-процессы, автоматизацию бизнес-процессов можно использовать для постоянной проверки и повышения эффективности ваших процессов в сравнении с этими инициативами.
Зачем автоматизировать свой бизнес с помощью Red Hat
Центр ИТ сместился с удовлетворения внутренних потребностей, таких как эффективность и контроль затрат, на взаимодействие с внешними клиентами и создание новых возможностей для бизнеса.
Добавить комментарий
Комментарий добавить легко