На этапе создания и становления компании чрезвычайно важна роль системы документационного обеспечения управления проектами. Система документационного обеспечения управления проектами — комплекс нормативных, организационно-распорядительных и учебно-методических документов, обеспечивающих эффективное функционирование организационной системы управления проектами и взаимодействие ее компонентов с информационной системой управления проектами (ИСУП) компании.
Задачами этой системы являются:
♦ формирование идеологии и методологии управления проектами в компании;
♦ регламентация бизнес-процессов, обеспечивающих внедрение проектного управления;
♦ обеспечение практической реализации матричной схемы управления при планировании и исполнении проектов компании;
♦ разграничение прав, обязанностей и ответственности исполнителей проекта;
♦ обеспечение обучения управляющих проектами планированию и ведению проектов в информационной системе управления проектами компании.
3 шага описания бизнес-процесса
Структура системы документационного обеспечения управления проектами приведена на рис. 6.
Рис. 6. Система документационного обеспечения управления проектами
Основным документом системы является «Регламент управления проектами», который должен быть разработан с учетом рекомендаций стандарта управления проектами ANSI PMI РМВОК GUIDE 2000 и требований стандарта ISO 10006 Quality management systems — Guidelines for quality management in projects.
♦ Основные понятия и термины.
♦ Система управления проектами:
ü Организационная система управления проектами.
ü Информационная система управления проектами.
ü Система документационного обеспечения управления проектами.
♦ Статус, права и ответственность управляющего про
ектом.
♦ Статус и функции Центра управления проектами.
♦ Процессы управления проектами компании:
ü Управление интеграцией проекта
ü Управление сроками проекта.
ü Управление стоимостью проекта.
ü Управление качеством проекта.
ü Управление человеческими ресурсами проекта.
ü Управление информационным взаимодействием в проекте.
ü Управление рисками проекта.
♦ Управление контрактами проекта.
♦ Содержание фаз проекта:
ü Фаза 1. Инициация.
ü Фаза 2. Планирование.
ü Фаза 3. Исполнение.
ü Фаза 4. Завершение.
♦ Особенности выполнения внутренних проектов.
Ø №1- Схема организационной системы управления проектами.
Ø № 2 — Матрица ответственности организационной системы управления проектами.
Ø №3 — Требования к составу, содержанию и правилам изложения раздела «Проектное управление» положений о подразделениях и должностных инструкций.
Ø №4 — Укрупненная схема бизнес-процесса управления проектами.
Ø №5 — Схема бизнес-процесса управления интеграцией проекта.
Ø №7- Схема бизнес-процесса управления сроками проекта.
Бизнес процессы компании — начните с реестра бизнес-процессов
Ø №8- Схема бизнес-процесса управления стоимостью проекта.
Ø №9 — Схема бизнес-процесса разработки схемы информационного взаимодействия в проекте.
Ø № 10 — Схема бизнес-процесса управления человеческими ресурсами проекта.
Ø №11 — Схема бизнес-процесса управления контрактами проекта.
Ø № 12 — Перечень обязательных документов дела проекта.
Ø № 13 — Форма описания проекта.
Ø № 14 — Методика анализа проекта по методу освоенного объема.
Ø № 15 — План задействования участников проекта.
Ø № 16 — Форма матрицы ответственности.
Ø № 17 — Форма плана управления информационным взаимодействием в проекте.
Ø № 18 — Перечень нормативных и справочных документов управляющего проектом.
Важнейшими дополнениями к указанному регламенту являются «Регламент управления рисками проектов» и «Регламент обеспечения качества проектов», детально описывающие соответствующие бизнес-процессы и содержащие комплекс методик, обеспечивающих реализацию этих бизнес-процессов. В основе информационной системы управления проектами должны лежать программные продукты фирмы Primavera. Ответственность за эффективность применения ИСУП возложена на центр управления проектами (ЦУП).
♦ методологическая — разработка и совершенствование корпоративных стандартов в области управления проектами, создание типовых моделей проектов и выдача их в рабочие группы проектов, ведение базы данных типовых операций, выявление типовых фрагментов проектов для последующего использования, разработка рабочей документации ИСУП, обучение сотрудников, ведение электронной библиотеки учебных, нормативных, информационных и научно-технических материалов по управлению проектами, проведение консультаций участников проекта на всех фазах жизненного цикла;
♦ аналитическая — анализ эффективности планирования и исполнения проектов, участие, при необходимости, в подготовке решений управляющего проектом или руководства компании по корректировке плана проекта и управлению ресурсами;
♦ архивная — хранение информации, формализация накопленных дел проектов;
♦ инфраструктурная — руководство внутренними проектами создания и модернизации ИСУП, менеджмент лицензий и прав на доступ к ИСУП, контроль за технологическим состоянием ИСУП;
♦ контрольная — мониторинг графиков исполнения проектов и состояния пула ресурсов компании, обработка и доведение до заинтересованных лиц информации об отклонениях от плана проекта вместе с рекомендациями по возможному маневру ресурсами, контроль полноты и
объективности документации дела проекта;
♦ коммуникативная — предоставление информации о портфеле проектов компании и отдельных проектах представителям заинтересованных в проекте и деятельности компании сторон на основании решения генерального директора компании.
♦ разработка методических и руководящих документов по вопросам управления проектами и работе в ИСУП;
♦ организация обучения и консультирования специалистов проектных групп;
♦ ведение депозитария и архива проектов в ИСУП;
♦ формирование типовых моделей проектов для использования при запуске очередного проекта компании;
♦ участие в оптимизации планов проектов;
♦ разработка предложений и участие в подготовке решений руководства компании и/или управляющих проектами по маневру ресурсами с целью недопущения срыва плановых сроков проекта;
♦ сопровождение внедрения и руководство эксплуатацией ИСУП;
♦ обеспечение работы диспетчерских групп филиалов.
Для обеспечения эффективного взаимодействия управляющих проектами с ЦУП и рационального использования ИСУП в компании разработан «Регламент планирования и ведения проектов в ИСУП». Регламент определяет:
♦ порядок подготовки приказов о начале фазы инициации проекта и об инициации проекта в случае положительного итога фазы инициации;
♦ обязанности управляющего проектом по своевременной актуализации и обеспечению объективности информации по зарегистрированному в ИСУП проекту;
♦ правила ведения управляющим проектом электронной версии дела проекта;
♦ порядок взаимодействия управляющих проектами с сотрудниками центра управления проектами по вопросам календарного планирования и отслеживания хода работ по проекту;
♦ обязанности сотрудников ЦУП по контролю календарного планирования и ведения проектов;
♦ периодичность и состав сведений, представляемых управляющим проектом в ЦУП в процессе исполнения проекта.
Одной из основных задач, возложенных на центр управления проектами, является обучение управляющих проектами планированию и ведению проектов в Primavera. С этой целью центром подготовлен комплекс методических и справочных материалов, включающий:
1.«Справочник по планированию и ведению проектов в
Primavera», представляющий собой практикум, проводящий
управляющего проектом по всем шагам планирования и отслеживания хода исполнения проекта.
2.«Руководство для управляющих проектами по Primavera».
3.«Установление мобильного терминального доступа к Primavera. Руководство для управляющих проектами».
Практическая апробация указанных материалов при обучении нескольких групп управляющих проектами показала их высокую эффективность.
Центром управления проектами разработана и утверждена «Программа обучения управляющих проектами планированию и ведению проектов в ИСУП».
Кроме собственных разработок центра управления проектами в состав системы документационного обеспечения управления проектами должен быть включен комплекс инструкций по работе с Primavera, а также ряд стандартов компании, регламентирующих маркетинговую и контрактную деятельность управляющих проектами.
Основные этапы разработки проектной документации представлены на рис. 7.
Рис.7. Этапы разработки проектной документации
Для технически и экологически сложных объектов по решению одновременно с разработкой рабочей документации и осуществлением строительства могут выполняться дополнительные детальные проработки проектных решений по отдельным объектам, разделам, вопросам.
Основным документом, регулирующим правовые и финансовые отношения, взаимные обязательства и ответственность сторон, является договор (контракт), заключаемый заказчиком с привлекаемыми им для разработки проектной документации организациями, другими юридическими и физическими лицами. Неотъемлемой частью договора (контракта) должно быть задание на проектирование.
Разработка проектной документации осуществляется при наличии решения о предварительном согласовании места размещения объекта, на основе утвержденных обоснований инвестиций в строительство или иных предпроектных материалов, договора и задания на проектирование.
Проектная документация, разработанная в соответствии с исходными данными, техническими условиями и требованиями, выданными органами государственного надзора (контроля) и заинтересованными организациями при согласовании места размещения объекта, дополнительному согласованию не подлежит за исключением случаев, особо оговоренных законодательством Российской Федерации.
Проектирование объектов строительства должно осуществляться юридическими и физическими лицами, получившими в установленном порядке право на соответствующий вид деятельности.
Использование изобретений при проектировании объектов строительства и правовая защита изобретений, созданных в процессе разработки проектной документации, осуществляются в соответствии с действующим законодательством.
Разработанная документация является планом действия и направлена на достижение следующих основных целей:
1. Обеспечить понимание и одобрение целей проекта и средств их достижения.
2. Без плана члены проектной команды говорят на «разных языках» и могут работать по многим различным направлениям несогласованно. Одобрение командой краткого, но глубоко проработанного плана проекта является фундаментальным средством контроля за проектом. Одобрение плана всеми участниками проекта означает понимание и согласие с целями
проекта и путями их достижения.
3. Обеспечить наличие формального описания требуемых ресурсов (времени, денег, штата) и вех, которые должны быть достигнуты.
Масштабы использования систем управления проектами в различных организациях могут существенно варьироваться. Сложность задач по внедрению зависит от масштабов организации, имеющейся структуры управления и степени автоматизации, масштабов и типа реализуемых проектов, степени вовлеченности сторонних организаций.
Дата добавления: 2018-02-15 ; просмотров: 1911 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Контур сбора требований
Основной операцией в данном случае является процедура регистрации требований на доработку. Под требованием понимается в данном случае любое формально описанное условие, которому должно удовлетворять создаваемое решение. В частности, требованиями являются:
- Ошибки, выявленные при внутреннем или внешнем (ПСИ) тестировании, в процессе эксплуатации решения
- Функциональные требования (доработки)
- Нефункциональные требования (ограничения, которым должно удовлетворять решение)
Требования могут поступать из различных источников, например:
- Представители Заказчика
- Тестеры в составе проектной команды
- Руководства компании
Все требования хранятся в Репозитории требований. Подробнее о требованиях (их атрибутах и жизненном цикле) написано в разделе «Информационная модель». Зарегистрировать требование может любой участник проектной команды, заполнив необходимый набор полей. В дальнейшем все активности по разработке связываются с конкретными требованиями, на реализацию которых они направлены. После регистрации требования выясняются основания для его реализации (ТЗ, договора и т.д.). Если оснований не обнаруживается, то требование отвергается или инициируется процесс внесения дополнений в договорные документы. Если основания есть, то требование может быть использовано в других контурах работ. Также требование может быть уточнено, если из его описания не понятно имеет оно основания или нет. Рисунок 1 – Укрупненная схема бизнес процесса разработки ПО Все требования делятся на две группы с точки зрения подхода к их реализации: Мелкие доработки
- длительность их реализации до 1 человеко-дня И
- не требуют аналитической проработки (написания Технического проекта)
Средние и крупные доработки
- длительность реализации более человеко-дня ИЛИ
- требуют аналитической проработки (написания Технического проекта)
Решение о реализации мелких доработок принимается руководителем группы путем назначения требования на соответствующего разработчика (Контур небольших доработок). Реализация средних и крупных доработок происходит постадийно:
- Планируется реализация доработок и аналитических работ по их проработке (Контур среднесрочного планирования)
- Проводятся аналитические работы, по их результатам составляется Технический проект (ТП) на реализацию требования (Контур аналитических работ)
- В рамках детального планирования работ по разработке текущей версии выбираются проработанные требования с готовыми ТП и включаются в состав задач для рабочего проектирования и реализации в текущей версии (Контур разработки версии)
Контур среднесрочного планирования
- Руководителем проекта
- Руководителем группы
- Архитектором
- в соответствии со среднесрочным планом должны быть реализованы в рамках настоящей версии И
- по которым завершена аналитическая проработка (имеется согласованный ТП)
- Архитектором
- Руководителем группы
- Руководителем проекта
- Описываются параметры версии (номер, дата выпуска, перечень файлов и др.)
- Перечисляются реализованные в версии требования (новый функционал, устраненные ошибки)
- Содержится информация о развертывании версии (последовательность действий)
- Если в рамках версии изменилась структура хранилищ данных, то в рамках этого документа прикладываются SQL-скрипты для перехода со старой структуры на новую
- Все «Ошибки тестирования версии» устранены
- Принимается решение о выпуске версии с рядом не устраненных ошибок
Источник: studfile.net
Система обучения в отделе продаж, как фактор развития бизнеса
Дано: компания, работающая на рынке В2В. Проблема: плановые показатели по продажам не выполняются на 100%, доля рынка не увеличивается, конкуренты опережают.
Задача: увеличить объем продаж за счет развития компетенций менеджеров по продажам и создания системы внутреннего обучения.
В своей практике я столкнулась с тем, что в подавляющем большинстве случаев руководители связывают причины невыполнения плановых показателей с работой менеджеров по продажам. Отсюда такая популярность тренингов по продажам. Но не все коммерческие задачи можно решить исключительно обучением и развитием навыков sales-команды. Во многих случаях требуются основательные преобразования в системе продаж.
В представленном мной кейсе работе по построению системы внутреннего обучения предшествовала диагностика, включающая анализ системы управления продажами, исследование конкурентного окружения, обзор рынка и т.д. Задача диагностики – выявить проблемы, которые лежат на стратегическом и операционном уровнях и являются корневыми. Без обнаружения и искоренения этих проблем обучение продавцов не принесёт ожидаемых результатов.
Все упомянутые мероприятия достойны отдельной статьи, поэтому в данном кейсе я не буду их описывать, а сосредоточусь на системе обучения.
После проведенных мероприятий по анализу причин невыполнения плана, я убедилась, что существенных проблем, которые должны быть в первую очередь решены на стратегическом и операционном уровнях, нет. А именно, компания предлагает рынку конкурентоспособный продукт, на рынке имеется платежеспособный спрос, планы по продажам соответствуют возможностям компании. При этом навыки продаж даже у опытных менеджеров требуют развития.
В частности выяснилось, что менеджеры не умеют донести до клиента конкурентные преимущества продукции, показать финансовые выгоды от сотрудничества. Поэтому переговоры со «сложными» клиентами часто заканчиваются неудачами.
Совместно с отделом продаж мы внедрили систему внутреннего обучения, которая «усилила» наших менеджеров по продажам, вооружила их необходимыми знаниями и навыками.
Анализ источников доходов
Сначала мы выделили способы получения доходов, на которые влияет отдел продаж. В нашем случае план продаж выполнялся за счет трех источников поступления денежных средств:
- привлечение новых клиентов
- расширение ассортимента у клиентов
- сервисное обслуживание клиентов
По каждому каналу поступления денежных средств мы разработали программы обучения. Начали мы с описания бизнес-процессов, которые приводят к получению компанией денежных средств.
