Сервісна заявка

Сервісна заявка — це звернення клієнта, співробітника, користувача або внутрішнього підрозділу на виконання певної роботи, отримання послуги, усунення проблеми, консультацію, ремонт, налаштування, обслуговування обладнання або виконання сервісного процесу.

У Service Desk, HelpDesk, ERP для сервісу, BPM, ТОІР, EAM та K2 ERP сервісна заявка є базовою сутністю для управління зверненнями: хто звернувся, що потрібно зробити, де проблема, хто виконавець, який строк, який SLA, які файли додані, що зроблено і чи задоволений заявник.

У практиці ITSM сервісний запит часто розглядають як формальний спосіб для співробітника, клієнта або постачальника попросити певну стандартну послугу: доступ, обладнання, інформацію, налаштування або іншу типову дію.^[1]

Головна ідея. Сервісна заявка перетворює “мені щось потрібно” на контрольований процес: заявник, опис, категорія, пріоритет, SLA, виконавець, статус, результат, файли, історія і відповідальність.

У K2 ERP сервісна заявка може бути пов’язана з клієнтом, договором, обладнанням, серійним номером, гарантією, нарядом, виконавцем, складом, запчастинами, актом, рахунком, BPM, BI, AI та API.

Важливо. Сервісна заявка без статусу, виконавця і строку — це не заявка, а побажання. А побажання в бізнесі мають дивну властивість губитися саме тоді, коли клієнт питає: “Ну що там?”.

Застереження щодо санкцій. Продукти 1С та BAS потрібно розглядати з урахуванням санкційного режиму, рішень РНБО, указів Президента України, офіційних переліків забороненого або ризикового програмного забезпечення та політик кібербезпеки підприємства. Перед використанням, закупівлею, супроводом або міграцією необхідно перевіряти актуальні офіційні джерела та юридичні обмеження.^[2]

Що таке сервісна заявка

Сервісна заявка — це зареєстроване звернення на виконання сервісної дії.

Це може бути:

звернення клієнта;
звернення співробітника;
заявка на ремонт;
заявка на технічне обслуговування;
заявка на консультацію;
заявка на налаштування;
заявка на доступ;
заявка на заміну обладнання;
заявка на виїзд майстра;
заявка на підключення послуги;
заявка на усунення несправності;
заявка на постачання запчастин;
заявка на гарантійне обслуговування;
внутрішнє доручення сервісній службі.

Сервісна заявка потрібна для того, щоб сервіс не жив у дзвінках, месенджерах, випадкових листах і фразах “я ж казав учора”.

Простими словами. Сервісна заявка — це офіційно зареєстроване прохання щось зробити: полагодити, налаштувати, перевірити, доставити, підключити, пояснити або обслужити.

Для чого потрібні сервісні заявки

Сервісні заявки потрібні там, де є потік звернень і робіт.

Вони допомагають:

не губити звернення;
фіксувати проблему або потребу;
призначати виконавців;
контролювати строки;
виконувати SLA;
бачити статуси;
зберігати історію;
додавати файли;
контролювати гарантії;
вести облік обладнання;
планувати виїзди;
рахувати витрати;
формувати акти;
аналізувати якість сервісу;
бачити завантаження виконавців;
підвищувати дисципліну виконання.

Без сервісних заявок підтримка часто працює в режимі “хто голосніше нагадав, тому швидше зробили”.

З сервісними заявками бізнес бачить чергу робіт, пріоритети, відповідальних і реальну якість сервісу.

Де використовуються сервісні заявки

Сервісні заявки можуть використовуватися в різних сферах:

IT-підтримка;
технічна підтримка клієнтів;
сервісна компанія;
ремонт обладнання;
гарантійне обслуговування;
експлуатація будівель;
ЖКГ;
ОСББ;
керуючі компанії;
медичне обладнання;
агротехніка;
будівельна техніка;
виробниче обладнання;
транспорт;
логістика;
торгові мережі;
інтернет-магазини;
внутрішній адміністративний сервіс;
господарська служба;
польовий сервіс.

Скрізь, де є “потрібно щось зробити”, є місце для сервісної заявки.

Сервісна заявка, звернення і задача

