что такое структурная декомпозиция проекта

Структурная декомпозиция работ

Структурная декомпозиция работ (СДР) — это представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции (то есть разбиения его на составные части по какому-либо признаку). СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

В проектном управлении обычно говорят о декомпозиции по основным этапам жизненного цикла проекта.

Весь жизненный цикл проекта (ЖЦП) делится на две основные стадии: планирование проекта и выполнение проекта. В эти стадии практически всегда входят такие этапы, как предпроектный этап, этап планирования, этап реализации, этап контроля (или мониторинга), этап завершения. И каждый из этих этапов состоит из какого-то количества работ, которые как раз и позволяют выполнить весь текущий проект и удачно его завершить.

Например, СДР проекта строительства и ввода в эксплуатацию нефтеперерабатывающего завода выглядит так (работа выполнена студентами третьего курса института отраслевого менеджмента кафедры экономики и управления в топливно-энергетическом комплексе, проходившими обучение по дисциплине «Управление проектами» на кафедре управления проектами):

Сетевой график

Теперь можно построить сам сетевой график проекта, который отражает последовательность выполнения работ. На сегодняшний день в проектном управлении распространены 2 варианта сетевых графиков: «работа-вершина» и «вершина-событие».

В сетевом графике типа «работа-вершина», работы представлены «вершинами», обычно прямоугольниками. Сетевой график будет выглядеть следующим образом:

Исторические раньше возник метод «вершина-событие», однако в наше время чаще используется «работа-вершина», т.к. он нагляднее и удобнее.

Теперь можно провести расчёт сетевого графика. Сначала идём слева направо и рассчитываем ранние сроки работ (раннее начало и раннее окончание), а затем справа налево, получая поздние сроки работ (позднее начало и позднее окончание). Ранние сроки работы — это раньше которых она не может начаться/завершиться. Поздние — крайние сроки ее начала/завершения.

Теперь мы можем применить метод критического пути (МКП) — один из главных методов в управлении проектами. Те работы, у которых ранние и поздние сроки совпадают, называются критическими работами проекта, а в совокупности они образуют его критический путь. Это самая длинная последовательность работ проекта, которая определяет его длительность. Для менеджера крайне важно знать и контролировать критический путь проекта, чтобы не затянуть его реализацию. Если необходимо оптимизировать проект по срокам, можно также сокращать работы, лежащие на критическом пути.

Остальные работы (не критические) имеют временные резервы: частный и общий. Частный говорит нам о том, на сколько мы можем задержать работу, на задерживая ни одной работы-последователя. Общий — на сколько можно задержать работу, задержав работы-последователи, но все же завершив проект в срок.

Сетевой график лежит в основе не только метода критического пути, но и другого метода: PERT (Program Evaluation and Review Technique). Его отличает то, что в нем учитывается вероятностная оценка длительности работ.

По каждой работе эксперты дают оценки длительности. Выделяют оптимистичную, пессимистическую и ожидаемую длительность. Затем в сетевой график заносят длительность, которая учитывает все оценки и рассчитывается по формуле (коэффициенты могут изменяться):

Матрица «Распределения административных задач управления»

Матрица распределения административных задач управления (РАЗУ) может использоваться для оптимизации функциональной структуры организации посредством анализа функций подразделений, определения трудоемкости выполнения управленческих задач и норм загрузки подразделений и служб. Рациональное распределение функций управления способствует эффективному достижению целей организации (фирмы). Определение целенаправленности любой организации, т. е. общей цели существования фирмы, является весьма важной и сложной проблемой.

Цель — это желаемое состояние любой системы. Цель состоит из совокупности подцелей (задач) и должна обладать следующими характеристиками:

Источник

Декомпозиция. Как разобрать огромный проект на понятные сегменты для предварительной оценки

Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?

Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.

Уровни декомпозиции

Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!

1 уровень. Крупные блоки или компоненты

Это может быть блок с е-коммерсом, личный кабинет, мобильное приложение, супер-навороченная админка. В общем, любые блоки работ, которые могут быть как-то между собой связаны, но которые можно делать изолированно друг от друга.

