Top down bottom up в чем разница
Как оценить объем крупного рынка
Важная часть любого product discovery – определить объем рынка, который ваш продукт способен занять, и доход, который продукт может привести.
Сегодня я расскажу о Bottom Up и Top Down методах анализа рынка, с помощью которых можно рассчитать реально достижимый рынок.
Top Down анализ – это расчет общего рынка с определением доли вашего продукта с нем.
Например, мы хотим продавать свежие фрукты с доставкой в стране. Нужно определить, насколько велик рынок для такого бизнеса.
Мы выяснили, что один россиянин тратит в среднем 600 рублей в месяц на фрукты, т.е. 7200 рублей в год. При этом ежегодно россиянами тратится примерно 3.5 трлн. рублей на фрукты.
Понятно, что не всем удобна опция с доставкой. На самом деле, запускать этот бизнес имеет смысл только в крупных городах – Москва и Питер. Мы знаем, что житель большого города тратит в среднем 1500 руб. в месяц на фрукты, т.е. 18 000 руб. в год. Ежегодно в двух городах тратится примерно 300 млрд. руб. в год.
Не все жители крупных городов пользуются доставкой, таковых всего 50%. Это снижает оценку до 150 млрд.руб. Супермаркеты всегда будут иметь за собой большую долю рынка, поэтому мы предположим, что только 20% людей будет заказывать фрукты с доставкой на дом. Таким образом, наша оценка составляет 30 млрд. рублей.
Я привел общий пример, где не учел многого. Для достижения максимально точного размера рынка нужно вести более строгую аналитику. Упустите важные предположения – переоцените свой ТАМ.
Вообще, Top Down анализ несложен, но он может ввести в заблуждение. Он не даст нам ответы на вопрос, сможем ли мы действительно выйти на этот рынок и чего нам это будет стоить. Хорошая новость заключается в том, что ответ на эти вопросы дает нам Bottom Up анализ.
Два подхода к планированию продаж
Два подхода к планированию продаж
Итак, предположим, мы планируем продажи на год. Годовое планирование самое важное. Существуют два действенных подхода. Первый называется Bottom-Up, что в переводе с английского означает снизу вверх. Его суть выражается в следующем: сколько мы сможем заработать при имеющихся ресурсах, с тем, что имеем сейчас. При текущем количестве сотрудников, при их настоящем уровне, при текущем ассортименте, имеющейся на данный момент проходимости и всем остальном. Покрутив эффективность каждого элемента в отдельности, сколько мы сможем заработать? Альтернативный подход называется Top-Down – сверху вниз. Сначала мы определяем цифру, которую хотим заработать, например 3 миллиона. Дальше – что нужно сделать, какие ресурсы (денежные, финансовые, людские, товарные) надо подтянуть, чтобы выполнить этот план. И раз уж мы говорим об удвоении продаж, зафиксируйте ваш текущий оборот и поставьте себе целью удвоить его через год. Хотя с этой задачей можно справиться и за меньший срок.
Начнем с Bottom-Up. Обращаемся к срезам, о которых говорили в предыдущей главе. Заполняем таблицы, анализируем. Чем больше различных ракурсов, тем лучше.
Товары, рекламные носители, сотрудники, поставщики – старайтесь оценить все. Бывают региональные срезы и срезы по каналам сбыта. Вы можете добавить к анализируемым данным показатели интернет-магазина. После того как ваши таблицы готовы, вы собираете группу из трех-четырех ключевых сотрудников. В нее должны войти вы сами, сотрудник, ведающий финансами (бухгалтер или финансовый директор), руководитель продавцов, главный администратор (исполнительный директор). То есть те люди, которые влияют на принятие решений, могут что-то изменить и исполняют контрольную функцию. Самих продавцов приглашать в эту группу не надо! Это критическая ошибка.
Следующий шаг – вместе с ними вы рассматриваете конкретные показатели за какой-либо месяц, пусть это будет январь. Смотрим в срезе строку, к примеру «мобильные телефоны», проверяем показатели по ней: оборот, прибыль, количество проданной продукции, возможно, детализация по сортам. И задаем себе и группе вопрос: а что у нас было в январе прошлого года? А в прошлом январе мы продали телефонов на 30 000. Понятно, что январь вообще не слишком удачный месяц для продаж. И мы учитываем это. Смотрим, какие мероприятия у нас проходили. Предположим, была реклама по радио или спецакция, и за счет этого мы увеличили свой объем продаж. Затем мы решаем, сколько мы хотим продать мобильных телефонов в этом январе, учитывая, что у нас уже запланирована специальная акция. И так далее. А еще у нас хороший новый продавец. С его помощью мы продадим больше. Итак, год назад было 30 000, а сейчас мы планируем продать в январе на 40 000. Обязательно надо посчитать, сколько это будет товара в количественном выражении. Тут мы подходим к плану закупок. Но это отдельная тема, сейчас мы ее не касаемся. И так с группой надо пройтись по всем товарам. И в итоге получится общая цифра за январь, с разбивкой по товарным группам.
Конечно, и в этом случае можно ошибиться. Но погрешность будет меньше. Именно за счет декомпозиции. То же самое следует проделать и с планом по продавцам. Изучаете соответствующий срез, смотрите, сколько у вас было продавцов в прошлом году, кто уволился, кто остался, кто пришел недавно и каково время разгона для него. Заполняете отдельно планы по продавцам и получаете общую цифру. Итоговая раскладка содержит данные по тому, на какую сумму должен продать каждый сотрудник в январе, феврале и т. д. Опять же все зависит от вашей терпеливости. Такое планирование – очень кропотливый труд. Если нет желания рассматривать каждый месяц отдельно, ограничьтесь кварталами. Но планирование по месяцам лучше, так как позволяет учитывать влияние различных мини-факторов. Распродажи, праздники, выездные фестивали, что-то еще. Многое может влиять на ваши продажи. Декомпозируя, вы все это учитываете. Суммируем месячные планы и получаем итоговую цифру за год.
Предположим, вы запланировали 1 200 000 по продуктовому срезу. Затем вы смотрите на работу продавцов, закладываетесь на их обучение, чтобы эффективность работы возросла. Предположим, их эффективность за квартал будет расти на 5%, это тоже надо заложить в план. Получаете следующую цифру – 1 260 000. По поставщикам – смотрите на стоимость закупки, какие-то особые условия, добавляете нового поставщика.
И вот тут можно совместить подходы и сделать вторую итерацию, используя Top-Down – сверху вниз. Вы ставите себе планку – а я хочу 2 000 000. Хочу, и все! Но чтобы получить эти 2 000 000, вы должны что-то добавить на нижнем уровне. Понимаете? Это значит, что вы будете вводить новые ассортиментные позиции. Изобретать новые специальные предложения и акции, пакетные и подарочные решения, о которых мы тоже поговорим. Возможно, для достижения нужной цифры плана вам потребуется открыть новую точку или нанять сотрудника. Вы смотрите время разгона прошлой точки и учитываете это в плане. Прогнозируете, каким будет оборот по новой точке. То есть подход другой – не от того, что есть сейчас и что будет, а от того, что вы хотите получить и что для этого нужно сделать.
Но чтобы такой план был достигнут, по каждой ячейке нужно прописать еще два листка. Первый называется «Ресурсы», второй – «Действия». В них тоже должна быть разбивка по месяцам. Вы решаете, что можно сделать в январе. Пусть будет промоакция. Соответственно в планах действий вы пишете: «Раз работать акцию для января, чтобы поднять продажи таких-то цветов». А что нужно для того, чтобы разработать и провести акцию? Нужны ресурсы. Нам может не хватить компетенций для подготовки акции, значит, нужен сторонний специалист – маркетолог. Для его привлечения нужны деньги. Пишете – сколько. Или вы решили, что пора запускать интернет-магазин. Соответственно в список действий на следующий год вы вносите: «Разработка интернет-магазина». И обязательно декомпозируете: найти подрядчика в январе, чтобы в марте интернет-магазин уже работал. А в плане продаж вы учитываете новый канал продаж, прикидываете в среднем его разгон и что уже к апрелю он будет давать вот такие цифры.
План действий и ресурсов дает нам недостающий остаток: 700 000, к примеру. И вам надо понимать, как вы эти 700 000 сможете заработать путем своих действий и акций. И надо достичь баланса, так чтобы все цифры сошлись. Сначала это очень сложно делать. Потому что непонятно, какого эффекта ждать от того или иного мероприятия, будет ли результативна выставка, если вам еще не приходилось в ней участвовать и никаких замеров нет. Поэтому мы советуем начинать не с года, а хотя бы с квартала. И да, поначалу вы будете ошибаться. Но с каждой новой итерацией плана ваша ошибка, погрешность, будет все меньше и меньше. А самое главное – это то, что, замеряя эффективность каждого мероприятия, каждой акции, каждого рекламного носителя, вы впоследствии точно сможете сказать, какой эффект они дают. Что билборд с освещением и стрелкой дает нам 10 звонков в день. А если магазин при текущей конверсии в 20% будет получать плюсом 10 звонков в день, то это 2 покупки с таким-то средним чеком, понимаете? Еще раз повторюсь, это сложно. Но есть такая фраза: «Fail to plan = Plan to fail», что в переводе с английского значит: «Провалить план означает планировать провал». Потому что без планирования вы не движетесь. А точнее, вы не понимаете, как вы это делаете. Помните про черный ящик?
Если вы не планируете свою работу, не предпринимаете никаких стратегических действий и инициатив – ваш бизнес не развивается. Если вы создаете сайт просто потому, что сайт завел ваш приятель и это не является частью плана по достижению конкретной цифры, то вряд ли он будет работать на прибыль. И не стоит рассчитывать на перемены к лучшему ни сейчас, ни через двадцать лет. Изменения могут произойти разве что в худшую сторону, если мы не будем планировать свое развитие.
Возвращаясь к системе планирования, начните с методики Bottom-Up. Напишите цифры снизу вверх – сколько вы сумеете заработать при текущем развитии, при текущей динамике, с текущими ресурсами. Смело удваивайте эту цифру. И оцените, что из имеющихся ресурсов вам надо подтянуть и какие действия предпринять, чтобы получить это удвоение.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
1.3. Суть системного подхода
1.3. Суть системного подхода Говорят, истина лежит между двумя противоположными мнениями. Неверно! Между ними лежит проблема. Иоганн Вольфганг Гёте Потребность в использовании системного подхода обострилась в связи с необходимостью управления объектами, имеющими
Ключевые технологии и стандарты продаж по этапам активных продаж
Ключевые технологии и стандарты продаж по этапам активных продаж Посмотрим, какие документы и в какой последовательности используются на различных этапах работы отдела продаж.1. Цели и планы продажПредположим, у нас есть бизнес, полностью готовый к старту продаж. Есть
1.4 Кризис классического подхода
1.4 Кризис классического подхода Первоначальным моим намерением было применение процедурных правил.Суть метода сводится к графическому описанию сложившейся технологии и поиску «белых пятен» в ней. Процедурные правила описывают не только основную технологическую
Усвоение позитивного подхода
Усвоение позитивного подхода Очень важно понять, что такое стресс, но научиться управлять им гораздо важнее. Даже если вам известно, что нужно предпринять, чтобы победить стресс, это вовсе не означает, что вы начнете действовать, особенно до тех пор пока эмоции влияют на
Усвоение позитивного подхода
Усвоение позитивного подхода Если обстоятельства берут над вами вверх, вероятно, вы еще не поняли, что несете полную ответственность за свое здоровье. От того, умеете ли вы распознавать и оценивать ситуацию, зависит дальнейшее развитие стресса. В ваших силах избежать
Находим дыры в системе продаж. Куда утекают деньги? (Аудит системы продаж)
Находим дыры в системе продаж. Куда утекают деньги? (Аудит системы продаж) Прежде чем внедрять в отдел продаж системы по выстраиванию бизнес-процессов, необходимо прояснить два вопроса:1. Что мешает компании развиваться?2. Какие слабые места есть в системе прямо
58. ЭТАПЫ И ПРИНЦИПЫ СИСТЕМНОГО ПОДХОДА В УПРАВЛЕНИИ. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОГО ПОДХОДА
58. ЭТАПЫ И ПРИНЦИПЫ СИСТЕМНОГО ПОДХОДА В УПРАВЛЕНИИ. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОГО ПОДХОДА Системный подход в управлении рассматривает управленческую деятельность как систему, т. е. как совокупность элементов, взаимодействующих между собой во времени и пространстве.
Два подхода к целеполаганию
Сверху вниз или снизу вверх
Эта статья входит в нашу коллекцию «Из окопов». В нем обсуждаются управление проектами, управление портфелями и управление задачами, а также сравниваются связанные с ними методы управления сверху вниз и снизу вверх.
Чтобы скачать версию Word в этой статье, см. в статье Top-down или bottom-up: white paper (Project Server 2010).
Дополнительные статьи см. в статье «Из окопов».
Сверху или снизу вверх?
Те из нас, кто работал в ИТ на протяжении многих лет, как правило, видят вещи с технической точки зрения, а иногда это не служит нам хорошо. Если мы посмотрим на данные управления портфелями, Project управления и управления задачами, это может выглядеть очень похоже. У меня есть поле ID, поле описания и дата начала и окончания во всех трех. Привязка всех трех из них должна быть естественной.
Давайте рассмотрим эти три понятия по одному. Их сходство легко увидеть, но существуют фундаментальные различия в трех перспективах.
Управление портфелем — подход сверху вниз
Люди могут означать много разных вещей под «управление портфелем», но наиболее распространенным значением, вероятно, является выбор проектов и приоритеты. Принципы в конечном счете затрагивают всех сотрудников организации, но этот процесс очень интересен для руководителей старшего звена. Управление начинается с определенных ограничений, таких как общий доступный бюджет и необходимость ответить на вопрос: «Что мы можем и должны сделать с таким объемом денег?» Если процесс управления портфелем достаточно зрелый, этот анализ может включать не только новые идеи, но и существующие проекты.
Чтобы создать процесс выбора портфеля и определения приоритетов, руководство должно противостоять тем, какие бизнес-критерии годят компанию, и заранее согласовать метрики, которые будут учитываться при поиске новых и существующих проектов. Должна ли доходность инвестиций быть ключевым показателем? Возможно, нам следует рассмотреть вопрос о влиянии на удовлетворенность клиентов, удержание персонала или соответствие стратегическим целям. Какие бы ключевые показатели ни были, руководство должно взвесить каждую инициативу проекта с учетом того, как этот проект может продвигать эти цели и как каждый проект сравнивает с альтернативными инициативами, на которые можно было бы потратить деньги.
Это очень аналитический процесс, даже если он сделан в голове. Это, конечно, очень аналитически, когда вы используете программное обеспечение управления портфелем проектов. Даже после того, как анализ программного обеспечения поступает в отчет или представление, практически всегда существует некоторый надзор на уровне управления, где принимается окончательное решение о приоритетах. Когда это будет завершено, окончательные результаты должны быть переданы тем, кто будет делать управление проектами каждого из проектов. Эти решения будут иметь последствия для финансирования одних проектов, а не для финансирования других, для того, чтобы сделать ресурсы более приоритетными для одних проектов, а не для других, а для продвижения расписания некоторых проектов и отсрочки других.
Project Управление — сверху вниз и снизу вверх
После утверждения проекта он переходит в другую область. Теперь в центре внимания более классическое представление планирования проектов. Теперь мы должны фактически создать то, что мы описали в нашем бизнес-обоснование, прежде чем он был утвержден.
Руководитель проекта начинает мыслить с точки зрения области проектов и ее результатов. Руководитель проекта знает конечный продукт, который необходимо создать, будь то программное обеспечение или здание, готовое к заполняемости. Они могут придумать основные этапы этого проекта и создать структуру сбоя работы.
Разработан критический путь логических действий, необходимых для завершения проекта. Руководитель проекта также знает, что он или она будут нести ответственность за график, который производится, поэтому он или она консультируется с рядом экспертов по предметам в проекте. Руководитель проекта создает представление проекта снизу вверх, просматривая задачу по задачам и обобщая эти задачи до этапов проекта и, в конечном счете, самого проекта. В это время руководитель проекта может также начать деление ресурсов по навыкам, по отделу или даже по имени. Эти ресурсы могут иметь затраты, связанные с ними. В результате вычисления продолжительности задач, необходимых ресурсов и их показателей мы оцениваем проект снизу вверх.
Пока все в порядке.
Но когда мы смотрим на даун-подход процесса выбора портфеля проектов, это тоже было затратой. Фактически, сметная стоимость проекта была частью бизнес-обоснования, которое руководство рассматривало при его одобрении. Если мы сейчас только что выполним нижнюю оценку проекта с помощью объединенных знаний экспертов по предметным темам, что они использовали при выборе проекта в исполнительном пакете?
Хороший вопрос. В некоторых организациях проекту будет дана примерная оценка от отдела проектов для создания бизнес-обоснования проекта. В других организациях перед рассмотрением проекта в процессе портфеля создается полная оценка снизу вверх. Проблема обоих этих подходов заключается в том, что они принимают усилия. Полная оценка может занять много усилий, но проект еще не получил одобрения для финансирования любых усилий. Так что во многих организациях кто-то из руководства просто делает предположение о том, какие будут затраты на этот проект.
Таким образом, процесс выглядит все интегрированным, но может быть немного catch-22 здесь. В первую очередь, работа, затраченная на смету или выбор проекта, чтобы иметь возможность тратить время на проект?
Кроме того, что произойдет, если снизу вверх оценка не соответствует оценке процесса выбора портфеля? Если оценка меньше, то, вероятно, нет проблем, но если работа не может быть завершена в то время или бюджет, оцененный людьми выбора портфеля, существует конфликт.
Вы можете подумать, что естественным является повторное перенаправление высшего руководства и просто обсуждение проблемы, но существует множество ситуаций, когда это не так просто, как кажется.
Во-первых, комитет по выбору портфеля редко является штатом управления проектами. Старшие сотрудники управления проектами почти всегда включаются в состав комитета по выбору портфеля, но сама группа обычно является очень старшими руководителями, которым сложно организовать время, чтобы все были вместе. Во-вторых, комитет по отбору может встречаться нерегулярно, поэтому собрать их вместе, чтобы обсудить все последствия несоответствия затрат для одного проекта по сравнению с оценкой, может быть большой проблемой. Наконец, существуют некоторые корпоративные культуры, в которых не будет продвижения по карьере, чтобы довести до старшего руководителя новости о том, что их догадки совершенно неправильно о том, что соответствующий график и бюджет для этого проекта.
Управление задачами — подход снизу вверх
Когда мы думаем об управлении задачами, мы склонны думать очень оперативно, и это чаще всего приводит нас к нашей повседневной повестке дня и продукту, как Outlook.
Теперь мы работаем на уровне отдельного или небольшого члена команды. Мы не видим задачи в контексте. Мы видим те вещи, которые мы обязались или, возможно, те вещи, которые мы попросили члена группы совершить. Это вообще не аналитическое представление. Есть задачи, которые нужно выполнять, и человек пообещал их выполнять.
По своей сути управление задачами очень просто. Вы выполните задачу, и когда вы завершите, скажите человеку, который дал вам задачу, чтобы она была завершена. Все функции для этого уже в Outlook.
Озорная ситуация с аналогичными данными
Есть поговорка: «Если она выглядит как утка и шарлатаны, как утка, она должна быть уткой». Это верно для уток, но это не всегда верно для данных, основанных на задачах.
Рассмотрим три уровня данных, ориентированных на проект:
На уровне портфеля у нас есть проект и, возможно, этапы ниже этого проекта. Сведения о фазе могут иметь номер кода, описание, продолжительность, дату начала и дату окончания.
На уровне проекта у нас есть проект и задачи ниже проекта. В сведениях о задачах может быть номер кода, описание, продолжительность, дата начала и дата окончания.
На этом уровне управления задачами у нас есть задача, а сведения о задачах могут иметь номер кода, описание, продолжительность, дату начала и дату окончания.
Они, конечно, выглядят одинаково, но на самом деле перспектива данных заставляет каждую из этих довольно распространенных записей служить совершенно другой цели.
Меня часто спрашивают: «Могу ли я переместить данные из представления портфеля в представление проекта в Outlook и обратно».
Краткий ответ на этот вопрос : «Да».
Но в нашей фирме мы говорим себе мантру, когда даем технические советы: «Не говорите мне, как это сделать, скажите мне, почему вы должны это сделать».
Чтобы сделать точку, представьте этот пример. Мы делаем полностью интегрированную среду. В верхней части шкалы мы имеем список проектов, организованных по портфолио. Мы не только выбираем эти проекты, но и интегрируемся еще дальше, следуя за ними после их активации в живых проектах из системы EPM. Для этого мы используем уже имеющиеся у нас функции для перемещения определений проектов и этапов с стороны портфолио нашей интегрированной системы в проектную сторону системы. Данные выглядят одинаково.
В нашей корпоративной системе управления проектами мы теперь делаем более подробное определение, используя исходные этапы из определения портфеля, которое было отжато сверху вниз. Это позволяет обновлять эту сводку в системе портфелей при обновлении проектов. Мы делаем много задач и назначаем много ресурсов. Теперь мы делаем анализ уровня ресурсов, чтобы определить нашу емкость во многих проектах.
Мы используем назначения ресурсов для нажатия данных задач и назначений каждому пользователю в качестве Outlook задачи или события календаря. Пользователям больше не нужно ходить в «систему управления проектами». Теперь они могут видеть свои данные в своей повседневной повестке дня. Данные выглядят так же, как и в списке проектов, и связаны далее вверх по течению с представлением портфеля.
Прогресс от этих задач и доступности от Outlook возвращается от человека к системе управления проектами вместе с оценками, когда эта работа будет завершена. Данные выглядят так же, как и в двух других системах, поэтому перемещение данных относительно легко.
Создание такой системы технически очень просто с помощью средств, доступных нам сегодня, а также немного конфигурации и разработки. И это будет прекрасно демонстрироваться.
Нам регулярно запросят именно этот тип структуры. Но, несмотря на то, что мы можем это сделать, должны ли мы?
Imagine, что на уровне задач человек принимает утреннее отключение для экстренного посещения стоматолога и обновляет свою Outlook, что она не будет доступна сегодня утром. Это плохая новость для него, но волновые эффекты для проекта могут быть массовыми. Теперь проектная система подсчитывает, что задача, которая должна была быть выполнена сегодня утром, не будет выполнена сегодня; она будет завершена только в середине дня завтра. Он послусно смотрит на критический путь и все задачи вниз по течению от этого и толкает их вперед на четыре часа. Возможно, пострадали сотни задач. Результатом может быть нажатие даты окончания проекта через пол дня. Другие проекты также затронуты, так как другие люди, работающие над этим проектом, теперь должны переустроить свои задачи, а само представление портфеля выдвинет несколько пикселей вперед.
Если представить себе это в режиме реального времени, проблема увеличивается. Сотни или тысячи людей в течение дня внося изменения, а представление EPM, представление выравнивания ресурсов и представление портфолио анимировать взад и вперед с эффектами.
На самом деле этого не происходит. Прежде всего, незадачливая стоматологическая пациентка вернется на свой пост в 12:00 и может просто работать несколько часов спустя сегодня вечером, чтобы убедиться, что этот критический путь догнал и все будет вернуться в нужное русло в первой половине дня.
Кроме того, несмотря на то, что данные выглядят одинаково, они никогда не интегрируются таким образом из-за именно этого эффекта.
Контекст данных — вопросы перспективы
Когда мы смотрим на данные, контекст данных имеет решающее значение. Данные, которые могут выглядеть одинаково из схемы записи к записи, используются для очень разных целей в зависимости от перспективы приложения.
В верхней части портфеля мы делаем стратегические решения о том, куда помещаем наши ресурсы для максимальной отдачи от инвестиций. Мы можем сделать выбор, который руководитель проекта не сделает. В моей организации мы иногда выбирали проекты, которые полностью не имеют нашего существующего набора навыков, зная, что мы были бы крайне неэффективными при их выполнении, но делали это, потому что мы хотели улучшить эти навыки. Отдача от инвестиций не была эффективной установкой, она была обучена установщикам. Это аналитическое представление.
В тактическом представлении проекта мы делаем оперативные решения о том, где получить лучшую пропускную способность нашего персонала и как можно быстрее и эффективнее завершить наши проекты. Глаз руководителя проекта всегда в будущее. То, что происходило в прошлом, интересует только руководителя проекта, поскольку оно улучшает его представление о будущем. Это также очень аналитическое представление.
В представлении управления задачами, как в повестке дня, мы не аналитически. Повестка дня — это система обязательств. Мы обещаем себе или другим, что мы будем делать определенные вещи в определенное время. Это может соответствовать аналитическому представлению. А может и нет.
Смешивание этих точек зрения и контекстов без понимания влияния может привести к хаосу.
Сверху или снизу вверх?
Существует, как обычно, нет правильного ответа. Некоторые аспекты системы управления проектами действительно должны быть снизу вверх. В конце концов, это люди, которые будут создавать все, что ваш проект о. Но некоторые решения принимаются и должны приниматься с самого верха и, по необходимости, сверху вниз.
Если вы держите различия для каждого уровня парадигмы управления проектами, становится понятнее, следует ли действительно интегрировать некоторые из этих систем или нет. Если процесс и мышление одного уровня не имеют прямой выгоды, будучи полностью интегрированы с другого уровня, то интеграция не является лучшей игрой. Важно узнать, как такая интеграция будет работать в реальном контексте и обеспечивает ли частота и детализация с одного уровня какое-либо значение для другого.
Если, например, руководящий комитет собирается только один раз в квартал, чтобы принимать решения о том, какие проекты двигаться вперед, а какие нет, то какая польза для обновления их представления каждый день, каждую неделю или даже каждый месяц?
Действительно ли алгоритм управления ресурсами для управления проектами предприятия должен видеть назначение отдельного лица или достаточно знать примерную доступность этого человека?
И тем не менее, если бы мы могли отправить назначение на повестку дня или на экран расметки конкретного человека напрямую, это бы сэкономит им по несколько минут каждый день, чтобы перейти в другую систему и интерфейс, чтобы увидеть те же данные?
Таким образом, сверху вниз право в некоторых обстоятельствах и снизу вверх право в других. Вы должны посмотреть на свою собственную ситуацию, чтобы увидеть, где интеграция этих средств и концепций может вернуть правильные дивиденды, прежде чем их совместить.
Об авторе
Крис Вандерслуис является президентом и основателем канадской компании HMS Software, сертифицированного партнером Microsoft. Он имеет степень по экономике в Университете McGill и более 30-летний опыт автоматизации систем управления проектами. Он является давним членом Института управления Project (PMI) и помог найти главы Группы Microsoft Project пользователей (MPUG) в Монреале, Торонто и Квебеке. Публикации, для которых Крис написал: Fortune, Heavy Construction News, Computing Canada magazine и PMI’s PMNetwork, и он является регулярным обозревателем для Project Times. Он преподает Project управления в Университете McGill и часто выступает на функциях ассоциации управления проектами в Северной Америке и по всему миру. HMS Software является издателем системы хронометража проекта TimeControl и с 1995 Microsoft Project партнером по решению.