Сервісну заявку часто плутають із зверненням або задачею.

Термін	Що означає
Звернення	Початкове повідомлення від користувача, клієнта або співробітника
Сервісна заявка	Зареєстрований сервісний запит, який має статус, категорію, виконавця, строк і результат
Задача	Конкретна дія, яку потрібно виконати в межах заявки або процесу
Наряд	Документ або доручення на виконання конкретної роботи виконавцем чи бригадою

Наприклад:

клієнт написав: “Не працює обладнання” — це звернення;
диспетчер зареєстрував сервісну заявку — це вже контрольований процес;
інженеру призначили перевірити блок живлення — це задача;
майстру видали наряд на виїзд — це робочий документ для виконання.

Основні реквізити сервісної заявки

Типова сервісна заявка може містити:

номер;
дату створення;
заявника;
клієнта;
контактну особу;
телефон;
email;
адресу;
організацію;
підрозділ;
об’єкт обслуговування;
обладнання;
серійний номер;
договір;
гарантію;
тему;
опис;
категорію;
тип заявки;
пріоритет;
SLA;
статус;
виконавця;
відповідального;
планову дату виконання;
фактичну дату виконання;
коментарі;
файли;
фото;
результат;
оцінку якості.

У K2 ERP сервісна заявка може доповнюватися додатковими властивостями через Характеристики сутностей без програмування.

Типи сервісних заявок

Сервісні заявки можуть мати різні типи.

Наприклад:

інцидент;
запит на обслуговування;
запит на консультацію;
ремонт;
гарантійний ремонт;
платний ремонт;
технічне обслуговування;
плановий огляд;
виїзд майстра;
заміна обладнання;
встановлення;
налаштування;
підключення;
демонтаж;
повернення;
рекламація;
скарга;
внутрішня заявка;
господарська заявка.

Тип заявки визначає маршрут, SLA, виконавця, документи, правила обробки і звітність.

Категорії сервісних заявок

Категорії допомагають класифікувати заявки.

Наприклад:

IT;
обладнання;
програмне забезпечення;
доступи;
мережа;
ремонт;
гарантія;
логістика;
електрика;
сантехніка;
будівля;
транспорт;
склад;
документи;
консультація;
аварія;
планове обслуговування.

Категорія потрібна не для краси довідника, а для автоматизації.

За категорією можна визначати:

виконавця;
SLA;
маршрут;
пріоритет;
шаблон відповіді;
список потрібних файлів;
тип наряду;
необхідність виїзду;
правила ескалації.

Пріоритет сервісної заявки

Пріоритет показує важливість заявки.

Типові пріоритети:

низький;
середній;
високий;
критичний;
аварійний.

Пріоритет може залежати від:

типу проблеми;
важливості клієнта;
договору;
SLA;
впливу на бізнес;
кількості користувачів;
ризику простою;
критичності обладнання.

Якщо все критичне — нічого не критичне.

Тому пріоритети мають бути чесними, інакше сервісна служба буде жити в постійній пожежі.

Статуси сервісної заявки

Статус показує стан заявки.

Типові статуси:

нова;
прийнята;
зареєстрована;
класифікована;
призначена;
в роботі;
очікує уточнення;
очікує клієнта;
очікує запчастин;
очікує підрядника;
заплановано виїзд;
виконана;
перевіряється;
закрита;
скасована;
прострочена.

Статус має відповідати реальному стану роботи.

Якщо всі заявки “в роботі”, це не статус, а туман.

SLA сервісної заявки

SLA або Service Level Agreement — це угода про рівень сервісу.

У сервісній заявці SLA може визначати:

час реакції;
час призначення виконавця;
час першої відповіді;
час виконання;
час виїзду;
правила ескалації;
робочий календар;
пріоритети;
відповідальність;
критерії порушення.

Atlassian описує управління сервісними запитами як стандартизовані робочі процеси подання, класифікації, виконання і комунікації за заявками.^[1]

SLA робить сервісну заявку вимірюваною: не “зробимо колись”, а “відреагувати за 2 години, виконати за 24 години, повідомити клієнта і зафіксувати результат”.

Виконавець заявки

Виконавець — це людина, група або підрядник, відповідальний за виконання заявки.