2 уровень. Страницы сайта или экраны мобильного приложения

В случае с блоком «мобильное приложение», как на схеме выше, разбиваем его на экраны. Но как узнать, что вы учли все-все-все возможные экраны? Для проверки полноты берите в расчёт сценарии использования — это даст понимание, какие задачи юзеры будут решать в приложении (или на сайте) и каким примерно образом они это будут делать.

Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.

Есть соблазн написать в смете только сценарий использования и его оценку (скажем, сценарий покупки товара или сценарий заказа такси) — ну, ведь понятно же, что там внутри. Нет, непонятно, и есть большой риск потерять множество шагов, поскольку такие сценарии большие, и их крайне сложно адекватно оценить целиком.

Когда сценарий раскладывается на экраны, шансов ошибиться становится меньше. Но помните, что каждый сценарий стоит проверять на связанность — достаточно ли вам вот этих экранов, чтобы этот сценарий сбылся?

У нас есть маркетплейс — магазин, куда другие производители могут загружать свои товары. Сценарии, лежащие на поверхности: загрузка своих товаров (загрузка и описание, разделы каталога и вот это вот всё), покупка товара (шаги покупателя на пути к цели), обработка заказа (как будут распределяться деньги, как будет получать свою долю маркетплейс и так далее). Если всё это не расписать подробно, можно запросто упустить кучу нюансов.

Будет ещё легче, если вы выделите ключевые роли на проекте (пользователь, администратор интернет-магазина и т. д.), у каждой из которых есть свой сценарий, а у каждого сценария — свой набор экранов. И тогда проверить полноту экранов ещё проще — достаточно посмотреть, связан и выполняется ли сценарий конкретной роли по ним.

3 уровень. Содержание экранов

В общем случае у вас на экранах могут быть какие-то вкладки либо какие-то блоки — грубо, вложенные экраны. Например, страница корзины/оформления заказа — здесь всегда есть блок товаров со своим сценарием (добавить-убавить-очистить), а еще блоки доставки, оплаты, авторизации, бонусной системы и так далее. Бывают ситуации, когда эти блоки также разбивают на экраны по шагам. Зависит от решения, принятого по итогам аналитики — бывает, что удобнее их всё-таки «слить» воедино.

Задача менеджера, когда он добрался до такого экрана, — посмотреть, из чего тот состоит. Бывает, экран легко разбить на блоки, бывает — сложно. Яркий пример сложной разбивки — калькуляторы: по ним чаще всего неочевидно, что происходит и как процесс расчёта делить на шаги.

Когда вы добираетесь до третьего уровня, нужно быть супер-внимательными, потому что на странице могут появляться самые разные вещи. И важно понимать, откуда они там вообще берутся — от этого будут сильно зависеть ваши оценки.

Откуда эта хрень на странице?!

Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».

Например, аналитик сказал: «это мы как-нибудь на коде решим», а потом на планинге сидят 4 умных человека, смотрят друг на друга и спрашивают: «кто это придумал, что это за маразм?!». Такая ситуация — явный признак, что где-то недоработали раньше. Бывает, конечно, что принятие какого-то решения действительно откладывается, но это должно быть осознанно и где-то зафиксировано.

Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.

Итак, какими могут быть варианты, откуда берутся данные на странице?

Вариант 1. Хардкод

Самый простой в реализации вариант ответа на наш вопрос — хардкод. Это значит, что программисты сели, прямо в коде зафигачили какую-то штуку, и теперь поменять ее могут только они. Самые частые блоки, с которыми так делают — логотипы компаний, иногда ссылки на соцсети, время от времени такое делают с меню (всё реже), телефонами (плохо!), декоративными элементами на верстке. Всё это — более-менее разумные моменты. Неразумно, это когда в код зашиваются, например, ВСЕ страницы или SEO-тексты блоками.

Вариант 2. Включаемая область

