FAQ
Обновлено: 03.12.2024
Для списания времени на задачу проекта пользователь должен выбрать ее в таймшите.
Доступность задачи в диалоге выбора определяют следующие условия:
- Проект не должен быть в статусе Отменен или Архивирован, т. е. он должен быть действующим.
- Автор таймшита должен быть добавлен в команду проекта (напрямую как пользователь или в составе подразделения), при этом добавленный член команды (пользователь или подразделение) не должен быть отключен.
- Автор таймшита должен быть назначен хотя бы на одну задачу проекта (явным образом или через назначение Всей команды).
- В проекте должна быть хотя бы одна задача, доступная для списания времени (в карточке задачи активна опция «Разрешено списание времени»). Если в проекте нет задач и учет ведется только на главную задачу проекта, то в свойствах проекта следует активировать опцию «Разрешить списание времени без выбора задачи».
- Задача должны быть активна (не отмечена как Выполненная).
При заполнении таймшита от пользователя может потребоваться заполнение свойства Роль:
Примечание
Необходимость заполнения колонки Роль в таймшите может быть отключена в настройках шаблона таймшита администратором системы.
Список доступных для выбора ролей определяется следующим образом:
- Если пользователь явным образом добавлен в команду проекта (через опцию Добавить пользователя), то в списке доступных для выбора ролей будут перечислены те роли, которые назначены пользователю в команде проекта.
- Если пользователь добавлен в команду проекта путем добавления подразделения (через опцию Добавить подразделение), то в списке доступных для выбора ролей будут перечислены те роли, которые назначены подразделению в команде проекта.
- Если в команду проекта добавлен и пользователь и подразделение к которому он относится, то в списке доступных для выбора ролей будут перечислены те роли, которые назначены и подразделению и пользователю в команде проекта.
- Если пользователю (и/или подразделению, к которому он относится) в команде проекта не назначено ни одной роли, то список доступных для выбора ролей будет пустым и указать роль будет невозможно.
Таймшиты в состоянии «Согласовано» не доступны для изменения.
Если требуется внести изменения в согласованный таймшит, нужно обратиться менеджеру по кадрам или администратору Timetta в вашей организации, чтобы он вернул таймшит в состояние «Черновик».
После внесения изменений потребуется заново запустить процесс согласования.
Оплачиваемые часы:
- Все часы по проектам с типом оплаты «Фиксированная стоимость».
- Часы по проектам с типом оплаты «Время и затраты» при условии, что для строки таймшита указан тариф, отличный от нуля.
Неоплачиваемые:
- Все часы по проектам с типом оплаты «Неоплачиваемый».
- Часы по проектам с типом оплаты «Время и затраты», для которых не указан тариф.
В Timetta показатель рассчитывается за какой-либо период, например, неделю, месяц и пр.
Оплачиваемое время — это все время учтенное через таймшиты по:
- Проектам с типом оплаты «Фиксированная оплата».
- Проектам с типом оплаты «Время и затраты», но только с выбранным тарифом, в котором стоимость часа больше 0.
Общее время — это все время, учтенное через таймшиты.
Показатель доступен в отчетах с типом Пользователи и в списках пользователей в системе.
Нельзя отправить на согласование таймшит, в котором есть не согласованная заявка на отсутствие. Есть строгий порядок согласования: сначала должно быть согласовано отсутствие, и только потом таймшит.
В момент отправки таймшита на согласование, он может проходить проверку на соответствие бизнес-правилам, настроенным администратором Timetta:
Правила бывают двух типов:
- Ошибка — таймшит не получится отправить на согласование до тех пор, пока он не будет соответствовать правилам.
- Предупреждение — таймшит можно отправить на согласование, проигнорировав предупреждение о несоответствии.
Удаление проектов, клиентов и программ происходит аналогично любому удалению сущности из списка в Timetta.
Важно!
Удаление — необратимая операция.
Для удаления:
- В области Проекты перейдите в необходимый список, например: Мои проекты, Мои клиенты, Мои программы.
- Выберите необходимую строку.
- Нажмите на кнопку Удалить на панели действий.
- Нажмите Подтверждаю в диалоговом окне.
При удалении может возникнуть следующая ошибка:
В Timetta нельзя удалять сущности, которые имеют связанные записи. Предварительно все зависимые данные также необходимо удалить.
-
При удалении Проекта такая ошибка может указывать на наличие отметок времени в Таймшитах, Заявок на затраты, Актов, Счетов, Бронирований, Запросов ресурсов, Проводок (в том числе автоматических) по данному проекту.
-
При удалении Клиента ошибка означает, что для данного клиента в системе существуют Проекты либо создан Счет на оплату.
-
При удалении Программы это означает, что существуют включенные в программу Проекты. Сначала необходимо исключить все проекты из программы.
Совет
Как правило, удаление сущности — трудоёмкая операция, требующая, в том числе удаления финансовых данных, что может негативно сказаться на проектном учете.
Для сохранения исторических данных лучше пользоваться возможностью перевода сущности в неактивное состояние. Для Клиентов и Программ таким является состояние Закрыт, для Проектов — Отменен или Архивирован.
При таком подходе:
- Сущность не будет отображаться в стандартном поиске;
- По умолчанию не будет отображаться в справочниках и списках;
- Не будет доступна для выбора в других компонентах системы (например, в таймшитах, бронированиях, счетах и т. д.).
При этом все исторические данные сохранятся в полном объеме.
Возможность добавления пользователя в команду проекта определяют следующие условия:
- В наборе прав доступа для роли Управление проектами должна быть активирована гранула Команда — Редактировать для соответствующей области.
- Добавляемый пользователь должен быть активным (активировано свойство Действующий в карточке сотрудника).
- Добавляемый пользователь ранее не был включен в команду проекта.
Как правило, проблема выявляется в п. 3. В большинстве случаев пользователь уже добавлен в команду проекта, но ранее был в ней отключен. Включить отображение деактивированных членов команды можно в настройках представления:
Для включения пользователя в команду проекта нажмите на соответствующую кнопку в интерфейсе:
Для организации процесса бронирования ресурсов под проекты.
Основной интерфейс приложения — Календарь бронирования. С его помощью можно бронировать сотрудников под участие в том или ином проекте, тем самым сообщая всей компании, что некоторый процент емкости сотрудника зарезервирован под проект на определенный период времени.
В общем случае есть два подхода: централизованный и децентрализованный.
При децентрализованном подходе все Менеджеры проектов коллективно работают с Календарем бронирования, используя его как общую доску для резервирования ресурсов под свои проекты.
При таком подходе у всех Менеджеров проектов должны быть права на редактирование Календаря бронирования, а решения о перераспределении ресурсов (например, в случае, если два и более менеджера претендуют на бронирование одного сотрудника) должны приниматься коллективно, на регулярных ресурсных встречах.
Централизованный подход более строгий и предполагает взаимодействие между Менеджерами проектов и Ресурсными менеджерами. Менеджеры проектов в таком случае выступают в качестве «потребителей ресурсов», а Ресурсные менеджеры — в качестве «владельцев». Взаимодействие между ними реализуется с помощью Запросов ресурсов.
При централизованном подходе Менеджеры проектов не могут самостоятельно резервировать сотрудников под свои проекты. Они должны обращаться к Ресурсным менеджерами, формулируя свои потребности с помощью Запросов ресурсов. Решение о резервировании сотрудников под проекты принимают Ресурсные менеджеры и только они могут вносить изменения в Календарь бронирования.
Режим работы с бронированием задается в настройках системы и применяется ко всей компании.
В базовом режиме бронирование выполняется с помощью «плашек»:
У плашки есть несколько параметров:
- Период (с по);
- Проект;
- Процент от емкости ресурса, забронированный под указанный проект на указанный период.
Плашка может быть в двух состояниях:
- Hard — подтвержденное бронирование;
- Soft — предварительное бронирование.
В базовом режиме не предусмотрена детализация бронирования по таймслотам (дням, неделям, месяцам). Задается только период времени, проект и процент емкости ресурса, выделенный под этот проект.
Базовый режим больше подходит для децентрализованного управления бронированием. В базовом режиме сложнее работать с Запросами ресурсов, однако проще работать с Календарем бронирования, так как плашки проще создавать, перетаскивать и менять их состояния.
В детальном режиме Календарь бронирования выглядит как таблица:
В детальном режиме нет плашек, а часы бронирования явно указываются на каждый таймслот. Детальный режим гораздо более подробный и позволяет более точно бронировать ресурсы. При этом он сложнее для восприятия и, так как в нём нет плашек, не поддерживает Hard и Soft бронирования.
Детальный режим больше подходит для централизованного управления бронированием. В детальном режиме удобнее работать с Запросами ресурсов.
Эти компоненты предназначены для разных ролей и разных целей.
Ресурсный план — инструмент для Менеджера проекта. В первую очередь, Ресурсный план нужен для оценки трудозатрат и себестоимости проекта. Ресурсный план может быть очень детальный, с декомпозицией до отдельных задач. Ресурсный план может быть составлен не для конкретных сотрудников, а с использованием Универсальных ресурсов (ролей) — особенно актуален такой подход на этапе первоначальной оценки проекта, когда нет гарантий, что проект в принципе стартует в указанные даты.
Календарь бронирования — это инструмент для коллективной работы (в случае децентрализованного подхода), или инструмент для Ресурсных менеджеров (в случае централизованного подхода). Календарь бронирования нужен для:
- Долгосрочного распределения сотрудников по проектам;
- Контроля ожидаемой утилизации каждого сотрудника;
- Выявления конфликтов за ресурсы, потенциального овербукинга;
- Балансировки загрузки, предотвращения простоев и перегрузов;
- Оптимального распределения ресурсов по проектам, с учетом их навыков и предпочтений.
Прямой связи нет. Если сотрудник добавлен в Ресурсный план проекта и выполнена оценка часов, это не равнозначно тому, что сотрудник забронирован под проект. И, обратная ситуация — если сотрудник забронирован под проект в Календаре бронирования это не равнозначно тому, что у него есть оценка часов в ресурсном плане.
Другими словами, сотрудник может быть запланирован на проект в Ресурсном плане но не забронирован (Менеджера проекта добавил оценку, но не зарезервировал сотрудника) или сотрудник может быть забронирован под проект, но оценки еще нет (Менеджера проекта зарезервировал ресурс, но еще не успел сделать Ресурсный план).
При децентрализованном подходе к бронированию рекомендуемый процесс такой:
- Менеджера проекта резервирует ресурс, с учетом его доступности по Календарю бронирования. Тем самым давая понять другим Менеджерам проектов, что ресурс не свободен и будет участвовать в его проекте.
- Менеджера проекта делает оценку Ресурсного плана с учетом емкости сотрудника, зарезервированной под его проект.
При централизованном подходе к бронированию рекомендуемый процесс такой:
- Менеджера проекта делает оценку в Ресурсном плане, желательно не для конкретных сотрудников, а с использованием Универсальных ресурсов.
- С помощью Запросов ресурсов Менеджера проекта обращается к Ресурсным менеджерам, чтобы они подобрали подходящих сотрудников взамен Универсальных ресурсов или подтвердили резервирование конкретных сотрудников под проект.
Если компания маленькая или если не предусмотрен процесс взаимодействия между Менеджерами проектов и Ресурсными менеджерами.
В таком случае обычно достаточно добавлять оценки часов в Ресурсные планы проектов, а за сводной загрузкой следить с помощью компоненты Сводка по сотрудникам. Последняя, по сути, представляет собой общий суммарный Ресурсный план по всем проектам и с ее помощью можно отслеживать совокупную оценочную загрузку ресурсов по всем проектам.
Во первых, нужно настроить Timetta:
- При использовании централизованного подхода рекомендуется использовать детальный режим работы с календарем бронирования.
- Выделить Ресурсные пулы — команды, за которые отвечают Ресурсные менеджеры. Для Ресурсных пулов поддерживается иерархия — может быть ведущий пул, включающий в себя несколько подчиненных (например, пул Аналитики, включающий в себя несколько под пулов: Аналитики SAP, Аналитики CRM и так далее).
- Для каждого пула следует назначить Ресурсного менеджера. Это тот человек, который будет обрабатывать запросы от Менеджеров проектов. Дополнительно, для каждого ресурсного пула можно назначить со-менеджеров — помощников основного Ресурсного менеджера.
- Всех сотрудников следует распределить по пулам. Пул, к которому относится сотрудник, указывается в карточке Пользователя на вкладке Профиль (реквизит Ресурсный пул).
При централизованном подходе рекомендуется использовать Универсальные ресурсы (роли). Универсальные ресурсы позволяют:
- Делать оценку проекта оперируя в Ресурсном плане не конкретными сотрудниками, а ролями.
- Делать запросы на подбор сотрудников взамен Универсальных ресурсов.
Другими словами, при оценке проекта, Менеджер проекта понимает, что через несколько месяцев ему понадобится Программист. Он добавляет в команду проекта Универсальный ресурс с соответствующей ролью, делает оценку, а затем формирует запрос для Ресурсного менеджера с просьбой подобрать ему подходящего сотрудника с соответствующей Ролью и с необходимой свободной емкостью. Такой запрос называется Запрос на подбор.
Чтобы можно было пользоваться Запросами на подбор необходимо предварительно:
- Наполнить справочник Роли. Подробнее — Роли.
- Назначить Пользователям роли. Подробнее — Управление пользователями.
- Наполнить справочник Уровни. Подробнее — Уровни.
Уровень — минимально необходимая характеристика для определения ставки себестоимости Универсального ресурса.
- Присвоить Пользователям уровни. Подробнее — Управление пользователями.
Для более точного определения ставки себестоимости Универсального ресурса можно настроить справочники Грейды и Локации. Подробнее о порядке определения ставки себестоимости Универсального ресурса — Уровни, грейды и локации ресурсов.
В команде проекта может быть два типа ресурсов:
- Универсальный ресурс — «заглушка» для оценки. Ресурс без конкретной фамилии, но с определенными характеристиками. Как минимум, для Универсального ресурса должны быть определены Роль и Уровень. Дополнительно можно указать Грейд, Локацию, Ресурсный пул.
- Именованный ресурс — конкретный сотрудник.
На стадии предварительной оценки проекта рекомендуется пользоваться Универсальными ресурсами по следующим причинам:
- На данной стадии могут быть не определены точные даты старта проекта.
- Нет гарантий, что Именованный ресурс в указанные даты будет свободен и сможет принять участие в проекте.
- Нет гарантий, что Ресурсный менеджер подтвердит выделение Именованного ресурса под данный проект.
В Timetta есть два типа Запросов ресурсов:
- Запросы на подбор — запрос на подбор подходящего исполнителя взамен Универсального ресурса.
- Запрос на актуализацию — запрос на изменение бронирования по Именованному ресурсу.
Лучше формировать команду из Универсальных ресурсов, а когда проект будет близок к старту (или когда вероятность старта и точность сроков проекта будет высокой), делать Запросы на подбор. В Запросе на подбор предусмотрена возможность указания предпочитаемых ресурсов. Таким образом, можно добавить в команду проекта Универсальный ресурс, например «Программист», а на этапе формирования Запроса на подбор указать, что предпочитаемым Программистом является конкретный сотрудник (один или несколько). При обработке запроса Ресурсный менеджер увидит ваши предпочтения и, по возможности, зарезервирует взамен Универсального ресурса нужного вам сотрудника.
Когда настройки выполнены, рекомендуемый процесс выглядит следующим образом:
- Менеджер проекта формирует команду проекта из сотрудников и/или Универсальных ресурсов.
- Менеджер проекта делает оценку трудозатрат по проекту в Ресурсном плане, тем самым формулируя потребность проекта в ресурсах.
- На вкладке Потребность в ресурсах в карточке проекта Менеджер проекта создает Запросы ресурсов: Запросы на подбор для Универсальных ресурсов и Запросы на актуализацию брони по сотрудникам.
- После формирования Запросов на подбор и Запросов на актуализацию Менеджер проекта стартует воркфлоу (бизнес-процесс) по каждому запросу, тем самым направляя свои запросы на рассмотрение Ресурсному менеджеру.
- Далее запросы поступают на обработку Ресурсному менеджеру. В конечном счете запросы переходят в состояние «Завершен», а результаты обработки запроса отражаются в Календаре бронирования.
Стандартный воркфлоу обработки Запроса на подбор или Запроса на актуализацию:
- Менеджер проекта стартует воркфлоу запроса. Подробнее — Воркфлоу.
- Ресурсный менеджер получает задачу на обработку ресурса (подбор или актуализацию). Есть два варианта:
а. Отклонить — Ресурсный менеджер возвращает запрос Менеджеру проекта с комментариями или замечаниями.
b. Завершить — Ресурсный менеджер подбирает ресурсы или актуализирует бронирование и завершает работу над запросом. Изменения бронирования отражаются в Календаре бронирования после завершения работы над запросом.
Дополнительно можно настроить шаг подтверждения результатов исполнения запроса со стороны Менеджера проекта. Например, так:
Да, можно. Это актуально для Запросов на подбор.
Например, могут быть следующие кейсы:
- Менеджер проекта направил запрос не в тот пул и Ресурсный менеджер хочет его передать в правильный пул.
- Менеджерам проектов сложно выбрать правильный пул и они направляют все запросы выделенному Координатору, который проанализирует запрос и сам выберет правильный пул.
Возможность делегирования можно настроить с помощью внесения изменений в Воркфлоу. Подробнее — Настройка делегирования запросов на ресурсы.
При анализе Себестоимости труда за какой-либо период могут возникать ситуации, когда Себестоимость, рассчитанная на основе Таймшитов, будет отличаться от Себестоимости, отраженной в Проводках.
Предположим, что сотрудники отмечают своё рабочее время через таймшиты на какой-либо Проект в течение месяца. При согласовании Таймшитов автоматически создаются Проводки. Если на этот месяц в Timetta есть открытый Учетный период, то Дата проводки будет равна Дате таймшита. При этом в качестве Даты таймшита берется последний календарный день, входящий в период Таймшита.
В качестве примера рассмотрим Таймшит на неделю с 31.10.2022 по 06.11.2022:
В этом случае Дата таймшита — 06.11.2022. Соответственно, если Учетный период на ноябрь открыт, то Проводки по этому Таймшиту будут созданы на 06.11.2022 (Дата проводки = Дата документа).
Однако в этом Таймшите есть особенность — в период Таймшита попадает один день из октября (31.10.2022).
В результате, если мы построим в области Аналитика отчет с типом «Таймшиты детально» за октябрь (с 01.10.2022 по 31.10.2022) и выведем в отчет Себестоимость всех часов за октябрь, окажется, что эта Себестоимость больше, чем Себестоимость за октябрь, отраженная в Проводках. Дело в том, что Себестоимость за 31.10.2022 будет отражена в Проводке, созданной на Дату таймшита, а Дата таймшита, как мы выяснили ранее — 06.11.2022. То есть с точки зрения финансового учета через Проводки, себестоимость одного дня из октября будет признана в ноябре.
Еще одна ситуация, когда Себестоимость, рассчитанная на основе Таймшитов, будет отличаться от Себестоимости, отраженной в Проводках может возникать из-за закрытия Учетных периодов.
Для простоты рассмотрим следующую ситуацию:
-
Сотрудник со ставкой себестоимости 100 рублей в час заполняет Таймшиты за октябрь.
-
Учетный период на октябрь открыт. Следовательно, по согласованным Таймшитам в октябре создаются Проводки.
-
Каждую неделю сотрудник списывает 1 час на один единственный проект.
В конце октября по Таймшитам сотрудника будет следующая картина:
Из таблицы видно, что так как последний Таймшит содержит в себе дни из разных месяцев, часть Себестоимости будет отражена в Проводках за ноябрь. Себестоимость за октябрь по отчету с типом «Таймшиты детально» составит 500 рублей, а по проводкам за тот же период — 400.
Теперь допустим, что один из согласованных ранее Таймшитов за октябрь вернули в статус «Черновик». Эта операция повлечет со собой автоматическое создание новой Проводки с противоположным знаком:
Теперь по первому таймшиту есть две Проводки:
- Проводка, созданная в результате согласования Таймшита.
- Проводка, созданная в результате возврата Таймшита в статус «Черновик».
Предположим, что после этого произошло два события:
- Учетный период на октябрь был закрыт.
- Таймшит был повторно согласован.
В результате по Таймшиту будет создана новая Проводка, но так как Дата документа попадает в закрытый Учетный период, Дата проводки будет равна ближайшей дате из открытого Учетного периода:
В результате Себестоимость, рассчитанная на основе Таймшитов в отчете с типом «Таймшиты детально» за октябрь составит 500 рублей, а Себестоимость, начисленная на октябрь с помощью Проводок — 300 рублей.
Чтобы дать доступ пользователю со сторонней почтой нужно:
- Нужно создать пользователя с почтой вашей организации (саму почту создавать не надо)
- В настройках созданного пользователя нажать на кнопку «Добавить альтернативную эл. почту для уведомлений». Все оповещения будут приходить на неё. Подробнее — создание пользователя.