RM і Profiline: автоматизація продажів і перехід на нову платформу :: Shopolog.ru

1. Труднощі перехідного періоду
2. Кожному - своя ціна
3. марафон даних
4. Оформлення та дизайн
5. Покупці бувають різні
6. Загальна структура порталу
7. вместо Післямови

Розробка B2B платформи + двостороння інтеграція і настройка 1С. Автоматизація процесу продажів і документообігу з дилерською мережею для найбільшого постачальника витратних матеріалів для офісної техніки.

«А що складного? Просто намалюйте гарний дизайн, закиньте туди наші товари, а вже далі ми займемося основною проблемою - продажами ». Я часто згадую цю фразу, яку давним-давно сказав мені один приятель. Він шукав «коробочки» рішення і вважав, що головна проблема при створенні оптового інтернет-магазину - це вибрати кольору, в яких буде виконана його головна сторінка, а далі все робиться натисканням «однієї кнопки».

В реальності постає безліч проблем, частина з яких загальні, частина - специфічні для кожного окремого оптового клієнта. Сьогодні я розповім про те, як ми в e-Commerce агентстві Compo справлялися з проблемами на одному з наших проектів.

До нас звернулася компанія RМ, це один з провідних оптових продавців картриджів, тонерів та інших витратних матеріалів для офісної техніки. Крім того, компанія виробляє витратні матеріали бренду Profiline.

На момент початку проекту компанія входила в топ-5 оптових постачальників на Російському ринку, і однією з основних причин для створення B2B-платформи було збільшення обсягу ринку і вихід в топ-3. Крім того, за допомогою нового майданчика в компанії хотіли підвищити ефективність роботи менеджерів відділу продажів. Та й взагалі, клієнти стають молодшими, більш вимогливим, їм простіше купувати онлайн, а не через менеджерів.

Цікаво, що для компанії це була друга спроба запустити B2B-платформу. Перша (4 роки тому) виявилася невдалою через неоптимального інтерфейсу і регулярних технічних проблем.

На етапі первинних переговорів нам показали портали конкурентів з проханням повторити і зробити краще.

Після переговорів були сформульовані дві основні задачі:

• частково автоматизувати і тим самим спростити роботу співробітникам відділу продажів;
• дати клієнтам зручну платформу;

Вивчивши запропоновані замовником проекти, ми зрозуміли, що зробити портал краще за інших ми просто зобов'язані. Функціонал, пропонований конкурентами, був досить вузький. По суті він обмежувався можливістю переглядати асортимент і робити замовлення за цінами, закріпленим за контрагентом. Мало того, реалізовано це було на архаїчних платформах, які не задовольняють сучасним вимогам ні за зовнішнім виглядом, ні за зручністю роботи. На конкуруючих сайтах навіть не було можливості фільтрувати каталог товарів, чого вже про говорити, наприклад, про автоматичні підказках при пошуку за назвою.

Приятель, якого я згадував на самому початку статті, був би дуже здивований, якби дізнався, що з технічної точки зору основна проблема при створенні B2B-платформи з самим порталом, власне, майже не пов'язана. В першу чергу потрібно налагодити автоматичне отримання даних з облікової системи постачальника (як правило це 1С).

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

Розповім про основні проблеми, з якими ми зіткнулися на проекті і про методи їх вирішення.

Труднощі перехідного періоду

Головна проблема, яка виникла перед нами з самого початку була пов'язана з тим, що початок робіт над порталом збіглося за часом з переходом компанії РМ зі старою версією 1С: Підприємство 7.7 на нову, реалізовану «з нуля» на основі бібліотеки стандартних підсистем, конфігурацію на платформі 1С: Підприємство 8.3. Не секрет, що можливості цих платформ так сильно відрізняються, що переходом на 8.3 зараз займається більшість магазинів, що працюють з 1С: Підприємство ..

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

Нами було запропоновано архітектурне рішення при якому портал передбачає наявність спеціальної «прокладки», яка може працювати відразу з двох баз, їй все одно, звідки брати інформацію. Завдяки цьому прошарку вирішується проблема дублювання даних: вся нова інформація вноситься відразу в нову базу, а не в обидві, як довелося б робити, якби ми скористалися стандартної архітектурою.

Переваги такої архітектури в наступному:

1. З'являється можливість запустити B2B-портал до повного переходу на нову систему 1С: Підприємство
2. Вирішується питання перенесення даних, необхідних для старту роботи нової системи 1С: Підприємство, який в будь-якому випадку необхідно було вирішувати
3. Менеджери, частково працюючи в новій системі, знайомляться з її інтерфейсом і механізмами, мають можливість відпрацювати і протестувати бізнес-процеси на реальних даних і замовленнях ще до переходу на нову програму, що істотно полегшує момент переходу
4. Виключається необхідність вносити одні і ті ж дані в різні програми