У включаемых областей есть специфика: во-первых, их можно случайно удалить. Во-вторых, если в них указываются даты мероприятий или цены на товары, это чревато путаницей, поскольку у этих областей нет связанности: если поменять дату или цену в одном месте, в другом она останется той же. Клиенты зачастую сразу говорят, что такого им не нужно — а значит, придётся продумывать, как менять цены, даты и прочие изменяемые поля автоматически и повсеместно.

Вариант 3. Из админки (из базы данных)

Итак, мы знаем, что какие-то данные выбираются из базы данных. Тогда нам нужно понимать, из какой сущности и из какого поля. Примеры сущностей в интернет-магазине: «товар», «раздел», «пользователь», «заказ» — то есть то, что состоит из каких-то полей. Поля — например, «цена».

Но достаточно ли нам будет понимать, из какой сущности и из какого поля выводятся данные? Не совсем. Когда выбираете какую-то информацию из базы, она может выводиться не в том виде, как она там хранится, а в несколько модифицированном.

Например, это формула

Когда информация хранится в базе, но ее нужно как-то определенным образом модифицировать, появляется понятие «формула». Одна из самых опасных вещей, которую менеджеры часто пропускают.

Когда вам аналитик говорит «ну там это как-то считается» — навострите ушки, впереди точно будет затык. Математики не понимают программистов и считают что, их формулу достаточно переписать и следом «просто» запрограммировать — делов-то. Но когда клиента начинаешь спрашивать о формуле, часто слышишь что-то вроде «ой, она у нас там в excel», или «механика пока непонятна», или вообще «ну скопируйте вон с того сайта».

Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».

Вот из-за этого о формулах никто не любит думать:)

В зависимости от используемой технологии бывает, что часть данных хранится в файлах. Может показаться, что это какая-то сущность или поле сущности, но это всё-таки ФАЙЛ.

Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.

С файлами ещё бывает история, что их нужно хранить на отдельных серверах, или в облаках S3, закачивая по специальному протоколу, но это уже нюансы масштабирования. На старте проекта, окупаемость которого непонятна, городить тут огород я не вижу смысла. Исключение — тяжелый видео-контент. Его лучше сразу писать в видеохостинги.

— Владимир Завертайлов, CEO & Founder

Как данные попадают в базу данных?

Обычно администратор или контент-менеджер садится и забивает данные ручками. Тогда здесь должен возникать вопрос, а хватит ли ему стандартных компонентов админки для этого. Для этого ПМ должен быть очень хорошо знаком с возможностями стандартной административной панели. А ещё с ними должен быть знаком аналитик и тестировщик (про кодера, понятно, молчим). В Сибирикс все QA-специалисты проходят базовый курс контент-менеджера, чтобы понимать, на что способна админка. Ну, а про то, что QA-спецы у нас обычно вырастают в проджект-менеджеров, мы уже как-то писали.

У вас на дизайне есть слайдер, где расставлены точки, по клику на которые открывается всплывашка, в которой есть фотография, описание и ссылка на куда-нибудь. Вопрос: как расставлять эти точки? Как вариант — координаты X и Y, но вряд ли контентщик будет счастлив от такого функционала. А значит, придётся что-то придумывать. И значит, в смету нужно это заложить.

Второй момент, который проджекты часто упускают, — права доступа и хватит ли их. А значит, это тоже нужно иметь ввиду и сразу перечислить потенциальные роли.

Вариант 4. Интеграция со сторонним ресурсом

Один из источников данных в базе — пользовательский контент. И здесь важно понимать, как он попадает в базу. На этом этапе часто теряется один из крупных сценариев: например, как пользователь вносит отзывы. У отзывов часто бывает рейтинг — штука с виду простая, но внутри она может быть довольно сложно организована. У чего больше рейтинг? Там, где поставили одну оценку в 10 баллов, или где 1000 оценок, но разных? Среднеарифметическое тут работает плохо. Но хитрые алгоритмы есть — привет, ещё один резерв в смете.

Если данные берутся всё-таки с внешнего источника, то без интеграции никак. Вариантов интеграции может быть несколько:

