Компанія «ЗаДляРуху» / ATC працює у складній і дуже динамічній сфері — продажі автозапчастин. Це бізнес, де швидкість обробки даних напряму впливає на продажі, сервіс, залишки, ціни, роботу менеджерів і довіру клієнтів.
На перший погляд продаж запчастин може виглядати як звичайна торгівля: є товар, є постачальник, є покупець, є замовлення. Але в реальності ринок автозапчастин — це один із найскладніших товарних сегментів для автоматизації.
Тут величезна номенклатура, десятки й сотні постачальників, постійно змінні прайси, крос-номери, аналоги, бренди, склади, залишки, замовлення з інтернет-магазинів, дзвінки клієнтів, підбір деталей по автомобілю, швидке резервування, інтеграції, телефонія, менеджери продажу, закупівля, логістика і дуже великий потік щоденних рухів у базі.
У цьому кейсі роботи виконувалися на базі 1С УТП. Система використовувалася для операційної роботи компанії, але через масштаб даних і навантаження база почала “висіти”. При обсягах понад 500 000 SKU і приблизно 1,5 млн рядків рухів на день стандартних засобів оптимізації 1С уже було недостатньо. Потрібно було йти глибше — на рівень бази даних Microsoft SQL Server, архітектури запитів, індексів, регламентних операцій і реальної логіки роботи системи.
У результаті вдалося вирішити проблеми із зависаннями, стабілізувати роботу бази, оптимізувати критичні місця й забезпечити роботу великого товарного та операційного потоку.
«ЗаДляРуху» / ATC — це компанія, що працює із запчастинами. Для такого бізнесу ключове значення мають номенклатура, швидкий пошук товарів, актуальні залишки, коректні ціни, інтеграції з постачальниками та швидке обслуговування клієнтів.
Автозапчастини — це не товарна група, яку можна легко вести вручну. Одна деталь може мати кілька артикулів, кілька аналогів, різних виробників, різні склади, різні строки поставки, різну ціну в різних постачальників і різну маржинальність.
Якщо в компанії більше 500 тисяч SKU, то навіть звичайний пошук товару, оновлення прайсів або формування залишків стає серйозним навантаженням для системи. А якщо щодня в базі створюється близько 1,5 млн рядків рухів, то це вже не “звичайна 1С”, а високонавантажена облікова система, де кожна неефективна операція множиться на мільйони записів.
У таких умовах система або витримує темп бізнесу, або починає гальмувати сам бізнес.
Перед проєктом стояло кілька важливих задач.
Потрібно було не просто “щось підправити в 1С”, а стабілізувати роботу великої операційної системи, яка щодня обробляє значний товарний і документальний потік.
Основні задачі:
підтримати роботу 1С УТП при великій кількості SKU;
забезпечити інтеграції з різними постачальниками;
налаштувати обмін із інтернет-магазинами;
підключити та використовувати IP-телефонію в бізнес-процесах;
вирішити проблеми із зависаннями бази;
оптимізувати роботу Microsoft SQL Server;
зменшити навантаження від великих рухів у базі;
прискорити критичні операції користувачів;
забезпечити стабільність системи при великих щоденних обсягах даних;
зробити так, щоб 1С УТП не блокувала роботу менеджерів, продажів і складу.
Головна ідея проєкту — не косметичне прискорення, а реальна технічна стабілізація системи, яка працює під великим навантаженням.
Автозапчастини — це сфера, де складність починається вже з номенклатури.
У звичайному магазині товар часто має одну назву, одну ціну й один залишок. У запчастинах усе інакше. Є оригінальні номери, аналоги, замінники, бренди, кроси, сумісність з моделями авто, різні склади, постачальники, очікувані поставки, ціни в валюті, знижки, націнки, терміни доставки.
Клієнт може запитати одну деталь, а менеджер має швидко знайти кілька варіантів: оригінал, якісний аналог, дешевший аналог, товар у наявності, товар під замовлення, товар у постачальника, товар із доставкою завтра.
Якщо система працює повільно, менеджер втрачає час. Якщо менеджер втрачає час, клієнт іде до конкурента.
Тому для компанії з автозапчастинами швидкість бази даних — це не внутрішня технічна проблема. Це питання продажів.
Понад 500 тисяч SKU — це вже великий товарний масив.
Кожна позиція може мати ціну, залишок, постачальника, бренд, артикул, аналоги, історію рухів, замовлення, резерви, закупівлі, продажі й оновлення.
Коли таких позицій сотні тисяч, будь-який неоптимальний запит, невдалий індекс, зайвий перерахунок або повільна обробка починають створювати серйозне навантаження.
Система, яка нормально працює на 20 тисячах товарів, може почати “задихатися” на 500 тисячах. І це не тому, що 1С УТП “погана” сама по собі, а тому, що типові механізми часто не розраховані на такий обсяг рухів без додаткової оптимізації.
Окремий виклик — приблизно 1,5 млн рядків рухів на день.
Це дуже великий щоденний потік даних для облікової системи. Кожен рух — це запис у регістрах, таблицях, індексах, журналах, підсистемах, звітах і запитах.
На такому обсязі починають проявлятися проблеми, які на малих базах просто непомітні.
Запит, який виконувався 0,2 секунди, починає виконуватися десятки секунд.
Документ, який проводився швидко, починає зависати.
Звіт, який відкривався за хвилину, може перестати відкриватися взагалі.
Регламентна операція, яка мала виконуватися вночі, не встигає завершитися до ранку.
Користувачі починають чекати.
База починає блокуватися.
Бізнес починає нервувати.
Саме в таких ситуаціях стає зрозуміло: оптимізація на рівні “перезапустіть сервер” уже не допоможе.
Основною технічною проблемою було те, що база даних почала зависати.
Для користувачів це виглядало просто: 1С довго думає, документи не проводяться, звіти не формуються, форми відкриваються повільно, система “висить”, менеджери не можуть нормально працювати.
Але за цим стояли глибші причини: великі таблиці, важкі запити, блокування, неефективні плани виконання, індекси, статистика SQL Server, великі обсяги рухів, регламентні операції, конкуренція користувачів і фонових процесів.
У таких ситуаціях не можна лікувати симптоми. Потрібно аналізувати, де саме виникає вузьке місце: у 1С-коді, в запитах, у структурі таблиць, у регістрах, у блокуваннях, у SQL Server, у налаштуваннях сервера або в логіці бізнес-процесу.
У 1С є штатні механізми обслуговування бази, регламентні операції, тестування й виправлення, оновлення статистики, інструменти адміністрування. Але при дуже великих обсягах даних і рухів цього не завжди достатньо.
Коли база щодня отримує близько 1,5 млн рядків рухів, типові засоби можуть не встигати, працювати занадто довго або не вирішувати проблему в конкретних таблицях і запитах.
У таких випадках доводиться працювати на рівні Microsoft SQL Server:
аналізувати важкі запити;
дивитися плани виконання;
перевіряти індекси;
оновлювати статистику;
виявляти фрагментацію;
шукати блокування;
оптимізувати таблиці з найбільшим навантаженням;
розділяти важкі операції;
переглядати регламентні завдання;
прибирати зайві перерахунки;
оптимізувати критичні місця не загально, а точково.
Тобто потрібно було не просто “натиснути стандартну кнопку в 1С”, а провести серйозну технічну роботу на рівні бази даних.
Ключова частина проєкту — оптимізація на рівні MsSQL.
Було проведено ряд дій, спрямованих на стабілізацію роботи бази та зменшення зависань.
У таких проєктах особливо важливо працювати не навмання, а за логікою: спочатку знайти найважчі місця, потім зрозуміти причину, потім застосувати зміни, потім перевірити ефект.
Можливі напрями оптимізації включали:
аналіз найбільш важких SQL-запитів;
виявлення таблиць із найбільшим навантаженням;
перевірку індексів;
перебудову або реорганізацію індексів;
оновлення статистики;
аналіз блокувань;
налаштування регламентного обслуговування;
оптимізацію роботи великих регістрів;
зменшення впливу фонових операцій на користувачів;
рознесення важких операцій у часі;
контроль tempdb, пам’яті, дискової підсистеми та планів виконання.
Саме така робота дала можливість вирішити проблему зависань, коли стандартні інструменти 1С уже не давали потрібного результату.
Окремий великий блок — інтеграції з постачальниками.
У бізнесі автозапчастин постачальники постійно передають прайси, залишки, ціни, строки поставки, бренди, артикули та доступність товарів.
Якщо все це обробляти вручну, компанія швидко потоне в Excel-файлах і помилках. Особливо при асортименті понад 500 тисяч SKU.
Інтеграції дозволяють автоматично або напівавтоматично завантажувати дані постачальників, оновлювати ціни, порівнювати наявність, працювати з артикулами, підтримувати актуальність каталогу й давати менеджерам реальні дані для продажу.
Для компанії це означає швидшу реакцію на ринок. Якщо постачальник змінив ціну або залишок, система має це врахувати. Якщо товар доступний у кількох постачальників, менеджер має бачити варіанти.
Ще один важливий напрям — інтеграція з інтернет-магазинами.
Для компанії з автозапчастинами сайт або інтернет-магазин — це не просто вітрина. Це канал продажів, який має отримувати актуальні товари, ціни й залишки з облікової системи.
Якщо 1С і інтернет-магазин не інтегровані, починається дублювання: товари заводяться вручну, ціни оновлюються із затримкою, залишки не відповідають реальності, клієнт замовляє те, чого вже немає, менеджери витрачають час на перевірки.
Інтеграція дозволяє пов’язати облікову систему з онлайн-продажами. Товарна база, ціни, наявність, замовлення й клієнти можуть рухатися між системами за правилами.
Для такого масштабу SKU це критично. Пів мільйона позицій неможливо якісно підтримувати вручну в інтернет-магазині.
У проєкті також використовувалася IP-телефонія.
Для продажу автозапчастин телефон залишається дуже важливим каналом комунікації. Клієнти дзвонять, уточнюють наявність, питають аналоги, перевіряють ціну, консультуються з менеджером, замовляють деталі.
Інтеграція IP-телефонії з обліковою системою дозволяє зробити роботу менеджера швидшою й зручнішою.
Коли дзвонить клієнт, система може допомогти швидко знайти його картку, історію замовлень, попередні звернення або відповідального менеджера. Дзвінок стає частиною бізнес-процесу, а не окремою подією, яка живе тільки в телефоні.
Для продажів це важливо, бо кожна секунда на дзвінку впливає на сервіс. Якщо менеджер швидко бачить клієнта й контекст, розмова стає продуктивнішою.
У цьому кейсі 1С УТП була центром великої кількості процесів.
Через систему проходили товари, рухи, замовлення, інтеграції, постачальники, інтернет-магазини, клієнти, документи, продажі, закупівлі та інші операції.
Коли 1С у такій структурі працює повільно, це впливає не на один відділ. Це впливає на весь бізнес.
Менеджери не можуть швидко продавати.
Закупівля не бачить актуальних даних.
Інтернет-магазин отримує затримки.
Телефонні продажі сповільнюються.
Керівництво не отримує нормальну аналітику.
Користувачі втрачають довіру до системи.
Тому стабілізація 1С УТП була важливою не як технічна задача, а як умова нормальної роботи компанії.
У багатьох компаніях 1С починає працювати як звичайна облікова система. Але з часом бізнес росте, кількість товарів збільшується, інтеграцій стає більше, рухів більше, користувачів більше, а база — важчою.
На певному етапі система переходить у зону високого навантаження.
У випадку «ЗаДляРуху» / ATC це було особливо помітно через поєднання кількох факторів:
понад 500 000 SKU;
інтенсивні рухи товарів;
близько 1,5 млн рядків рухів на день;
інтеграції з постачальниками;
обмін з інтернет-магазинами;
активна робота менеджерів;
IP-телефонія;
велика кількість запитів до бази;
постійні операції оновлення цін, залишків і документів.
У такому режимі база даних стає критичним елементом бізнесу. Якщо вона зависає — зависає все.
У межах робіт було виконано комплекс дій, спрямованих на стабілізацію системи.
Йшлося не про одну “чарівну кнопку”, а про послідовну технічну роботу:
аналіз причин зависань;
пошук найважчих операцій;
дослідження навантаження на Microsoft SQL Server;
аналіз великих таблиць і регістрів;
робота з індексами;
оптимізація статистики;
виявлення проблемних запитів;
оптимізація регламентних операцій;
перегляд логіки інтеграцій;
зменшення пікових навантажень;
стабілізація роботи 1С УТП;
підтримка інтеграцій із постачальниками та інтернет-магазинами;
покращення роботи користувачів.
Саме комплексність дала результат. Бо при таких обсягах проблема рідко буває в одному місці. Зазвичай це сума накопичених факторів, які разом створюють зависання.
Ефект був досягнутий тому, що оптимізація виконувалася не тільки на рівні 1С, а й на рівні MsSQL.
Штатні механізми 1С можуть бути корисними, але вони не завжди бачать реальну картину так, як її бачить SQL Server: плани виконання, блокування, індекси, статистика, фізичне читання, tempdb, очікування, навантаження на диски.
Коли робота ведеться на рівні бази даних, можна точніше визначити, що саме створює зависання. Іноді проблема не в самій формі 1С, а в запиті, який читає занадто багато рядків. Іноді — в індексі. Іноді — в застарілій статистиці. Іноді — в блокуваннях. Іноді — в тому, що важка інтеграція запускається в момент активної роботи користувачів.
Після таких дій система починає працювати стабільніше, бо усуваються реальні вузькі місця.
Для «ЗаДляРуху» / ATC результат мав практичне значення.
Коли система перестає зависати, бізнес отримує не просто технічну стабільність. Він отримує швидшу роботу менеджерів, менше нервів у користувачів, кращу обробку замовлень, актуальнішу інформацію, стабільні інтеграції й можливість працювати з великим асортиментом без постійного страху, що база знову “ляже”.
У бізнесі автозапчастин це особливо важливо, бо клієнт не чекає довго. Якщо менеджер не може швидко знайти деталь, перевірити ціну й оформити замовлення, клієнт піде до іншого продавця.
Стабільна система — це конкурентна перевага.
У результаті було виконано комплекс робіт із підтримки, інтеграції та оптимізації 1С УТП для компанії «ЗаДляРуху» / ATC.
Рішення охоплювало:
роботу з 1С УТП;
підтримку великої номенклатури понад 500 000 SKU;
інтеграції з різними постачальниками;
інтеграції з інтернет-магазинами;
підключення та використання IP-телефонії;
аналіз проблем зависання бази;
оптимізацію на рівні Microsoft SQL Server;
роботу з великими обсягами рухів — близько 1,5 млн рядків на день;
оптимізацію індексів, статистики, важких запитів і регламентних процесів;
стабілізацію роботи бази;
вирішення проблем із зависаннями;
покращення роботи користувачів і бізнес-процесів.
Кейс «ЗаДляРуху» / ATC — це приклад того, що справжня автоматизація великого торгового бізнесу не закінчується встановленням 1С.
Коли компанія працює з понад 500 тисячами SKU, має інтеграції з постачальниками, інтернет-магазинами, IP-телефонією і генерує близько 1,5 млн рядків рухів на день, система стає високонавантаженою. У такій ситуації звичайні штатні інструменти оптимізації вже не завжди можуть врятувати базу від зависань.
Потрібна глибока робота: аналіз SQL Server, індекси, статистика, важкі запити, блокування, регламентні операції, інтеграції й реальна поведінка користувачів.
Саме такий підхід дозволив вирішити проблеми із зависаннями й повернути системі стабільність.
Це кейс про те, що іноді головна автоматизація — це не нова красива форма, а те, що база перестає падати під навантаженням, менеджери можуть працювати без пауз, інтеграції не душать систему, а бізнес знову отримує швидкість, контроль і впевненість у своїй операційній платформі.
Українська 
English
Poland