Виконавцем може бути:

інженер;
майстер;
диспетчер;
сервісна група;
IT-фахівець;
адміністратор;
технік;
бригада;
підрядник;
логіст;
менеджер підтримки;
відповідальний підрозділ.

У системі важливо бачити:

хто призначений;
коли призначений;
чи прийняв заявку;
який строк виконання;
які коментарі залишив;
що зробив;
які файли додав;
чи потрібна перевірка.

Заявка без виконавця — це сервісна сирота.

Диспетчеризація заявок

Диспетчеризація — це приймання, класифікація і розподіл заявок.

Диспетчер може:

прийняти звернення;
уточнити інформацію;
визначити категорію;
поставити пріоритет;
перевірити договір;
перевірити гарантію;
призначити виконавця;
запланувати виїзд;
проконтролювати строк;
повідомити заявника;
закрити заявку після виконання.

Хороший диспетчер — це не просто людина, яка “перекидає заявки”.

Це центр координації сервісу.

Наряд на виконання робіт

Наряд — це документ або завдання на виконання конкретної роботи.

Сервісна заявка може породжувати один або кілька нарядів.

Наприклад:

заявка: “Не працює насос”;
наряд 1: “Виїхати на об’єкт і провести діагностику”;
наряд 2: “Замінити деталь”;
наряд 3: “Провести тестування після ремонту”.

Наряд може містити:

виконавця;
бригаду;
дату і час виконання;
адресу;
роботи;
матеріали;
запчастини;
обладнання;
трудовитрати;
фото;
акт;
підпис клієнта;
результат.

Наряд потрібен, коли заявка переходить від “треба зробити” до “хтось конкретний їде і виконує”.

Об’єкт обслуговування

Сервісна заявка часто пов’язана з об’єктом обслуговування.

Це може бути:

обладнання;
будівля;
квартира;
приміщення;
транспорт;
сервер;
робоче місце;
виробнича лінія;
касовий апарат;
медичний прилад;
насос;
генератор;
верстат;
складська техніка;
інженерна система.

У системі важливо бачити історію заявок по об’єкту:

скільки разів ламався;
які роботи виконувалися;
які запчастини використовували;
хто ремонтував;
скільки коштувало;
чи є гарантія;
чи варто ремонтувати далі.

Серійний номер у сервісній заявці

Якщо заявка стосується конкретного обладнання, важливо фіксувати серійний номер.

Серійний номер дозволяє бачити:

який саме виріб обслуговується;
кому він проданий;
коли проданий;
чи діє гарантія;
які ремонти були раніше;
які запчастини використовували;
чи не повернули інший виріб;
чи є історія рекламацій.

Сервіс без серійного номера часто працює в режимі “схоже, це наше обладнання”.

Сервіс із серійним номером працює точніше.

Гарантійна заявка

Гарантійна заявка — це сервісна заявка, яка виконується в межах гарантійних зобов’язань.

У гарантійній заявці потрібно контролювати:

дату продажу;
серійний номер;
гарантійний строк;
умови гарантії;
причину звернення;
чи не порушені правила експлуатації;
результат діагностики;
рішення сервісу;
ремонт;
заміну;
відмову в гарантії;
акт;
файли;
фото.

Гарантія — це місце, де сервісна заявка зустрічається з юридичною відповідальністю, технікою і нервами клієнта.

Платна сервісна заявка

Платна сервісна заявка може передбачати:

діагностику;
рахунок;
погодження вартості;
передплату;
виконання робіт;
використання запчастин;
акт виконаних робіт;
оплату;
закриття взаєморозрахунків.

У K2 ERP така заявка може бути пов’язана з:

договором;
рахунком;
актом;
складом;
запчастинами;
банком;
касою;
взаєморозрахунками;
фінансовою аналітикою.

Внутрішня сервісна заявка

Сервісні заявки можуть бути не тільки клієнтськими, а й внутрішніми.

Наприклад:

співробітник просить доступ до системи;
потрібно налаштувати комп’ютер;
зламався принтер;
потрібен ремонт офісу;
потрібно замовити обладнання;
потрібне робоче місце;
потрібно перевірити мережу;
потрібно виконати господарську роботу.