Другая проблема — админы сайтов, с которым парсятся данные, не слишком счастливы, что эти данные кто-то «ворует», и будут всячески защищаться. А это приводит к «падению» парсинга и попаданию в черные списки. Вы попытаетесь с этим бороться добавлением каких-нибудь платных proxy — короче, целый квест. Есть особые сервисы для организации парсинга — например, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy или Content Grabber (полный список из 30 сервисов ищите тут).

Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:

Хуже всего бывает, когда говорят «ну вы, программисты, между собой договоритесь и разберитесь сами как-нибудь». Если протокол не формализован и взаимной ответственности нет, критический путь проекта будет пролегать через интеграцию, и на ней он завалится. Или по крайней мере, здесь потратится куча времени на согласование с программистом заказчика его протокола и отладку.

Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).

Как все это «подружить»

Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».

Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂

Когда это может не сработать

Если на проекте есть какая-то дремучая математика, и вы живете в мире, полном злых неожиданностей, то декомпозиция по экранам будет давать сбой. В общем случае она довольно хорошо показывает, что и как происходит на типовых проектах.

Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!

Источник

Создание структурной декомпозиции работ для задач по проекту

Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2

Часто проект состоит из нескольких мероприятий или задач. Структурная декомпозиция работ (WBS) — это иерархическое представление задач проекта. В этом разделе описан порядок создания WBS, добавления в него задач и добавление требований и другой информацию для каждой задачи. Он также содержит сведения о работе с доходом и затратами в WBS, работе с ожидаемыми и фактическими часами для задач в WBS и работе с WBS в Microsoft Project.

Можно ввести следующую информацию для задач в WBS.

Последовательность задач в иерархии

Другие задачи, если имеются, которые необходимо выполнить до запуска задачи

Дата начала, дата окончания и продолжительность задачи

Количество часов, необходимое для задачи

Необходимые навыки и образование работника

Работники, назначенные для этой задачи

Расчетные доход и затраты

Можно создать WBS вручную или импортировать задачи из другого WBS или шаблона WBS.

Этот раздел не применяется к версиям Microsoft Dynamics AX до накопительного обновления 7 для Microsoft Dynamics AX 2012 R2. При использовании более ранней версии Microsoft Dynamics AX 2012 см. раздел Структурная декомпозиция работ (форма).

Необходимые условия

В следующей таблице показаны обязательные компоненты, которые должны быть подготовлены до начала работы.

Связанные задачи конфигурации

Настройка календарей для рабочих периодов, которые будут использоваться в проектах. Дополнительные сведения см. в разделе Создание календарей рабочего времени. Если не назначен рабочий календарь для связанного проекта, появится сообщение в форме WBS.

Выбор рабочего календаря, который будет использоваться по умолчанию для новых проектов. Дополнительные сведения см. в разделе Настройка параметров для системы табелей учета рабочего времени.

Настройка категорий проектов. Дополнительные сведения см. в разделе Создание категорий и групп категорий для проектов.

Создание WBS для проекта вручную

Можно создать WBS для определенного проекта, начав с пустой формы WBS.

Для создания WBS для проекта выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Откройте проект, для которого необходимо создать WBS. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

В форме Структурная декомпозиция работ первая строка в сетке содержит имя проекта и сумму значений, указанных для задач. Невозможно изменить эти поля непосредственно.

Для добавления задачи в разделе Область действий щелкните Задача и введите сведения о задаче. В следующей таблице показана информация, которую можно вводить в каждое поле.

Имя задачи

Введите имя задачи.

Предшественники

Введите идентификационный номер задач, которые необходимо выполнить до того, как может быть начата текущая задача. У задачи может быть несколько предшественников.

Категория

По умолчанию категория автоматически копируется из категории для часов по умолчанию часов в форме Параметры модуля «Управление и учет по проектам». Можно изменить категорию для задачи.

Усилия (часы)

Введите расчетное общее количество часов, необходимых для выполнения задачи. Количество часов может отражать сведения о нескольких работниках для задачи и также может включать все часы, которые могут разнести работники поставщика по проекту.

Число ресурсов

Введите количество работников, необходимых для выполнения задачи, включая работников поставщика.