Обмін між 1С 7.7 і 1С 8.3 реалізований за допомогою зовнішніх джерел даних, що дає переваги в швидкості, завантаженості і надійності перед класичним перенесенням через правила обміну.

Кожному - своя ціна

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

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

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

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

Довелося розробити спеціальний модуль, що дозволяє на кожну категорію товару встановлювати для кожного клієнта свою колонку цін і відсоток знижки / націнки до неї. Це закривало 95% роботи з цінами для контрагентів. Крім того для кожної конкретної позиції була створена можливість вказати спеціальну ціну, яка, в разі конфліктів, має пріоритет перед іншими типами цін. Цим ми закрили решта 5% випадків, коли на конкретну позицію конкретному контрагенту потрібно встановити ціну з точністю до копійки.

Мало того, частина клієнтів компанії РМ працюють за кількома договорами, умови роботи і ціни за якими можуть відрізнятися. Нами була створена можливість задавати індивідуальні ціни не тільки для клієнта, але і для будь-якого його договору.

Вартість продукції прив'язана до курсу валют. Не секрет, що деякі великі замовники в цій частині також висувають свої умови роботи. Тому для кожного клієнта реалізована можливість завдання індивідуального курсу, за якими відбувається розрахунок цін, або відсотка націнки на курс ЦБ. Це дозволило менеджерам виставляти менші ціни, але по більшій курсу (або навпаки), що підвищило гнучкість ціноутворення компанії.

марафон даних

Налагоджений обмін даними - ця одна з ключових складових успішного порталу. На цьому етапі практично завжди виникає якась проблема, з якою треба боротися. В даному випадку на порталі використовуються відразу 14 типів даних, які треба було співвіднести між собою!

Ось ці типи даних:

