До запуску замовлення у виробництво компанія може виконувати кілька підготовчих робіт: розробляти дизайн, готувати креслення, проводити конструкторські розрахунки, визначати технологію виготовлення, формувати калькуляцію або оформлювати технічну документацію. Від завершення цих завдань залежить, коли менеджер зможе надати клієнту комерційну пропозицію, а виробництво — отримати достатньо даних для початку роботи.
Коли технічні запити зберігаються в листуванні, окремих таблицях, усних домовленостях і персональних списках працівників, керівник бачить окремі доручення, але не загальний обсяг роботи. Кількість відкритих завдань не показує, скільки годин потрібно на їх виконання, у якій послідовності вони мають пройти та чи відповідає запланована дата доступності спеціалістів.
Назви роботи та відповідального працівника недостатньо для планування.
Графік має враховувати вид роботи, її планову трудомісткість, місце в черзі, робочий календар виконавця, пріоритет, поточний етап, дедлайн і вже витрачений час.
Без цього керівник бачить перелік доручень, але не бачить пропускної здатності технічного відділу.
Технічна підготовка є окремим потоком робіт
Технічні завдання виникають не тільки після підтвердження замовлення. Частина з них потрібна ще до продажу: дизайнер готує макет, конструктор перевіряє можливість виготовлення, технолог визначає операції та матеріали, кошторисник або інший спеціаліст формує розрахунок. Інші роботи з’являються після погодження замовлення або як внутрішні запити компанії.
Якщо ці завдання не пов’язані з початковим комерційним запитом, менеджеру доводиться окремо з’ясовувати, кому передано роботу, чи прийнята вона до виконання та коли буде готовий результат. Дані про клієнта, вимоги, файли й погодження при цьому залишаються в різних каналах.
У модулі «Робочі завдання» Bon Sens на базі Odoo завдання можна створити з нагоди в CRM, з документа продажу або безпосередньо в модулі. Інформація про клієнта, продавця та комерційний запит залишається пов’язаною з виконанням роботи. Вимоги передаються через опис, вкладення та структуровані брифи з питаннями й відповідями.
Зв’язок із початковим запитом важливий і для планування роботи відділу. Керівник бачить, до якого замовлення належить завдання, яка команда його виконує та від якого результату залежить подальший рух роботи.
Завдання без планового часу не показує реального завантаження
У переліку три завдання можуть виглядати однаково: підготувати макет, зробити розрахунок і розробити креслення. Проте перша робота може зайняти менше години, друга — половину робочого дня, а третя — кілька днів. Підрахунок карток не враховує цієї різниці, тому не може бути основою для визначення завантаження.
Перелік робіт стає планом лише після оцінки їхньої трудомісткості. Для повторюваних видів робіт доцільно встановити нормативні планові години. Під час створення завдання вони формують початкову оцінку обсягу роботи, яку потрібно розмістити в черзі конкретного виконавця.
У рішенні Bon Sens планові години налаштовуються для послуг і відповідних видів робіт. Після вибору виду роботи в завдання переноситься встановлена кількість годин. У черзі з’являється не просто картка з назвою, а робота з визначеною трудомісткістю.
Початковий норматив може потребувати коригування. Проте навіть орієнтовна оцінка створює спільну основу для розподілу робіт. Після накопичення фактичних даних компанія може перевірити, для яких видів робіт установлені години відповідають реальній трудомісткості, а для яких системно занижені або завищені.
Без планової оцінки неможливо визначити ані обсяг незавершеної роботи, ані резерв потужності відділу.
Робочий календар визначає доступний час спеціаліста
Планові години показують потребу в ресурсі, але не відповідають на питання, коли цей ресурс доступний. Працівник може мати повний або скорочений графік, інший режим роботи чи обмежену частку часу, яку реально можна спрямувати на технічні завдання.
Для кожного виконавця налаштовуються робочі години та фактор ефективності. Ці параметри потрібні для розрахунку доступного часу й завантаження. Якщо картка працівника не пов’язана з користувачем або в ній не заповнений робочий календар, графік не має достатньо даних для планування.
Фактор ефективності не прирівнює весь номінальний робочий день до часу виконання завдань. Частина дня може припадати на внутрішні комунікації, погодження, уточнення, організаційні роботи та інші процеси. Конкретне значення компанія визначає відповідно до організації роботи певного відділу.
Планування має враховувати не номінальну тривалість робочого дня, а час, доступний конкретному виконавцю. Потреба в годинах за завданнями порівнюється з його робочим календарем і фактором ефективності. На цій основі можна визначити, чи має спеціаліст резерв для нового запиту та як його додавання вплине на вже заплановані роботи.
Черга визначає, коли завдання може бути виконане
Навіть правильно оцінене завдання не має обґрунтованого терміну, якщо його розглядати окремо від інших робіт. Дата готовності залежить не тільки від його трудомісткості, а й від усіх завдань, які вже стоять перед ним у черзі.
Для кожної команди передбачена власна послідовність етапів канбану. Завдання розподіляються між дизайнерами, конструкторами, технологами або іншими підрозділами, проходять визначені етапи та розташовуються в пріоритетній послідовності. Користувач із відповідним дозволом може змінювати порядок карток у межах етапу.
Переміщення одного термінового завдання змінює очікувані дати всіх робіт, що стоять після нього. Керівник бачить, які дедлайни можуть зміститися після коригування пріоритету, і може врахувати це до погодження нового терміну з менеджером або клієнтом.
У картці робочого завдання зберігаються планова дата та розрахований дедлайн. Разом із плановими годинами, виконавцем і положенням у черзі ці дані показують, чи відповідає бажаний термін доступній потужності.
Графік не замінює управлінського рішення. Пріоритети, перепризначення та коригування планових дат залишаються відповідальністю уповноважених працівників, але їхній вплив на подальшу чергу стає видимим.
Виконавець, команда, етап і дедлайн мають бути частинами одного документа
Розподіл завдань лише за прізвищами не дає повної картини. Для управління потоком потрібно бачити, до якої команди належить робота, хто відповідає за її виконання, на якому етапі вона перебуває та який дедлайн розраховано з урахуванням черги.
Картка завдання об’єднує команду, виконавця, продавця, пов’язану нагоду або документ продажу, категорію, вид роботи, пріоритет, планову дату, розрахований дедлайн, планові години, опис, брифи, вкладення й дані обліку часу. Історія змін зберігається в тому самому документі.
У результаті завдання залишається частиною загального процесу — від комерційного запиту до передавання результату менеджеру або у виробництво. Менеджер бачить стан роботи, керівник команди — її місце в черзі та відповідального виконавця, а спеціаліст отримує вимоги, файли й контекст без пошуку інформації в окремих каналах.
Розподіл ролей і прав захищає чергу від неконтрольованих змін. Продавець може створити завдання й передати вимоги, виконавець — фіксувати роботу, а лідер команди — призначати спеціаліста та коригувати планові дати. Окремими дозволами регулюються зміна послідовності завдань і ручне редагування планового або фактичного часу.
Фактичний час підтримує актуальність майбутнього плану
Планові години залишаються оцінкою, доки компанія не зіставляє їх із фактичним виконанням. Якщо розрахунок, який нормативно займає дві години, систематично потребує чотирьох, майбутній графік буде перевантаженим навіть за правильно налаштованого календаря.
Виконавець фіксує роботу за допомогою таймера в картці завдання. Одночасно він може вести відлік лише за однією роботою. Після завершення система записує фактичні години та оновлює залишок часу. У табелі також зберігається історія зміни етапу, команди, виконавця, виду роботи та планових годин.
Порівняння плану з фактом потрібне не для контролю кожної хвилини працівника. Воно показує якість нормативів і дає підстави переглядати майбутні оцінки. Якщо відхилення повторюється для одного виду робіт, керівник може перевірити, чи правильно визначено плановий час, чи достатньо даних передає ініціатор завдання та чи не виникає додаткова робота, якої не було в початковому описі.
Фактичні години мають управлінську цінність лише за регулярної та однакової для всіх фіксації. Пропущені запуски таймера або неточні ручні коригування спотворюють дані, тому правила обліку часу мають бути частиною робочого процесу.
Графік потрібен для управління пропускною здатністю, а не для мікроконтролю
Графік не потрібен для щохвилинного контролю працівників. Його завдання — показувати, скільки робочого часу вже зайнято, який обсяг залишається в черзі, де виникає перевантаження та який термін можна підтвердити для нового запиту.
На основі цих даних керівник може змінити послідовність робіт із розумінням впливу на наступні дедлайни, перепризначити завдання іншому спеціалісту, скоригувати дату або переглянути нормативні години після накопичення фактичних даних.
Якщо певний виконавець систематично має більше планових годин, ніж доступного часу, проблема полягає не в кількості карток як такій. Вона може бути пов’язана з концентрацією критичних компетенцій, нерівномірним розподілом робіт або заниженими нормативами.
Для виробничої компанії практичний результат полягає в узгодженні продажів, технічної підготовки та запуску замовлення. Менеджер не визначає дату готовності креслення або розрахунку окремо від поточного навантаження відділу. Керівник технічної команди бачить, яку частину майбутнього доступного часу вже займають прийняті завдання.
Які дані потрібні для управління завантаженням
Кількість відкритих завдань показує лише поточний обсяг карток. Для планування потрібні сума планових годин, залишок невиконаного часу, фактичні витрати, доступний час за календарями, завантаження за виконавцями, прострочені роботи, поточні етапи та зміни пріоритетів.
Жоден із цих показників не варто аналізувати ізольовано. Високе завантаження може бути допустимим, якщо роботи розподілені на достатній період. Невелика кількість завдань може створювати критичне обмеження, якщо всі вони потребують багато годин одного спеціаліста.
Тому завантаження технічного відділу потрібно оцінювати як співвідношення планової трудомісткості, доступного часу та пріоритетної черги. Фактичні години доповнюють цю модель і показують, наскільки коректно компанія оцінює повторювані види робіт.
Від переліку робіт до керованого графіка
Канбан із картками показує стан робіт, але сам по собі не відображає завантаження. Для керованого графіка кожне завдання повинно мати планову трудомісткість, виконавця, позицію в черзі та зв’язок із його робочим календарем. Тоді керівник бачить не тільки поточні доручення, а й те, яку частину майбутньої потужності відділу вони вже займають.
Модуль «Робочі завдання» Bon Sens на базі Odoo об’єднує постановку вимог, зв’язок із CRM і продажами, розподіл за командами, планові години, пріоритети, етапи, розрахований дедлайн і фактичний час. Це формує єдиний робочий контур для планування технічної підготовки замовлень.
Графік не усуває потреби визначати пріоритети й підтримувати дисципліну обліку. Проте пріоритети, нормативи, призначення та зміни фіксуються в одному процесі, а не в окремих домовленостях. Керівник отримує дані для оцінювання завантаження, а менеджер — підставу для погодження реалістичного терміну підготовки дизайну, розрахунку, креслення або технічної документації.
Хочете побачити планування робочих завдань як частину управління технічним відділом?
Можемо показати, як у рішенні Bon Sens на базі Odoo пов’язати запити з CRM і продажів, планові години, робочі календарі, виконавців, пріоритетну чергу, дедлайни та фактичний час в одному процесі.
Задайте питання менеджеру через форму на сайті або зателефонуйте:
Задайте питання менеджеру
Задавайте ваші питання і ми зв’яжемося з вами для їх обговорення.
Керована черга показує реальну послідовність робіт і допомагає перебудовувати графік після зміни пріоритетів, завантаження або доступності спеціалістів
Порівняння запланованих і фактично витрачених годин показує, де оцінка трудомісткості перестає відповідати реальному виконанню
Нарахування зарплати має завершуватися управлінською картиною витрат
Послідовність операцій, технічні завдання, передача деталей і дані для відрядної зарплати
Відрядна оплата має спиратися на підтверджену дію, а не на усні домовленості