Внутрішня сервісна заявка допомагає компанії не втрачати внутрішні запити між чатами, листами і “я тобі казав біля кавомашини”.

Клієнтська сервісна заявка

Клієнтська заявка надходить від зовнішнього клієнта.

Вона може бути пов’язана з:

договором обслуговування;
гарантією;
обладнанням;
замовленням;
рахунком;
актом;
SLA;
історією клієнта;
попередніми зверненнями;
сервісними умовами.

Для клієнта важливі не внутрішні складнощі компанії, а результат.

Клієнт хоче знати:

заявку прийняли;
хто займається;
коли буде результат;
що зроблено;
чи потрібно щось оплатити;
куди звертатися далі.

Заявка мешканця

У ОСББ, ЖКГ або керуючих компаніях сервісна заявка може бути заявкою мешканця.

Наприклад:

не працює ліфт;
протікає труба;
немає світла в під’їзді;
потрібно прибрати територію;
поламаний домофон;
аварійна ситуація;
скарга;
пропозиція;
заявка на ремонт.

Такі заявки мають бути прив’язані до:

будинку;
під’їзду;
квартири;
мешканця;
особового рахунку;
виконавця;
статусу;
фото;
результату.

Планове технічне обслуговування

Сервісні заявки можуть створюватися не тільки після проблеми, а й планово.

Наприклад:

регулярний огляд обладнання;
профілактика;
плановий ремонт;
заміна витратних матеріалів;
калібрування;
перевірка безпеки;
сезонне обслуговування;
технічний аудит.

Планові заявки допомагають попереджати аварії.

Бо краще створити заявку на профілактику сьогодні, ніж аварійну заявку завтра о третій ночі.

Запчастини і матеріали

Сервісна заявка може потребувати запчастин або матеріалів.

У системі потрібно бачити:

які запчастини потрібні;
чи є вони на складі;
чи потрібно замовити;
яка вартість;
з якого складу списати;
на яку заявку списати;
хто використав;
чи включити в рахунок клієнту;
чи це гарантійна заміна;
чи потрібно повернути дефектну деталь.

У K2 ERP сервісна заявка може бути пов’язана зі складом, серійним обліком, партійним обліком і фінансами.

Акт виконаних робіт

Після виконання сервісної заявки може створюватися Акт виконаних робіт.

Акт може містити:

клієнта;
договір;
заявку;
роботи;
матеріали;
виконавця;
дату;
суму;
підпис;
коментар;
результат;
гарантійні умови.

Акт потрібен для підтвердження виконання робіт і подальших фінансових операцій.

Для платного сервісу акт може бути підставою для оплати.

Для внутрішнього сервісу — підтвердженням виконання.

Коментарі до заявки

Коментарі допомагають зберігати історію обробки заявки.

У коментарях можуть бути:

уточнення заявника;
відповіді виконавця;
пояснення диспетчера;
причини затримки;
результати діагностики;
рішення клієнта;
погодження вартості;
службові нотатки;
підсумок виконання.

Коментарі краще зберігати в заявці, а не в месенджері.

Бо через місяць месенджер перетворюється на археологічні розкопки, а заявка має зберігати історію.

Файли і фото в сервісній заявці

До сервісної заявки можуть додаватися файли:

фото проблеми;
скриншот помилки;
акт;
рахунок;
договір;
гарантійний талон;
паспорт обладнання;
схема;
інструкція;
фото до ремонту;
фото після ремонту;
відео;
висновок майстра;
листування;
документ від підрядника.

У K2 ERP файли можуть бути прив’язані не лише до заявки, а й до клієнта, договору, обладнання, серійного номера, наряду, акту, задачі або іншої сутності.

Файли в сервісній заявці — це доказ і контекст. Фото проблеми часто пояснює ситуацію краще, ніж десять повідомлень “воно не працює”.

Характеристики сервісної заявки

У різних компаній сервісні заявки можуть мати різні додаткові поля.

Наприклад:

тип обладнання;
модель;
серійний номер;
причина звернення;
канал звернення;
джерело заявки;
тип гарантії;
рівень критичності;
регіон;
об’єкт;
відповідальний менеджер;
дата виїзду;
причина прострочення;
результат діагностики;
рішення по гарантії.