• Холдинги (група юросіб, які представляють собою фактично одного клієнта);
• Контрагенти (довідник з реквізитами)
• Договори (повна інформація про сторони договору і типі цін в ньому);
• Список типів цін
• склади
• Категорії сайту (для перегруповування номенклатури, структура каталогу в 1С і на сайті не збігається)
• Категорії 1С (для тієї ж мети)
• Номенклатура (власне товари з характеристиками)
• Ціни (значення цін)
• Залишки (з урахуванням резервів)
• категорії користувачів
• Фінанси (дані про дебіторську заборгованість)
• Менеджери (окремий список дозволених користувачів порталу)
• Індивідуальні ціни (ті самі персональні ціни на конкретну позицію)
• Регіони (перелік регіонів, в яких працюють контрагенти, використовується для прив'язки складів)

Повний обмін даними про асортимент, як правило відбувається раз на добу в нічний час, оскільки вимагає перекачування великого обсягу даних. І проблема полягала в тому, що синхронізація цих даних повинна йти в певній черзі. Типовий приклад: коли ми синхронізуємо дані юридичних осіб, то треба розуміти, що всі вони прив'язані до різних холдингам або клієнтам. А це означає, що вся інформація про холдинги до цього моменту повинна бути завантажена. Але кожен з цих типів даних містить різний обсяг інформації. У свою чергу, програми, які синхронізують різні види даних, працюють різні часи, причому різниця суттєва. І нам потрібно було налаштувати таку черговість і розклад, щоб все нормально синхронізувати. Все б нічого, але синхронізація під різними навантаженнями сервера працює по-різному: з різницею мало не в кілька хвилин.

Нам довелося придумувати рішення, яке дозволяє враховувати всі ці затримки.

«Рішенням в нашому випадку є використання додаткового компонента Symfony process component -який дозволяє виконувати команди синхронізації в потрібній черзі дочекавшись виконання попередньої синхронізації. Таким чином розклад синхронізації звелося до одного єдиного запуску процесу, який в свою чергу вже управляє синхронізацією даних в потрібному порядку, при цьому гарантує чітку черговість виконання », - розповідає технічний директор Compo Володимир Гантурін.

Ну і, звичайно, треба було так вибудувати синхронізацію, щоб збоїв не було і вона займала б якомога менший час. У підсумку повне завантаження даних - близько 600 000 записів синхронізується 7-9 хвилин, в залежності від навантаження.

Приклад. Синхронізація контрагентів на досить слабкому тестовому сервері за допомогою автоматичної консольної команди. 6858 контрагентів з усіма даними синхронізуються за 15 секунд.

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

На рівні 1С запущені WEB-сервіси, що дозволяє порталу самому бути ініціатором обміну. Такий метод дозволяє порталу отримувати необхідну інформацію тоді, коли це необхідно, що полегшує і прискорює обмін.

Дані обміну являють собою окремі отримані елементи в форматі json. Механізм відправки даних на портал працює наступним чином:

1. Портал відправляє запит, який містить в собі вказівку на тип вивантаження, і, при необхідності додаткові відбори. Наприклад, для контрагентів є можливість вказати ідентифікатор окремого клієнта і тоді у відповідь прийде інформація тільки по цьому користувачеві. Це дозволяють зробити обмін «точковим», що сприятливо позначається на швидкості оновлення інформації і на завантаженості бази 1С.
2. 1С, отримавши запит, формує необхідні файли даних і передає їх назад на B2B-портал. При цьому, в разі повного вивантаження на порталі відбувається очищення неактуальних даних, при частковій вивантаженні (застосовані будь-які з відборів) дані тільки доповнюються. Це дозволяє уникнути накопичення «сміття» на порталі.

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

Оформлення та дизайн

Покупці бувають різні

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

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

Тому ми відмовилися від традиційної каталожної структури, замінивши її параметричних пошуком, в якому можна в тому числі вказувати розділ каталогу, в якому буде шукатися товар. Наприклад, коли шукаєш картридж для принтера «samsung SCX-3400», то можна шукати товар, виходячи з моделі принтера, артикулу та інше. А можна просто вбити цифри «3400», і він видасть потрібний картридж.

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

Наприклад, ви робите закупівлі для офісу і часто купуєте один і той же набір товарів. Частіше за все ви не пам'ятаєте напам'ять назви всіх принтерів та іншої техніки. Для таких замовників ми ввели додаткові способи підбору товару. Наприклад, система автоматично формує список з останніх замовлень. Так що якщо користувач пам'ятає, коли замовляв потрібний йому зараз картридж, він знайде його там.

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

Нарешті є B2B-контрагенти, які взагалі не оперують товарними назвами, типу «картридж для samsung SCX-3400». В їх документації вказані внутрішні унікальні ідентифікатори (UID-коди) товару. Для таких клієнтів нами були розроблені відповідні інструменти підбору по UIDу і частини UIDа. Крім того, є можливість завантаження Excel-файлу з кодом товару і кількістю. При завантаженні на сайт такого файлу - з його даних формується кошик.

Крім того, перед початком підбору номенклатури користувач вказує наступні дані:

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

Але замовники відрізняються не тільки за величиною. У зв'язку з цим теж виникають складнощі. Наприклад, для частини контрагентів ми включили автоматично настроюється відображення валюти.

Є ситуації і складніше. Не всім контрагентам постачальник хоче показувати точний наявність. Тому частина з них бачать залишки як «багато-мало-мало», при цьому зарекомендували себе партнерам показуються фактичні залишки в штуках по потрібним складах.

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

Спеціально для оптовиків довелося поміняти і модуль з рекламаціями. Знову ж таки, ми зіткнулися зі специфікою товару. Картриджі - це товар, який коштує не дуже багато, купується великими партіями і має різні артикули. І якщо покупець з якоїсь причини хоче повернути партію, то йому при відправленні претензії до компанії, зазвичай треба переписувати і звіряти безліч артикулів, кожен з них вносити в рекламацію і кілька разів перевіряти, щоб не було помилок, прикріплювати фотографію товарів. Тому було вирішено спростити форму відправлення претензії, обмеживши її двома полями - номер замовлення / накладної (вибирається зі списку замовлень) і вільне поле з описом проблеми. Оскільки в даному проекті рекламації не передаються порталом в 1С, а відпрацьовуються менеджерами в адміністративній частині порталу, всі спірні питання простіше прояснити в чаті з менеджером.

Загальна структура порталу

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

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

вместо Післямови

Ви повірите шахраєві, який скаже, що у нього є таблетка, моментально допомагає від усього на світі? Скоріш за все ні. Люди, які говорять, що їх коробочки рішення не вимагає додаткових витрат, встановлюється за кілька кліків і відразу дає результат, по суті, такі ж шахраї. Проблеми обов'язково будуть. Я розповів лише про декілька. Не факт, що в наступному проекті не з'явиться якогось свого набору. Однак результат того, звичайно ж, варто.

Про компанію РМ

• РМ (виробник продукції для друку під відомим брендом Profiline) - одна з провідних компаній Росії, що займаються оптовими поставками картриджів, тонерів та іншими расходниками для офісної техніки.
• Працює з 1996 року
• Дилерська мережа компанії - понад 2000 партнерів
• Працює в 300 містах Росії і країнах СНД
• У компанії працює більше 180 чоловік
• Склади - більше 30 000 метрів