Если для задачи вводятся продолжительность и усилия в часах, количество ресурсов работников рассчитывается автоматически.

Начало

Введите расчетную начальную дату для задачи.

Готово

Введите расчетную дату окончания для задачи. Если ввести начальную дату и продолжительность в днях для задачи, дата окончания будет добавлена автоматически.

Продолжительность (дни)

Введите расчетное количество рабочих дней, необходимых для выполнения задачи. Если ввести дату начала и окончания, продолжительность рассчитывается автоматически.

Работники

Выберите одного или нескольких работников для планирования задачи.

Можно сделать выбор в списке работников, время которых уже зарезервировано для проекта, установив флажки рядом с их именами, или нажать кнопку Просмотреть дополнительных работников, чтобы открыть форму Назначение работника. В форме Назначение работника можно выбрать других работников, чтобы назначить их задаче и добавить в проектную группу.

Дополнительные сведения о том, как выбрать дополнительных работников для задачи и проектной группы, и о том, как Microsoft Dynamics AX распределяется время между работниками в определенных ситуациях, см. в разделе Назначение работников задачам вручную в структурной декомпозиции работ в AX 2012 R3.

Чтобы добавить задачу на уровне ниже другой задачи, выберите задачу, а затем в разделе Область действий щелкните Задача. Заполните сведения в полях для новой задачи. Сведения о том, как изменить структуру задач в WBS, см. в разделе «Организация задач в WBS» далее в этом разделе.

Импорт задач в WBS

Можно импортировать задачи из WBS для одного проекта в WBS для другого проекта. Можно также импортировать задачи из шаблона WBS в WBS для конкретного проекта. Дополнительные сведения о создании шаблона WBS см. в разделе Создание шаблона структурной декомпозиции работ для проектов.

При импорте задач из WBS другого проекта или из шаблона WBS все задачи импортируются. После импорта задач можно удалить все задачи, которые не относятся к текущему проекту.

Чтобы импортировать задачи в WBS, выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Откройте проект, для которого создается WBS. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

В форме Структурная декомпозиция работ выберите задачу, для которой следует импортировать задачи. Импортированные задачи добавляются в выбранную задачу как подзадачи. После импорта задач их можно перемещать (по необходимости) для текущего проекта и WBS.

На панели «Действие», на вкладке СДР, щелкните Импортировать шаблон в выбранной задаче.

В форме Копировать из можно указать, следует ли импортировать задачи из WBS для другого проекта или из шаблона WBS. По умолчанию только шаблоны WBS перечислены в поле Название. Чтобы выбрать в списке проектов, снимите флажок Показывать только шаблоны.

В поле Название выберите имя WBS или шаблона WBS, содержащего импортируемые задачи, а затем щелкните ОК.

Организация задач в WBS

По мере работы по проекту можно изменять последовательность задач, изменять предшествующие задачи и изменять уровень для задачи. Например, можно импортировать задачи из другого проекта, а затем решить, что импортированные подзадачи являются важным начальным этапом текущего проекта. Можно повысить подзадачу до более высокого уровня в иерархии, чтобы сделать ее задачей, переместить ее вверх в последовательности задач, а затем изменить ее предшественников.

Чтобы организовать задачи в WBS, выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

Измените задачи в WBS, как необходимо. Ниже в таблице показано, какие действия можно выполнить для изменения WBS.

Перемещение задачи в более раннее положение в WBS

Выберите задачу и в разделе Область действий щелкните Переместить задачу вверх.

При перемещении задачи все подзадачи перемещаются вместе с ней. Нумерация задач в WBS автоматически изменяется, когда задача перемещается.

Перемещение задачи в более позднее положение в WBS

Выберите задачу и в разделе Область действий щелкните Переместить задачу вниз.

Повышение подзадачи до более высокого уровня в иерархии задач

Выберите задачу и в разделе Область действий щелкните Уменьшить отступ.

Нумерация задачи с повышенным уровнем автоматически изменяется для новой позиции. Например, в шаблоне WBS с тремя родительскими задачами и одной подзадачей повышается уровень подзадачи 2.1. Задача с повышенным уровнем становится задачей 3, а бывшая задача 3 становится задачей 4.