У K2 ERP Характеристики сутностей дозволяють доповнювати заявки додатковими властивостями без програмування.

Це важливо, бо сервіс у медичному обладнанні, ЖКГ, IT, будівництві, агро і торгівлі має різну логіку.

Service Desk і сервісна заявка

Service Desk — це система або процес управління сервісними зверненнями.

Сервісна заявка в Service Desk проходить шлях:

створення;
реєстрація;
класифікація;
визначення пріоритету;
перевірка SLA;
призначення виконавця;
виконання;
комунікація із заявником;
перевірка результату;
закриття;
аналіз якості.

Service Desk потрібен для того, щоб сервіс був не хаотичним, а керованим.

HelpDesk і сервісна заявка

HelpDesk часто використовується для підтримки користувачів.

У HelpDesk сервісна заявка може бути пов’язана з:

проблемою користувача;
консультацією;
доступом;
програмною помилкою;
обладнанням;
робочим місцем;
внутрішньою IT-службою;
базою знань;
SLA.

HelpDesk частіше асоціюється з підтримкою.

Service Desk — ширше поняття, яке може охоплювати сервісні процеси, SLA, договори, активи, зміни, знання, аналітику і бізнес-результати.

База знань

Сервісна заявка може бути пов’язана з базою знань.

База знань допомагає:

швидко знаходити типові рішення;
відповідати на часті питання;
навчати нових виконавців;
зменшувати повторні звернення;
стандартизувати відповіді;
прискорювати виконання заявок.

Наприклад, якщо 100 користувачів щомісяця створюють однакову заявку, можливо, проблема не в користувачах, а в тому, що їм давно потрібна нормальна інструкція.

Ескалація сервісної заявки

Ескалація — це передача заявки на вищий рівень контролю або іншому виконавцю.

Ескалація може спрацьовувати, якщо:

порушено SLA;
заявка критична;
виконавець не реагує;
потрібне рішення керівника;
потрібен підрядник;
потрібні запчастини;
клієнт незадоволений;
проблема повторюється;
заявка зависла.

Ескалація потрібна не для покарання, а для того, щоб проблема не лежала тихо до моменту, коли вона стане великою.

Оцінка якості сервісу

Після закриття заявки можна збирати оцінку якості.

Оцінювати можна:

швидкість реакції;
якість виконання;
ввічливість виконавця;
зрозумілість комунікації;
повноту рішення;
загальне задоволення;
повторну проблему.

Оцінка допомагає не просто закривати заявки, а покращувати сервіс.

Бо “закрито” ще не завжди означає “клієнт задоволений”.

Сервісна аналітика

Аналітика сервісних заявок може показувати:

кількість заявок;
відкриті заявки;
закриті заявки;
прострочені заявки;
середній час реакції;
середній час виконання;
порушення SLA;
завантаження виконавців;
найчастіші категорії;
проблемні об’єкти;
повторні заявки;
гарантійні звернення;
витрати на сервіс;
якість роботи підрядників;
задоволеність клієнтів.

Без аналітики сервісна служба бачить тільки чергу заявок.

З аналітикою вона бачить причини, тенденції і якість.

Сервісна заявка в K2 ERP

У K2 ERP сервісна заявка може бути частиною єдиної ERP-платформи.

Вона може бути пов’язана з:

Саме це відрізняє сервісну заявку в ERP від простого тікета в окремій системі.

У ERP заявка має фінансовий, складський, договірний і управлінський контекст.

BPM у сервісних заявках

BPM дозволяє автоматизувати маршрут сервісної заявки.

Наприклад:

заявка створена;
система визначила категорію;
перевірила SLA;
призначила диспетчера;
диспетчер призначив виконавця;
виконавець провів діагностику;
система створила наряд;
склад видав запчастини;
майстер виконав роботу;
клієнт підтвердив результат;
акт сформовано;
заявка закрита.

BPM потрібен для того, щоб заявка рухалась за правилами, а не за настроєм виконавця.

Сервісна заявка і фінанси

Сервісна заявка може впливати на фінанси.

Наприклад:

