Автоматизація сервісного центру по ремонту техніки.

Замовник

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

Замовник звернувся з таким питанням. Є сервісний центр, який проводить ремонт техніки. Потрібно було автоматизувати його діяльність. У замовника вже була торгова програма “1С: Підприємство” “Управління торгівлею”, в якій працювали всі магазини, оптовий відділ, закупівельники. Тому автоматизацію сервісного центру потрібно було провести в цій програмі.

Завдання

Потрібно було автоматизувати облік починаючи з приймання товару на сервісний центр майстром приймальником, і до видачі відремонтованого товару клієнту. Так само потрібно було врахувати що є гарантійний товар і не гарантійний. Розподілити обов’язки між сервісними інженерами і в результаті нарахувати заробітну плату кожному співробітникові сервісного центру. Організувати закупівлю і зберігання запасних частин.

Почали аналізувати бізнес-процеси, які відбуваються в сервісному центрі. Опишу частина з них.

1 – Прийом товару від клієнта.

2 – Первісне тестування

І на цьому етапі вже виникло багато питань. 

• Якщо товар приймався як гарантійний, він міг стати «не гарантійним”, наприклад, з причин неправильного використання. Після цього потрібно було це повідомити клієнту і якщо він погодиться замінити товар – його замінити, а якщо не погодиться поставити в очікування щоб його забрав клієнт.
• Могло статися так, що товар робочий, просто неправильно підключили шнур живлення.
• І третій варіант – був виявлений дефект і визначена приблизна вартість. В цьому випадку потрібно було повідомити клієнту орієнтовну вартість робіт і в разі якщо він погодиться – запускати в роботу, а якщо не погодиться – поставити товар на очікування щоб клієнт його забрав.

Почала вимальовуватися схема бізнес-процесу з розгалуженнями. Що за чим іде, чому і для чого.

Для реалізації цього проекту було прийнято рішення використовувати штатний механізм системи “1С: Підприємство”, який називається “Бізнес процеси”.
З його допомогою програма самостійно просуває замовлення послуги на черговий етап бізнес-процесу.

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

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

І це далеко не повний перелік всіх процесів, які відбуваються в сервісному центрі.

Проаналізувавши всі процеси ми склали карту маршруту бізнес-процесу.

Що таке карта маршруту:

Щоб ви розуміли що таке карта маршруту, я приведу маленький приклад взятий з просторів інтернету.

Як бачите, є старт і фініш, є умови. У процесах вказана посада виконавця і описано що відбувається в цьому процесі.

У карті маршруту виявилося більш 80 елементів. Після передали карту замовнику, і пройшлися з ним по кожному елементу. У процесі з’ясувалося, що і це ще не все процеси, що є ще ряд процесів і розгалужень. Доповнили ними карту і знову передали замовнику на затвердження. Так робили кілька разів. І все одно цей варіант не став остаточним. Після того як ми запустили проект в роботу вилізло ще близько 10-15 процесів, про які замовник ні слова не сказав і, відповідно, вони не були прописані. І вже в процесі роботи ми додавали нові ділянки в карту маршруту таким чином, щоб не порушити вже діючі процеси.

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

Я приведу тут частина карти маршруту, яка вийшла в результаті.

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

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

Що отримав замовник

1 – Є інформація по кожному товару, зданого в ремонт. Система за запитом видає інформацію на якому етапі знаходиться товар. Це або тестування, або ремонт у постачальника, або чекає запчастин, або очікує клієнта і ще багато етапів. Це називається статус замовлення.

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

3 – Кожен інженер в програмі має свій набір навичок. Так, наприклад, Іванов може ремонтувати ноутбуки та монітори, Петров вміє телефони, Сидоров вміє ремонтувати принтера та роутери. Це дало можливість в інтерфейсі інженера відображати тільки ті сервісні замовлення, які він може виконувати.

4 – Інженер згідно своїх навичок в своєму інтерфейсі бачить завдання які йому необхідно виконати, і виконує їх в порядку черги.

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

6 – Програма знає який товар і скільки часу знаходиться на ремонті у постачальника. Це тепер підконтрольний процес. Можна відібрати, наприклад, товари які знаходяться на ремонті більше 2-х тижнів.

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

8 – Як тільки закінчився ремонт, менеджер приймальник бачить у себе завдання, згідно з якою він дзвонить клієнтові і оповіщає його про те що товар відремонтований, повідомляє йому ціну ремонту, каже що було зроблено і просить підійти і забрати товар і замовлення ставати в статус “Очікування повернення покупцеві “.

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