Заблаговременная оплата по кодам накладных расходов: технический документ

Этот технический документ является частью колонки "Вести с передовой". В нем описываются рекомендации по определению структуры кода накладных расходов организации для системы управления проектами или централизованного расписания.

Чтобы скачать версию этого документа в формате Word, перейдите на страницу Заблаговременная оплата по кодам накладных расходов.

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

Заблаговременная оплата по кодам накладных расходов

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

Просите меньше, а не больше

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

Не будем обманывать друг друга. Никто этого делать не будет. Пользователь скорее выберет первый вариант, который покажется достаточно близким. В случае отсутствия такой возможности все время в конечном итоге уйдет на "999:Разное".

Потому создайте простой список. В идеале для него вообще не нужна прокрутка, он должен умещаться на одном экране или прокручиваться одним щелчком мыши. Это возможно, когда выбор состоит максимум из 20–30 возможных вариантов. В этом случае меньше значит больше.

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

Не спрашивайте о том, что вам уже известно

Я видел много структур кодов расходов, где существуют идентичные коды для каждого отдела или проекта. Однако если пользователей попросили выбрать проект и мы создаем запись, например для собраний, то я знаю, что должна быть позиция "собрания по этому проекту". Так зачем засорять список расходов разными элементами собрания? То же самое касается и отделов. Если имеется список сотрудников по отделам, то мы уже знаем, в каком отделе они состоят. Зачем засорять список расходов такими элементами, как "Собрание отдела продаж", "Собрание технического отдела" и "Собрание отдела маркетинга". Просто создайте один элемент с именем "Собрания", и мы, исходя из отдела и проекта сотрудника, сможет узнать, какое это было собрание.

Твердо решитесь углубить детализацию

Выбор соответствующего уровня детализации для проекта и расписания — распространенная проблема. Подумайте о желаемом уровне управления. При этом учитывайте следующие аспекты: 1) Большее значение должны иметь сами данные, нежели время, потраченное на их сбор. Если вы проведете весь день, составляя отчет о своем дне, сможете ли вы действительно что-то сделать? 2) Работайте на том уровне, на котором вы готовы принимать решения. 3) Чем сложнее структура для ввода, тем меньше вероятность получения точных данных. 4) По возможности распределите работу так, чтобы все выполняли ее на одном уровне. Следите, чтобы не получилось так, что вы руководите одной группой, работающей над задачами продолжительностью 10 минут, и другой, занимающейся задачами в 3 дня. Многие считают, что писать отчет на 3–5 строк по заданному дню достаточно.

Обусловливайте данные

Некоторые люди заставляют конечного пользователя отвечать на один и тот же вопрос. Например, мы уже видели системы со столбцом "Исследования и разработки" — это означает, что эти расходы подлежат или не подлежат налоговой льготе на затраты по НИОКР. Однако мы должны связать соответствие с самой задачей, а не с каждой строкой расписания всех пользователей. Тем более, что было бы, если бы одни пользователи считали, что расходы подлежат льготе, а другие — наоборот? Этот вероятный сценарий также подходит для таких примеров, как "Подлежат разработке в отделе исследований и разработки" и "Не подлежат разработке в отделе исследований и разработки". Это удваивает количество кодов накладных расходов без возвращаемого значения. Просто попросите одного из сотрудников отдела исследований и разработки отметить значения в раскрывающемся списке как подлежащие или не подлежащие, и вам не придется постоянно спрашивать об этом у конечных пользователей.

Иерархия

В хороших проектах и централизованных расписаниях данные отображаются в виде иерархии. Если имеется множество возможных вариантов, то построение иерархии может существенно упростить восприятие данных. Разместите на каждом уровне по 5–10 элементов для выбора. Не стоит стремиться создать десятки уровней. Иерархия на 3–4 уровня обычно вмещает достаточно вариантов. В конце концов, 10 элементов на каждом уровне в четырехуровневой системе — это 10 000 возможных вариантов. Разве для вашего проекта нужна более сложная структура?

Показывайте меньше

Чем меньше вопросов и вариантов ответов вы предоставите пользователям, тем лучше. Если есть вопрос, на который вы можете ответить в фоновом режиме, тогда не стоит задавать его пользователям в расписании. Цель — собрать не побольше данных, а наиболее точные данные, и у вас это лучше получится, если вы избавите конечных пользователей от данных, вопросов и вариантов, которые ничего для них не значат.

Что делать с этими данными?

Руководители среднего звена часто говорят мне, что им нужны более подробные данные, чем я предлагаю, на что у меня всегда один ответ: "Что вы будете делать с этими данными?" Сбор данных для расписания на основе задачи выполняется с целью создания более эффективных бизнес-решений, потому я часто спрашиваю этих руководителей, какое именно бизнес-решение они не могут принять без более подробных данных. Если вы посмотрите на данные с этой точки зрения, вы поймете, что, вероятно, детализация чрезмерна. Возможно, достаточно знать общее количество часов, затраченных на собрания, перемещения или задачи по накладным расходам, не вдаваясь в подробности каждой из этих задач.

Копайте глубже, но только если нужно

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

Сохраняйте порядок

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

Заключение

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

Об авторе

Крис Вандерлуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, а также партнер Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерлуису по адресу электронной почты chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерлуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×