платна заявка створює рахунок;
виконані роботи створюють акт;
використані запчастини формують витрати;
виїзд майстра має собівартість;
гарантійна заявка може бути витратою компанії;
клієнтська заявка може бути джерелом доходу;
сервісний контракт має бюджет;
SLA може впливати на штрафи або бонуси.

У K2 ERP сервісна заявка може бути пов’язана з фінансами, проєктним обліком, взаєморозрахунками і управлінським обліком.

Сервісна заявка і API

Через API для ERP сервісні заявки можуть створюватися з різних джерел.

Наприклад:

сайт;
мобільний застосунок;
клієнтський портал;
email;
чат-бот;
CRM;
система моніторингу;
обладнання;
IoT-датчики;
зовнішній HelpDesk;
інтернет-магазин;
особистий кабінет клієнта.

Через API можна:

створити заявку;
отримати статус;
додати коментар;
прикріпити файл;
передати фото;
призначити виконавця;
отримати результат;
закрити заявку;
передати оцінку.

API робить сервісну заявку частиною цифрової екосистеми, а не просто записом у внутрішній базі.

Сервісна заявка і BI

BI система може аналізувати сервісні заявки.

BI може показувати:

динаміку заявок;
заявки по клієнтах;
заявки по категоріях;
заявки по виконавцях;
виконання SLA;
прострочення;
повторні звернення;
витрати на сервіс;
ефективність підрядників;
проблемні об’єкти;
якість сервісу;
гарантійні витрати;
завантаження команди;
середній час виконання.

BI дозволяє керівнику сервісу бачити не тільки список заявок, а й здоров’я сервісної системи.

Сервісна заявка і AI

AI в ERP може допомагати в роботі із сервісними заявками.

Наприклад:

класифікувати заявку за текстом;
визначати пріоритет;
підказувати виконавця;
знаходити схожі заявки;
пропонувати рішення з бази знань;
підсумовувати історію заявки;
попереджати про ризик порушення SLA;
аналізувати повторні проблеми;
знаходити типові причини звернень;
готувати відповідь клієнту;
прогнозувати потребу в запчастинах.

AI не замінює сервісну службу, але може зробити її швидшою і уважнішою.

Типові помилки в роботі із сервісними заявками

Типові помилки:

приймати заявки тільки телефоном;
не фіксувати звернення в системі;
не визначати виконавця;
не ставити строки;
не налаштовувати SLA;
не класифікувати заявки;
не вести історію;
не додавати файли;
не прив’язувати обладнання;
не контролювати гарантію;
не списувати запчастини на заявку;
не створювати акти;
не аналізувати повторні проблеми;
не збирати оцінку якості;
вести сервіс окремо від ERP.

Найгірша помилка — думати, що сервісна заявка закінчується кнопкою “закрити”.

Насправді вона закінчується тоді, коли проблема вирішена, клієнт поінформований, документи оформлені, витрати враховані, а система запам’ятала досвід.

Сервісні заявки і перехід з 1С/BAS на K2 ERP

У старих системах 1С або BAS сервісні заявки могли вестися по-різному:

у документах;
у задачах;
у довідниках;
через зовнішні обробки;
через BAS Service Desk;
через окрему HelpDesk-систему;
через Excel;
через пошту;
через месенджери;
через ручні доробки.

Під час переходу на K2 ERP важливо не просто перенести список заявок, а відновити сервісний контекст:

заявник;
клієнт;
договір;
об’єкт;
обладнання;
серійний номер;
гарантія;
статус;
SLA;
виконавець;
коментарі;
файли;
наряди;
акти;
витрати;
історія.

Правильна міграція сервісних заявок — це не перенесення старої черги звернень. Це перенесення сервісної пам’яті: клієнти, обладнання, історія, гарантії, SLA, файли, виконавці, акти і результат.

Реплікатор K2 і сервісні заявки

Реплікатор K2 — це інструмент для перенесення даних з 1С/BAS у K2 ERP.

Для сервісних заявок Реплікатор K2 може допомагати:

