Заблаговременная оплата по кодам расходов
Эта статья является частью нашей коллекции "Из окопов". В нем описаны рекомендации по определению структуры кода оплаты вашей организации для системы управления проектами или системы расписания.
Чтобы скачать Word версию этой статьи, см. раздел Зарядка вперед по кодам оплаты.
Дополнительные статьи см. в технических документах "Из окопов".
Заблаговременная оплата по кодам расходов
Меня часто просят помочь организациям определить структуру кода оплаты либо для системы управления проектами, либо для системы расписания. Хотя это правда, что каждая организация отличается, и разные потребности приводят к разным типам расходов, существуют некоторые распространенные методики, которые мы нашли на протяжении многих лет, которые являются универсальными.
Спрашивайте меньше, а не больше
Никто не любит бюрократию, поэтому чем сложнее структура кода заряда вы делаете, тем меньше вероятность того, что люди делают точные отчеты. Представьте себе, например, что я составлю список из 10 000 кодов оплаты в длинном плоском списке на выбор. Возможно, вам придется прокручивать в течение часа, изучая каждую возможную запись в раскрывающемся списке, прежде чем найти правильный выбор для этого конкретного расписания или обновления проекта. Затем вам нужно прокрутить остальную часть списка, чтобы убедиться, что вы не нашли что-то, что было не просто немного более точным.
Давайте не будем глупыми. Никто не будет этого делать. Они возьмут первую запись, которая кажется достаточно близкой, и выберут, что. В противном случае все часы в конечном итоге будут отвечать "999:Прочее".
Так что сделайте свой список простым. В идеале он не должен требовать прокрутки вообще, но должен быть виден на одном экране или, возможно, одним щелчком мыши. Это означает, что вы выбираете только из 20-30 возможных вариантов максимум. В этом случае меньше больше.
Если руководство намерено получить гораздо больше деталей, напомните ему, что лучше получить больше точности и меньше детализации, чем больше детализации и меньше точности.
Не спрашивайте, что вы уже знаете
Я видел много структур кода оплаты, в которых существует одинаковый код оплаты для каждого отдела или каждого проекта. Тем не менее, если людей уже просят выбрать проект, и мы делаем запись для собраний, например, то я знаю, что строка должна быть "собрания по этому проекту", так зачем загрязнять список расходов несколькими элементами собрания? Та же логика и в отделах. Если у нас есть список сотрудников, принадлежащих к каждому отделу, то мы уже знаем, в каком отделе они находятся. Зачем загрязнять список расходов с помощью "Собрание отдела продаж", "Собрание технического отдела" и "Собрание отдела маркетинга". Просто сделайте один пункт под названием "Собрание", и мы можем вывести из отдела сотрудника и проекта, для чего было собрание.
Разрешение для более эффективного разрешения
Выбор подходящего уровня разрешения для проекта и расписания является распространенной задачей. Подумайте о том, на каком уровне вы хотите управлять вещами с такими условиями: 1) Данные должны быть более ценными, чем в то время, чтобы их собрать, поэтому если вы тратите весь день отчетности за свой день, как вы на самом деле будете делать что-то? 2) Работайте на уровне, на который вы готовы принимать решения. 3) Чем сложнее ввести, тем меньше вероятность получения точных данных. 4) По возможности заставить всех работать на одном уровне разрешения, чтобы вы не управляли одной группой в задачах длительностью 10 минут, а другой — в задачах длительностью 3 дня. Для многих людей возможность сообщить 3-5 строк подробностей за данный день является большим количеством деталей.
Настройка данных
Некоторые пользователи снова и снова отвечают на одни и те же вопросы. Например, мы видели системы со столбцом "R&D", что означает, что эта плата является или не является платежом, соответствующим налоговому кредиту R&D. Но мы должны иметь возможность связать право на саму задачу, а не каждую строку расписания каждого человека. Кроме того, что я буду делать, если некоторые пользователи считают, что это право, а некоторые пользователи думают, что это не так? Этот вероятный сценарий также используется в таких примерах, как "Разработка для R&D" и "Разработка не подходит для R&D". Это удваивает количество кодов оплаты для отсутствия возврата в значении. Просто попросите кого-то в R&D пометить каждое раскрывающееся значение как допустимое или нет, и вам не придется продолжать просить конечных пользователей пытаться выяснить это каждую неделю.
Иерархических
Более совершенные системы проектов и расписаний обеспечивают иерархическое отображение данных. Если у вас нет другого выбора, кроме как иметь много возможных вариантов выбора, то создание иерархии может упростить проглотить большое количество данных. Подумайте о 5–10 элементах на выбор по максимуму на каждом уровне. И не поддайтесь искушению сделать десятки уровней. Создание иерархии 3–4 уровней должно иметь возможность охватывать большинство параметров. В конце концов, 10 элементов на уровне в 4-уровневой системе составляет 10 000 возможных расходов. Ваш проект сложнее, чем это?
Показать мне меньше
Чем меньше вопросов и вариантов вы даете своим пользователям, тем лучше вы будете. Если вы можете ответить в фоновом режиме, попробуйте не спрашивать его у пользователей в расписании. Цель заключается не в сборе максимально возможного количества данных, а в том, чтобы собрать максимально точную картину, и вы будете делать это лучше, если оградите конечных пользователей от данных, вопросов и вариантов, которые не будут иметь для них никакого значения.
Что вы будете делать с этими данными?
Мне часто говорят типы среднего управления, что им нужно "гораздо больше деталей", чем я предлагаю, и мой ответ всегда один и тот же: "Что вы будете делать с этим?" Цель сбора данных расписания на основе задач заключается в принятии более эффективных бизнес-решений, поэтому я часто спрашиваю у руководителей среднего звена, какое бизнес-решение они не в состоянии принять сейчас, когда они думают, что они сделали бы лучше, если бы у них было больше подробностей. Когда вы начинаете смотреть на информацию таким образом, вы обнаружите, что вам, вероятно, нужно меньше. Это может быть достаточно, чтобы узнать только общее количество часов, проведенных на собраниях, в пути или в накладных задачах, чем выяснить, что было каждой из этих задач.
Детализация глубже... но только в том случае, если необходимо
Когда вы начинаете выполнять анализ расписания, чтобы выяснить, где все ваши часы, вы обязательно найдете некоторые несоразмерные результаты. Там, где вы найдете необычно высокий процент часов, которые бросают вызов ожиданиям, пробурите немного глубже. Но не слишком глубоко. Добавьте еще один уровень сведений для этой платы и дайте ему несколько недель, чтобы увидеть, какие данные вы получаете. Искушение будет в том, чтобы расширить один код оплаты, такой как "собрания", в 50 новых кодов оплаты со всеми возможными типами собраний, которые могут произойти. Попробуйте противостоять этому искушению и вместо этого измените код 1 заряда на 5 или 6. Если вы не получили подробные сведения или у вас по-прежнему есть несоразмерные результаты, изучите немного глубже.
Поддержание чистоты дома
Списки расходов имеют тенденцию увеличиваться в размере, но никогда не уменьшаться. Рекомендуется регулярно проверять их и устранять вздутие. В этом случае вы, скорее всего, продолжите получать более точную информацию и сможете определить области, в которых вы теряете время.
Заключение
Управление кодом оплаты , будь то расписание проекта или система расписаний, может повлиять на эффективную систему, из которой можно рассчитывать данные, или систему со слишком большим количеством определений и недостаточной точностью. При разработке структуры кода оплаты рекомендуется начинать с меньшего, а не большего. Гораздо проще добавить больше сведений позже, если это потребуется, чем отмена дополнительных сведений и упрощение для перегруженных пользователей.
Об авторе
Крис Вандерслуис (Chris Vandersluis) — президент и основатель канадской компании HMS Software( Монреаль), сертифицированного партнера Майкрософт. Он имеет степень экономики в Университете Макгилла и более 30 лет опыта в автоматизации систем управления проектами. Он является давним членом Института управления проектами (PMI) и помог основать отделения Монреаля, Торонто и Квебека группы пользователей проекта (MPUG). Публикации, для которых Крис написал, включают Fortune, Heavy Construction News, Computing Canada magazine, PMNetwork PMI, и он является регулярным обозревателем Project Times. Он преподает расширенное управление проектами в Университете Макгилла и часто выступает в функциях ассоциации по управлению проектами в Северная Америка и по всему миру. HMS Software является издателем системы хронометрирования, ориентированной на проекты TimeControl, и с 1995 года является партнером по решению проектов Майкрософт.
С Крисом Вандерслуисом можно связаться по электронной почте по адресу: chris.vandersluis@hms.ca
Если вы хотите прочитать дополнительные статьи Криса Вандерслуиса, связанные с EPM, см. на сайте руководства по EPM HMS (https://www.epmguidance.com/?page_id=39).