Можно выбрать несколько задач для уменьшения отступа. Если щелкнуть Уменьшить отступ, выбранные задачи перемещаются на один уровень выше по сравнению с предыдущим уровнем.

Перемещение задачи на одну позицию вниз в WBS

Выберите задачу и в разделе Область действий щелкните Увеличить отступ.

Задача станет подзадачей предшествующей задачи. Например, в WBS есть две задачи. При понижении уровня задачи 2 она становится подзадачей задачи 1, и ее нумерация автоматически изменяется. Если у задачи 1 нет других подзадач, новой подзадаче присваивается номер 1.1. Если у задачи 1 имеются другие подзадачи, новая подзадача добавляется после других подзадач и ей присваивается новый номер.

Можно выбрать несколько задач для увеличения отступа. Если щелкнуть Увеличить отступ, выбранные задачи перемещаются на один уровень ниже по сравнению с предыдущим уровнем.

Выберите задачу и в разделе Область действий щелкните Удалить.

При удалении задачи, у которой нет подзадач, все ее подзадачи также удаляются. Кроме того, удаленная задача удаляется в качестве предшественника других задач, которые от нее зависели.

Если необходимо удалить родительскую задачу, но не требуется удалять одну или несколько ее подзадач, перед удалением родительской задачи выполните любое из следующих действий.

Повысьте уровень подзадачи до того же уровня, что и родительская задача.

Переместите подзадачи в другую родительскую задачу.

Поиск и разрешение конфликтов планирования в WBS

При вводе даты и часов для задач введенная информация может привести к конфликтам планирования. Можно вручную изменить усилие, даты и продолжительность задач для разрешения конфликтов планирования или можно разрешить системе автоматически их определять и исправлять. По умолчанию система настроена для определения и исправления конфликтов планирования при вводе информации для задач.

Для использования автоматического планирования для WBS выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

В форме Структурная декомпозиция работ проверьте, что помощь в автоматическом планировании включена. Если помощь в автоматическом планировании включена, отображается кнопка Автоматическое планирование включено в разделе Область действий.

Если помощь в автоматическом планировании не включена, щелкните Автоматическое планирование отключено. Название кнопки изменяется на Автоматическое планирование включено.

Чтобы исправить проблемы планирования, которые существовали до включения автоматического планирования, в разделе Область действий щелкните Исправить все несоответствия планирования.

Для отключения помощи в автоматическом планировании и ручного разрешения конфликтов планирования выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

В форме Структурная декомпозиция работ на панели операций нажмите кнопку Автоматическое планирование включено. При нажатии этой кнопки название кнопки изменяется на Автоматическое планирование отключено.

Измените значения в полях Усилия (часы), Число ресурсов, Начало, Готово и Продолжительность (дни) по необходимости.

Работа с ожидаемыми и фактическими доходом и затратами в WBS

Если выбрана категория проекта для задачи и для категории проекта указаны цена продажи и почасовые затраты, цена и суммы затрат автоматически добавляются в WBS для задачи. В представлении отслеживания затрат в WBS можно просмотреть сравнение между плановыми, ожидаемыми и фактическими доходами и расходами для задачи.

Чтобы сравнить запланированные, ожидаемые и фактические доходы и затраты для задачи, выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

На вкладке Задача в разделе Вид щелкните Представление отслеживания затрат.

Просмотрите статус доходов и затрат для каждой задачи. В следующей таблице представлены сведения, отображаемые в полях данного представления.

% понесенных затрат

Процент разнесенных затрат, разделенный на ожидаемые общие затраты по задаче. Общие ожидаемые затраты отображаются в поле Оценка при завершении.

Фактические затраты

Общие затраты по часам, разнесенным на дату задачи.

Издержки на завершение

Остальные затраты по часам для выполнения задачи. Значение автоматически рассчитывается как Оценка при завершении – фактические затраты.

Можно изменить значение этого поля. При этом значение в поле Оценка при завершении также обновляется.