переносити клієнтів;
переносити договори;
переносити об’єкти обслуговування;
переносити обладнання;
переносити серійні номери;
переносити відкриті заявки;
переносити закриті заявки;
переносити статуси;
переносити SLA;
переносити виконавців;
переносити коментарі;
переносити файли;
переносити наряди;
переносити акти;
переносити сервісну історію;
звіряти дані;
запускати K2 ERP паралельно зі старими системами;
переходити тоді, коли готові диспетчери, виконавці, керівники сервісу і користувачі.

Реплікатор K2 дозволяє організувати поступовий перехід сервісних заявок з 1С/BAS у K2 ERP без зупинки сервісної служби: заявки переносяться, звіряються, користувачі навчаються, а компанія переходить тоді, коли готова.

Що можна перенести в K2 ERP

Під час переходу сервісного контуру в K2 ERP можуть переноситися:

клієнти;
контрагенти;
договори;
сервісні договори;
користувачі;
виконавці;
групи виконавців;
підрядники;
об’єкти обслуговування;
обладнання;
серійні номери;
гарантійні дані;
категорії заявок;
типи заявок;
пріоритети;
статуси;
SLA;
відкриті заявки;
історія заявок;
наряди;
задачі;
коментарі;
файли;
акти;
рахунки;
складські документи;
запчастини;
управлінські звіти;
критична сервісна історія.

Не завжди потрібно переносити все.

Іноді достатньо перенести активних клієнтів, обладнання, відкриті заявки, гарантійні об’єкти, SLA, файли і критичну історію, а стару систему залишити як архів.

Чому не варто копіювати старий сервіс один в один

Під час міграції часто хочеться сказати: “Зробіть у K2 ERP так само, як було”.

Іноді це потрібно для критичних процесів.

Але стара система може містити:

дублікати клієнтів;
заявки без категорій;
заявки без виконавців;
статуси, які нічого не означають;
SLA, які ніхто не контролює;
обладнання без серійних номерів;
гарантії без дат;
коментарі в месенджерах;
файли в різних папках;
заявки без актів;
запчастини без списання;
повторні проблеми без аналізу;
звіти, які вже ніхто не використовує.

Перехід на K2 ERP — це шанс не просто перенести заявки, а побудувати зрозумілий сервісний процес.

Санкційний контекст 1С та BAS

Після початку російської агресії проти України питання використання програмного забезпечення, пов’язаного з російськими компаніями, правовласниками або екосистемами, стало не лише технічним, а й безпековим.

Продукти 1С та BAS потрібно розглядати з урахуванням:

санкцій РНБО;
указів Президента України;
офіційних переліків забороненого програмного забезпечення;
вимог кібербезпеки;
ризиків для критичної інфраструктури;
політик державних підприємств;
внутрішніх політик безпеки організації;
стратегічної цифрової незалежності України.

Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються, зокрема, продукти 1С/BAS.^[2]

Ключове застереження. 1С та BAS перебувають у полі санкційних і безпекових обмежень. Українським підприємствам варто не вкладатися в продовження залежності від цих продуктів, а планувати контрольований перехід на українські альтернативи.

K2 ERP як українська платформа для сервісних заявок

K2 ERP може бути українською ERP-платформою для підприємств, які хочуть вести сервісні заявки без залежності від 1С та BAS.

K2 ERP може підтримувати або розвивати напрями:

K2 ERP для сервісних заявок — це можливість керувати сервісом в єдиній українській платформі: клієнти, заявки, SLA, виконавці, обладнання, гарантії, запчастини, акти, фінанси, BPM, BI, AI та API працюють разом.

Сервісна заявка як SEO-термін

Сторінка Сервісна заявка важлива для SEO, бо користувачі можуть шукати:

сервісна заявка;
заявка на сервіс;
service request;
сервісний запит;
заявка Service Desk;
заявка HelpDesk;
облік сервісних заявок;
програма для сервісних заявок;
ERP для сервісу;
сервісна заявка SLA;
заявка на ремонт;
заявка на технічне обслуговування;
гарантійна заявка;
заявка мешканця;
сервісна заявка K2 ERP;
українська ERP для сервісу;
альтернатива BAS Service Desk;
альтернатива 1С сервісні заявки;
перехід з BAS на K2 ERP;
Реплікатор K2 сервісні заявки.

FAQ

Що таке сервісна заявка?

