Во многих отраслях работа предприятий организована по проектному принципу. Напомним, что согласно стандарту ISO 21500, проект — это уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели.
Для оптимального управления проектами разработаны методики и программные инструменты. Пример бизнес-процесса управления проектом для конкретного предприятия представлен в этом разделе.
Если вы не хотите использовать для организации управления хирургию реинжиниринга, а предпочитаете терапию оптимизации существующих бизнес-процессов, их нужно описать, а затем оптимизировать. В результате у вас получится
Бизнес-процесс управления проектом (верхний уровень)
На основе оптимизированного бизнес-процесса нужно разработать шаблон проекта для выбранного программного инструмента:
Шаблон проекта в MS Project
Если на вашем предприятии одновременно выполняются несколько проектов и нужно запланировать распределение ресурсов между ними, вам придётся использовать серверную версию ПО или создать консолидирующий проект:
Как выглядят регламенты и бизнес-процессы
Пример консолидирующего проекта
Не забудьте про инструкции пользователей, участвующих в создании, коррекции и контроле исполнения проекта:
Инструкция по работе с MS Project
На нашем сайте можно ознакомиться с другими примерами разработанных нами описаний бизнес-процессов, а также с процедурой заказа и выполнения этой услуги. О том, как сэкономить при заказе этой услуги мы рассказываем в видео «Стоимость описания бизнес-процессов» на нашем канале Youtube.
Если вы хотите узнать о возможностях такой экономии для вашей компании, заполните этот вопросник для подготовки коммерческого предложения на оптимизацию бизнес-процессов, и мы пришлём вам КП с ценой и планом выполнения этой работы.
Как заказать наши услуги
УЗНАТЬ ПОДРОБНЕЕ
- Наши услуги
- Сколько стоит консалтинг?
- Примеры работ
- Отзывы клиентов
- Подписка на рассылку
В соответствии со ст. 1274 ГК РФ при публикации материала сайта в Интернете, указание авторства и индексируемая ссылка на источник публикации обязательны.
197183, Санкт-Петербург, Представительство в Москве
+7 (962) 684-45-80 +7 (812) 430-19-53 +7 (921) 962-08-63 —>
Источник: piter-consult.ru
Анализ и моделирование проектных бизнес-процессов
Бизнес-процесс – это совокупность действий, работ и мероприятий, с помощью которых создается готовый продукт или услуга, востребованная потребителями.
Предприятие создает готовый продукт или услугу, чтобы их реализовать и получить выручку. Затем оно выплачивает налоги в пользу государства, а оставшуюся часть денег расходует по собственному усмотрению. Бизнес-процесс обеспечивает соединение отдельных элементов производства. Руководство налаживает их таким образом, чтобы иметь возможность получать выгоду.
Бизнес-процессы представляют собой важные ресурсы предприятия. Они требуют управления, как и любая другая структура предприятия. Выделяют следующие виды бизнес-процессов:
Китайский с нуля для начинающих
Увлекаем Китаем, китайским языком и культурой
- Управляющие.
- Операционные.
- Поддерживающие.
Управляющие бизнес-процессы поддерживают функционирование системы предприятия. Они связаны с корпоративным управлением и стратегическим менеджментом. Операционные бизнес-процессы описывают основную деятельность организации. Именно они создают поступление средств на счета компании.
Поддерживающие бизнес-процессы обеспечивают нормальное функционирование основных производственных процессов. Сюда относят управление кадрами, бухгалтерии и обеспечение технической поддержки.
Любой бизнес-процесс направлен на обеспечение потребителя именно тем товаром, в котором он нуждается. Обычно он декомпозируется на несколько подпроцессов с целью повышения управляемости и прозрачности. Бизнес-процессы строятся таким образом, чтобы создавать ценность для покупателя. То есть недостаточно обеспечить эффективный маркетинг и сбыт, важно, чтобы на каждом этапе производственной цепи учитывались основные потребности и ожидания потенциального покупателя. Кроме того, важно обеспечить эффективность, то есть высокие показатели рентабельности и конкурентоспособности.
«Анализ и моделирование проектных бизнес-процессов»
Готовые курсовые работы и рефераты
Решение учебных вопросов в 2 клика
Помощь в написании учебной работы
Моделирование бизнес-процессов
Управление бизнес-процессов позволяет решить поставленные стратегические и тактические задачи. Чтобы оптимизировать процессы и обеспечить нормальную работу предприятия, необходимо моделировать бизнес-процессы для лучшего их понимания и реализации. Моделирование по сути является управлением. Это деятельность, которая дает возможность анализировать бизнес-процессы, а значит, улучшать их и автоматизировать.
Одной из целей бизнеса является обеспечение долгосрочной конкурентоспособности. В современных условиях это достигается за счет увеличения скорости процесса или за счет сокращения цикла производства. Если цель достигается, то повышается качество продукции, снижаются затраты на ресурсы.
Моделирование бизнес-процессов осуществляется с помощью инструментов, которые используют участники управления. Эти инструменты направлены на обеспечение прозрачности процессов, они способствуют централизации корпоративных моделей. Не стоит путать инструменты с системами автоматизации бизнес-процессов. Последние тоже моделируют процесс, но имеют практическое применение. Они позволяют снизить затраты труда.
Так же возможно использование имитационного моделирования по принципу формирования модели «что, если». В этом случае для анализа берутся фактические показатели, которые появляются по мере выполнения процесса. Моделирование может опираться на нотации, жизненный цикл, предметно-ориентированное управление, цепочку процессов для управления событиями и так далее.
Наиболее часто в современной практике для моделирования применяется специальное программное обеспечение. Также с помощью современных информационных технологий возможно создание архитектуры процессов и архитектуры, которая ориентирована на обслуживание.
Анализ проектных бизнес-процессов
Анализ бизнес-процессов представляет собой систематическое получение данных для того, чтобы с их помощью идентифицировать каждый процесс и улучшить его для реализации целей предприятия. Проведение анализа является необходимым для усиления конкурентного положения предприятия на рынке. Фактическая ситуация описывается следующими параметрами:
- Длительность поставки.
- Прозрачность или непрозрачность процесса.
- Глубина процесса.
- Чрезмерно широкий ассортимент.
- Внутрифирменные затраты.
- Неиспользованные мощности.
- Низкая доля времени обработки в общем времени прохождения заказа и другое.
Вышеперечисленные параметры относятся к ключевым процессам предприятия. Но исследование для того и проводится, чтобы выявлять на первый взгляд незначительные изменения, которые могут повлечь за собой разрушительные последствия. Описание структуры процесса является необходимым процессом для его улучшения.
Анализ на основе полученных данных помогает реализовать количественные, качественные, временные, экологические и экономические требования. Информационными источниками выступают производственная документация, аудиторские данные, информация интервью, самоописания, сделанные работниками на своих рабочих местах.
Перед началом анализа проектных бизнес-процессов ставится цель, определяется процесс для исследования, выбираются функции. Если анализируется материальный поток, то определяются ресурсы, затраты, связанные с ними, объем мощностей, движение ресурсов и так далее. То есть сначала определяется специфика процессы и цели исследования, потом подбирается необходимая информация и она анализируется в зависимости от целей работы.
Анализ проводится систематически, чтобы иметь возможность отслеживать процесс в динамике. Причинами для проведения срочного анализа могут стать увеличение времени поставки, непрозрачность процесса, слишком широкий ассортимент, увеличение затрат или постоянное изменение переменных расходов, большие транспортные и внутрифирменные затраты, необходимость дорогостоящей модернизации, низкая доля времени обработки, слишком высокая загрузка мощностей. Все это свидетельствует о нарушениях в процессах.
Источник: spravochnick.ru
Управление проектами и процессами: опыт внедрения BPM в проектном институте
Действительный член российской Ассоциации профессионалов управления бизнес-процессами (ABPMP Russian Chapter), к.т.н.
Проектный институт, о котором пойдет речь в настоящей статье, является одним из крупнейших институтов Европы, занимающихся градостроительным проектированием. Основной продукцией института являются генеральные планы городов, территориальные схемы, проекты планировки территорий или линейных объектов, институт выполняет и другие градостроительные работы.
Важной особенностью работы института является необходимость привлечения большого числа подразделений разной специализации как к выполнению проектных работ, так и к подготовке договорной документации на такие комплексные работы. При этом, одно из подразделений является основным исполнителем и несет ответственность за подготовку работы или договорной документации в целом, а остальные привлеченные подразделения являются соисполнителями — они выполняют свою специализированную часть работы и передают основному исполнителю для интеграции в общую работу.
Основной исполнитель, являясь ответственным за работу в целом, не всегда принимает результаты работ соисполнителей с первого предъявления, иногда отправляет их на доработку, сопровождая замечаниями. Иногда такая процедура повторяется несколько раз. И так может быть с каждым соисполнителем.
Кроме того, после того, как основной исполнитель закончил приемку материалов от каждого соисполнителя и подготовил консолидированный вариант документации (договорной или проектной), эти материалы направляются на проверку институтскими службами (сметно-договорной отдел, отдел экспертизы, юридический отдел и т.д.), после чего на рассмотрение и утверждение руководством института. При этом и с этапа проверки, и с этапа утверждения подготовленные материалы могут быть возвращены с замечаниями на доработку ответственному исполнителю, а от него и соответствующим соисполнителям. При этом сроки подготовки договорных документов затягиваются, возникают риски несвоевременной сдачи проектной документации по договору. Упростить процедуру подготовки и согласования документации в общем случае нельзя — слишком высока ответственность за качество документации (работы института во многих случаях формируют облик городов, качество жизни населения).
Внедрение проектного управления
Недовольство многих заказчиков института (включая государственные органы) вынудило руководство института искать выход из создавшейся ситуации. Было принято решение о создании Проектного офиса — специального подразделения, которое бы занималось координацией работ. Основной задачей подразделения должно было стать постоянное отслеживание хода работ по всем проектам и по всем подготавливаемым договорам, напоминание исполнителям о сроках и подготовка аналитических материалов для руководства по состоянию выполнения проектов и подготовки договоров. В середине 2013 в институте такое подразделение было создано.
В первые же дни работы проектного офиса выяснились следующие обстоятельства: поскольку исполнители не всегда присутствуют на месте (совещания, встречи с заказчиками, выезды на место и др.), да еще и не очень заинтересованы в дополнительном контроле за их деятельностью, мониторинг состояния проектов и подготовки договоров оказался очень трудоемким занятием. Один сотрудник центра реально мог эффективно контролировать небольшое количество работ.
Стало понятно, что для мониторинга «вручную» деятельности института по проектам и подготовке договоров нужно слишком много сотрудников проектного офиса, кроме того, контроль со стороны проектного офиса (в виде явно задаваемых вопросов, напоминаний, требований предоставить информацию) раздражал всех исполнителей, что порождало множество конфликтных ситуаций. Сотрудники проектного офиса воспринимались исполнителями подразделений (а зачастую и их руководителями) не как помощники, а как помеха в работе. Информация в результате не поставлялась, или поставлялась не полная, не соответствующая действительности. Нужно было искать иной подход к решению проблемы.
Переход к управлению процессами с использованием BPMS
Руководитель проектного офиса предложил использовать для решения проблемы систему (компьютерную программу) автоматизации бизнес процессов. Уже осенью 2013 года был реализован пилотный проект, в рамках которого в одной из систем автоматизации бизнес-процессов (BPMS), системе Bizagi, был настроен прототип процесса подготовки коммерческих предложений по заявке заказчиков. Пилотный проект показал, что средства BPMS способны не только решить проблему мониторинга, сделать процессы подготовки проектной и договорной документации прозрачными, но и стать проактивным началом, как бы «электронным диспетчером», назначающим задания всем участникам процесса.
В начале 2014 года были проведены конкурсные процедуры, заключены соответствующие договоры (аренда лицензий на использование системы BPMS и работы по настройке в системе бизнес-процессов предприятия). Около 2-х месяцев ушло на настройку процессов, 3 недели на тестирование. В конце апреля 2014 года первый процесс — «Заключение договора» был запущен в промышленную эксплуатацию.
Результаты запуска системы превзошли все ожидания. По каждому экземпляру процесса (по каждой заявке заказчика) можно было в любой момент времени наглядно видеть на какой стадии находится подготовка документации, а также сколько времени и кем из исполнителей было потрачено на соответствующие задания по всем предыдущим шагам. Система исправно управляла процессом, запуская задания параллельно нескольким исполнителям, четко выполняя заложенные правила выбора соответствующих исполнителей или согласующих, выбирая тип маршрута в зависимости от указанных параметров. С заданной частотой система напоминала о просроченных заданиях, причем не только самому исполнителю, но и его руководителям разного уровня в соответствии с заданными параметрами. Развитая система отчетов позволяла оперативно видеть прямо в системе не только текущее состояние, но и аналитику по процессам за любой выбранный период деятельности.
Опыт эксплуатации BPMS
Началась стадия эксплуатации системы и работы по оптимизации бизнес-процессов.
Ниже приведены факторы, влияющие положительно и отрицательно на эффективность внедрения:
Рассмотрим историю запусков экземпляров процесса «Заключение договора»:
Видно, что в начале эксплуатации наблюдается частая смена версий настроек процесса. Это естественно, поскольку сразу настроить процесс с параметрами, близкими к оптимальным, невозможно. По мере накопления опыта эксплуатации все меньше возникало потребностей к смене версий. Последние две версии выдержали годовую эксплуатацию каждая.
Также характерно, что в начальные периоды эксплуатации (первый год) не удавалось внести необходимые изменения за одну смену версии. Обязательно что-нибудь не получалось и приходилось сразу же за одной сменой версии осуществлять еще одну или даже две (май 2014 г. — 3 версии, август 2014 г. — 3 версии, декабрь 2014 г. — февраль 2015 г. — 3 версии). Последние изменения (февраль 2016 г.) удалось реализовать в рамках единственной смены версии. Это свидетельствует уже о накопленном опыте и уже о более совершенных настройках процесса.
Смена версии — это целый комплекс изменений. Небольшие изменения вносились в настройки практически ежедневно. Заявки на внесение таких (как, впрочем, и крупных) изменений регистрировались в электронной системе заявок на портале компании, выполнявшей работы по настройке системы.
Все решения о размещении таких заявок принимались на уровне руководителя проектного офиса, являвшегося руководителем проекта внедрения BPMS. Это очень важное обстоятельство. Делегирование полномочий руководства (которое утвердило только начальную схему процесса перед запуском в промышленную эксплуатацию) на рабочий уровень позволило обеспечить высокий темп внесения изменения в процесс. Схемы версий процессов и подпроцессов в бумажном виде не документировались — все они есть непосредственно в системе.
Эффект от внедрения BPMS
Одной из важнейших целей при оптимизации данного процесса было сокращение длительности процесса. Этот результат был достигнут, на графике приведенном ниже мы видим, что длительность процесса сократилась почти в три раза, причем сокращения длительности между последними версиями процесса уже незначительное, что свидетельствует о том, что приблизились к некому технологическому пределу:
Добиться такого значительного сокращения средних показателей длительности процесса «Заключение договора» удалось за счет нескольких факторов:
- Электронный документооборот (отсутствуют полностью потери на передачу документов);
- Все задания в процессе имеют установленный норматив времени на выполнение, исполнители видят время, отпущенное им на выполнение работы;
- В системе настроены напоминания о том, что что время отпущенное на выполнение задание заканчивается, что оно уже закончилось (с последующими регулярными повторами), причем напоминания приходят не только исполнителям, но и их руководителям;
- Система не дает уйти дальше с шага, если задание просрочено, без короткой объяснительной записки прямо в системе (специальное поле) — это доставляет дискомфорт и желание больше не попадать в такую ситуацию, работать без задержек;
- Силами проектного офиса велся непрерывный мониторинг по экземплярам процессов и по отдельным заданиям. Еженедельно руководству института направлялся аналитический отчет со всеми данными по просроченным заданиям и процессам;
- Процесс «Заключение договора» в своей основной части делится на 5 ветвей с различными маршрутами и алгоритмами выполнения. Это позволило в 4-х ветвях сделать упрощенные алгоритмы, избежать лишних шагов, тем самым сократить время исполнения процессов на данных ветвях процесса;
- В системе реализована автоматическая подготовка документов: договор, календарный план, соглашение о договорной цене, акт приемки работ по этапу или договору, счет на предоплату по договору, сопроводительное письмо к договорным документам, лист согласования договора. Для автоматической подготовки договора используется более 30-ти типов шаблонов (чтобы как можно меньшая доля договоров была подготовлена не автоматически);
- Автоматическая подготовка договоров системой не только сокращает время подготовки самого текста договора практически до нуля, но также позволяет избежать необходимости вычитывания, проверки самого текста договора кем бы то ни было (основные параметры: стоимости, сроки исполнения и т. д. согласовываются в системе до этого);
- Только очень малая часть договоров имеют «нешаблонный» текст, при этом, даже и этот текст готовится, как правило, путем внесения поправок в один из вариантов шаблонного договора.
Кроме того, сокращение длительности процесса достигнуто и за счет других способов оптимизации бизнес процесса. Доступность аналитических данных по выполнению заданий позволяет найти узкие места в процессе и устранить их, найти медлительных сотрудников и заменить их. Кроме того, можно устранить из процесса шаги, которые по статистике дают предсказуемый результат (если это создает риски — такие шаги следует перевести из последовательного выполнения в параллельное, чтобы на них не тратилось время процесса).
Участие руководства
Важным фактором, влияющим на длительность процессов, является то, как организовано в рамках процесса взаимодействие с руководством предприятия. При обсуждении схемы бизнес-процесса «Заключение договора» руководители (директор и его ключевые заместители) уверенно заявляли, что есть необходимость им в самом начале процесса видеть заявку заказчика, определять тип проекта и ответственного исполнителя, иметь возможность отказаться от заключения договора. В рамках реального процесса многие из тех же руководителей, в силу своей крайней занятости, рассматривали материалы очень долго, и если бы их шаги были встроены в процесс последовательно, то это бы его сильно тормозило. В институте построены схемы процессов, при которых задержки на рассмотрение руководством сведены к минимуму, почти к нулю, но при этом выполнены все пожелания руководителей по возможности участия в рассмотрении проектов.
Работа с пользователями и роль руководства
Большое внимание в ходе проекта уделялось работе с пользователями. Обо всех нововведениях пользователи оповещались рассылками по электронной почте.
Силами проектного офиса были подготовлены подробные инструкции по работе в системе, полное пошаговое описание процесса «Заключение договора» с детальной информацией о действиях пользователя на каждом шаге, с рассмотрением всех возможных вариантов, с описанием доступной информации и доступных возможностей. Все материалы были размещены на корпоративном портале и были доступны всем пользователям. Постоянно работала «горячая линия» — можно было задать вопросы по телефону или электронной почте. В случае возникновения у пользователя любых проблем, специально выделенный сотрудник проектного офиса оперативно подходил на рабочее место пользователя и помогал справиться с проблемой.
Практически все обращения пользователей комментировались в рассылке всем пользователям — чтобы и другие пользователи понимали причину возникновения данных затруднений в работе с системой и заранее знали, как в этом случае справиться с возникшей проблемой. Пользователям предлагалось принять участие в еженедельных обучающих семинарах, однако эта форма обучения не прижилась — как правило семинары отменялись из-за отсутствия слушателей. Собрания пользователей также оказались неэффективными, конструктивного обсуждения работы в системе на таких собраниях не получилось.
В ходе реализации проекта трижды менялся руководитель предприятия. Поддержки со стороны руководства было явно недостаточно, ряд пользователей демонстрировали откровенный саботаж, достаточно большая часть пользователей работала в системе, но постоянно сопровождала работу выражением недовольства при каждом удобном случае.
Как же в таких условиях все-таки удалось реализовать проект, обеспечить работоспособность системы? Понятно было, что без поддержки руководства реализовать вариант нажима (принудить работать) не получится и нужно искать положительные стимулы пользователям для работы в системе.
Проектный офис во-первых, не пошел на конфликт, и визировал в том числе и договоры, созданные вне системы (тем самым демонстрируя, что важен результат — скорейшая передача подготовленного договора заказчику), во-вторых в системе оперативно реализовывались любые разумные пожелания пользователей (чтобы им было удобнее работать в системе), в-третьих, в системе были реализованы сервисные функции, позволяющие существенно снизить пользователям трудоемкость операций (автоматическая генерация многих документов), в-четвертых, в системе пользователям было доступно больше информации, чем в письме-обращении заказчика. В частности, в системе пользователь мог видеть обращения данного заказчика по другим объектам, а также другие обращения этого и других заказчиков по данному объекту с подготовленными в ответ документами.
Постепенно пользователи оценили сами преимущества работы в системе и доля договоров, подготовленных вне системы, сократилась практически до нуля.
Обеспечение качества
Еще одним важным свойством автоматизированного бизнес-процесса является то, что достигается автоматически: выполнение всех регламентов, заложенных в настройку бизнес-процесса. Если при управлении процессом «вручную», исполнитель-координатор может что-то перепутать, забыть кому-то показать, с кем-то согласовать и т.д., то с автоматизированной системой таких ошибок не бывает. Процесс всегда идет в полном соответствии с заданными параметрами и заложенными алгоритмами, определяющими маршрут и порядок продвижения. Это свойство снижает риски того, что документация не проверена или не согласована должным образом, т.е. снижает риски выпуска некачественной документации.
Источник: delovoymir.biz