Оценка при завершении

Ожидаемые общие затраты при завершении данной задачи рассчитываются по формуле фактические затраты на данный момент + стоимость завершения.

Плановые затраты

Ожидаемые общие затраты по задаче.

Прогнозируемое отклонение затрат

Оценочное отклонение стоимости этой задачи, рассчитанное по формуле оценка при завершении – запланированная стоимость. Отрицательное значение показывает, что оценочная стоимость превышает общие бюджетные затраты.

В поле справа от значений флажок указывает, что общее планируемое расхождение положительно или равно нулю. Символ предупреждения указывает, что предполагаемое расхождение является отрицательным и что ожидается, что стоимость часов для задачи превысит бюджетные затраты для задачи.

Работа с ожидаемыми и фактическими часами для задач в WBS

В форме WBS можно ввести ожидаемое количество часов, необходимых для выполнения задачи. При вводе ожидаемых часов для задач значения автоматически добавляются в поля в представлении отслеживания усилий в WBS.

Чтобы сравнить запланированные, ожидаемые и фактические часы, разнесенные для задачи, выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

На вкладке Задача в разделе Вид щелкните Представление отслеживания усилий.

Просмотрите состояние часов для задач. В следующей таблице представлены сведения, отображаемые в полях данного представления.

Процент выполнения

Процент фактических часов, разделенный на число оставшихся часов для выполнения задачи. Общие ожидаемые часы отображаются в поле Усилия при завершении.

Фактическое усилие (часы)

Общее количество часов в проводках, разнесенных на дату задачи.

Остающиеся усилия (часы)

Ожидаемое количество оставшихся часов, необходимых для выполнения задачи. Значение автоматически рассчитывается как Усилие при завершении – фактическое усилие.

Можно изменить значение этого поля. При этом количество часов в поле Усилия при завершении также изменяется.

Усилия при завершении

Ожидаемое общее количество часов по данной задаче, когда она завершена, рассчитывается по формуле фактическое количество часов на сегодняшний день + оставшиеся усилия.

Запланированные усилия

Ожидаемые общие часы по задаче.

Прогнозируемое отклонение усилий

Оценочное отклонение по данной задаче, рассчитанное по формуле усилие при завершении – запланированное усилие. Отрицательное значение показывает, что ожидаемое количество часов превышает общие бюджетные часы.

В поле справа от значений флажок указывает, что общее планируемое расхождение положительно или равно нулю. Символ предупреждения указывает, что предполагаемое расхождение является отрицательным и что ожидается, что количество часов для задачи превысит бюджетные часы для задачи.

Работа с WBS в Microsoft Project

Можно создать связь между проектом в Microsoft Dynamics AX и соответствующим проектом в Microsoft Project. Затем можно использовать Microsoft Project для создания или обновления WBS проекта и создать шаблон WBS, который можно использовать в Microsoft Dynamics AX.

Можно также использовать Microsoft Project для замены структурной декомпозиции работ проекта, который ведется в Microsoft Dynamics AX. Дополнительные сведения см. в разделе Создание или обновление проекта с помощью Microsoft Project.

Для обновления WBS для проекта, который интегрирован в Microsoft Project, выполните следующие действия.

Щелкните Управление и учет по проектам > Обычный > Проекты > Все проекты. Открытие проекта. На панели «Действия» на вкладке План в группе Мероприятия щелкните Структурная декомпозиция работ.

В форме Структурная декомпозиция работ в области действий на вкладке СДР щелкните Открыть в Microsoft Project.

Измените WBS при необходимости. При закрытии WBS изменения также сохраняются в Microsoft Project.

Техническая информация для системных администраторов

При отсутствии доступа к страницам, которые необходимы для выполнения этой задачи, свяжитесь с системным администратором и предоставьте сведения, представленные в следующей таблице.

Конфигурационные ключи

Для этой задачи конфигурационный ключ не требуется.

Роли безопасности

Для создания WBS необходимо быть членом роли безопасности, включающей полномочия Ведение мастера мероприятия по проекту (ProjActivityMasterMaintain).

Источник