Сервісна заявка — це зареєстроване звернення клієнта, співробітника або користувача на виконання роботи, отримання послуги, ремонт, консультацію, налаштування або обслуговування.

Чим сервісна заявка відрізняється від задачі?

Сервісна заявка описує потребу або проблему, а задача — конкретну дію, яку потрібно виконати для її вирішення.

Що таке SLA у сервісній заявці?

SLA — це правила строків реакції та виконання заявки: коли потрібно відповісти, коли виконати, коли ескалювати і що вважається порушенням.

Хто є виконавцем сервісної заявки?

Виконавцем може бути співробітник, сервісний інженер, майстер, група підтримки, підрядник або відповідальний підрозділ.

Чи може сервісна заявка мати файли?

Так. До заявки можуть додаватися фото, скриншоти, акти, рахунки, договори, гарантійні документи, інструкції, схеми та інші файли.

Чи може K2 ERP підтримувати сервісні заявки?

Так. K2 ERP може бути платформою для сервісних заявок, Service Desk, HelpDesk, SLA, виконавців, нарядів, обладнання, гарантій, складу, актів, BI, AI та API.

Чи можна перенести сервісні заявки з 1С/BAS у K2 ERP?

Так. Через Реплікатор K2 можна переносити клієнтів, договори, обладнання, серійні номери, відкриті заявки, історію, статуси, SLA, файли, наряди, акти і критичну сервісну історію.

Чи потрібно переносити всі старі заявки?

Не завжди. Часто достатньо перенести відкриті заявки, активних клієнтів, обладнання, гарантійні об’єкти, SLA, файли і критичну історію. Старі завершені заявки можна залишити в архіві.

Коротко

Питання	Відповідь
Що таке сервісна заявка?	Зареєстроване звернення на виконання сервісної роботи, ремонту, консультації або обслуговування.
Де використовується?	Service Desk, HelpDesk, сервісні компанії, IT, ЖКГ, ОСББ, ремонт, гарантія, обладнання, технічна підтримка.
Що має містити?	Заявника, опис, категорію, пріоритет, SLA, статус, виконавця, строк, файли, результат і історію.
Навіщо потрібен SLA?	Щоб контролювати строки реакції та виконання.
Чим корисна K2 ERP?	Об’єднує заявки з клієнтами, договорами, обладнанням, гарантіями, складом, фінансами, BPM, BI, AI та API.
Як перейти з 1С/BAS?	Через аудит, Реплікатор K2, перенесення даних, паралельну роботу, звірку і навчання користувачів.

Висновок

Сервісна заявка — це основа керованого сервісу.

Вона дозволяє бачити:

хто звернувся;
що потрібно зробити;
який пріоритет;
який SLA;
хто виконавець;
у якому статусі робота;
які файли додані;
яке обладнання обслуговується;
чи діє гарантія;
які запчастини використано;
який результат;
чи задоволений заявник.

Без сервісних заявок сервіс часто живе в дзвінках, чатах, пам’яті співробітників і героїзмі виконавців.

З сервісними заявками сервіс стає видимим, вимірюваним і керованим.

K2 ERP дозволяє розглядати сервісну заявку не як окремий тікет, а як частину єдиної ERP-платформи: клієнти, договори, обладнання, SLA, виконавці, склад, фінанси, документи, BPM, BI, AI та API працюють разом.

Правильний підхід до сервісних заявок:

реєструвати всі звернення;
класифікувати заявки;
визначати пріоритет;
налаштовувати SLA;
призначати виконавців;
вести статуси;
додавати файли;
пов’язувати заявки з обладнанням і договорами;
контролювати гарантію;
формувати наряди й акти;
аналізувати якість сервісу;
переносити дані через Реплікатор K2;
поступово переходити зі старих систем на K2 ERP.

Саме так сервісна заявка перестає бути “ще одним зверненням” і стає реальним інструментом якості, відповідальності та довіри.

Див. також

Зовнішні посилання

Примітки

[atlassian_srm-1] 1,0 ^1,1 Atlassian: What is a service request?

[cip_list-2] 2,0 ^2,1 Держспецзв’язку: перелік забороненого до використання програмного забезпечення та обладнання

[1]

[2]