Онлайн магазинът продава. Защо тогава всяка промяна става по-скъпа?

Поръчките се увеличават, но екипът все по-трудно ги обработва. Компанията иска да започне продажби в друга държава, а подготовката изисква промени в почти всички системи. Добавянето на нов доставчик изглежда като малка задача, докато не се стигне до продуктовите данни, наличностите и цените.

За собственика това често води до въпроса дали онлайн магазинът вече е изчерпал възможностите си. Отговорът зависи от нещо повече от възрастта на сайта или името на платформата.

Разговаряме с Виктор Генчев, съосновател на дигиталната агенция Viste, чийто екип работи по разработка и развитие на OpenCart магазини, персонализирани функционалности и интеграции с бизнес системи.

Клиент идва при вас и казва: „Магазинът вече не ни върши работа, искаме нов“. Откъде започвате?

Питаме го какво точно не успява да направи. „Не ни върши работа“ може да означава много различни неща. Магазинът зарежда бавно. Продуктите се обновяват трудно. Служителите пренасят поръчки ръчно. Или бизнесът иска да продава на друг пазар, а сегашната организация не го позволява.

След това разглеждаме самия проект: състоянието на платформата, модулите, индивидуалните разработки и интеграциите. Успоредно с това разпитваме клиента за плановете му. Какво иска да промени сега и какво очаква да се случи с бизнеса?

Без този разговор можем да направим технически изряден магазин, който пак да затруднява хората. Ако проблемът е в начина, по който се подават наличностите, той няма да изчезне само защото сме сменили дизайна или платформата.

Понякога анализът показва, че съществуващият магазин може да се развие. В други случаи има основания за по-сериозна промяна. За нас е важно да можем да обясним защо предлагаме едното или другото.

Къде се натрупват разходите, които собственикът трудно вижда в началото?

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

Тази работа рядко присъства в бюджета за сайта. Собственикът я вижда по-късно като необходимост от още хора, забавяне при натоварване или трудност да обучи нов служител.

Има и друг разход: колко усилие изисква следващата промяна. Ако добавянето на една функция налага проверки и корекции на много други места, развитието постепенно се оскъпява. Тогава дори разумни бизнес идеи започват да се отлагат.

Затова при оценката на проекта гледаме как се работи с него ежедневно и как може да се променя. Началната цена е само част от тази картина.

Как изглежда подобно развитие в реален проект?

С Linson Moto започнахме от изграждането на онлайн магазина и след това постепенно развивахме системата заедно с бизнеса.

В началото задачата е да има работещ магазин. С времето идват повече изисквания към каталога, обслужването и обработката на поръчките. После се появяват нови канали за продажба и чужди пазари. Всяка от тези стъпки поставя различни задачи пред екипа и софтуера.

При този проект разработихме собствен софтуер за управление на складовите процеси — WMS, свързан с OpenCart магазините. Работихме и по интеграции с маркетплейси, куриери и платежни услуги, както и по автоматизации на ежедневната работа. Това помогна за по-бърза и лесна обработка на поръчките, подобряване на вътрешните процеси и разширяване на бизнеса на чужди пазари.

Това не беше една голяма разработка, поръчана изцяло в първия ден. Нуждите се появяваха и уточняваха във времето.

Точно затова дългосрочното познаване на проекта е ценно. Когато клиентът поиска нова интеграция, трябва да разбираме как тя ще се отрази на наличностите, поръчките и работата на служителите. Самото свързване на две системи е само част от задачата.

Какво е необходимо, за да може един OpenCart магазин да обслужва по-сложен бизнес?

Трябва да се реши къде ще се управлява всяка част от работата.

Продуктовата информация, наличностите и движението на стоката са свързани, но са различни задачи. При един бизнес е достатъчно голяма част от тях да се управляват през магазина. При друг има система за управление на ресурсите на предприятието, позната като ERP, отделен складов софтуер, много доставчици или специфични условия за продажба.

OpenCart дава възможност да разработваме индивидуални функции и да свързваме тези системи. Но свободата да добавяме код не означава, че всяка нова задача трябва да бъде решена вътре в платформата.

Някои функции се реализират добре с готов модул. За други е необходима собствена разработка. При складови операции например може да има основание за отделен софтуер, който обменя информация с магазина. Изборът зависи от процеса, натоварването и бъдещата поддръжка.

Важни са и ситуациите, в които нещо се обърка. Какво става, ако външната система не отговори? Кой вижда, че синхронизацията е спряла? Как се възстановява обменът на данни, без да се пропуснат или дублират поръчки?

Отговорите помагат да преценим кога OpenCart е подходящ за сложен онлайн магазин и как да организираме конкретната реализация. Платформата е основата; качеството на проекта зависи и от решенията около нея.

Как разбирате дали си струва да надградите съществуващия магазин, или е време за миграция?

Гледаме каква част от сегашното решение може надеждно да обслужва следващите цели на бизнеса.

Ако проблемът е ограничен — например определена интеграция, бавна операция или неудобна администрация — има смисъл първо да оценим възможността да го решим. Не е нужно всеки недостатък да води до нов магазин.

При натрупани несъвместими промени, трудна поддръжка или сериозно разминаване с бъдещите изисквания може да се наложи преизграждане. То не означава непременно смяна на платформата. Понякога е нужна нова реализация върху същата платформа, а в други случаи е по-разумно да се премине към различно решение.

Когато се налага миграция, тя включва много повече от прехвърляне на продукти. Има клиентски данни, история на поръчките, връзки с други системи и адреси на страници. Трябва да се планират пренасочванията, проверките преди старта и подготовката на екипа за работа с новото решение.

Затова бих бил внимателен към предложение за смяна на платформата, направено преди изпълнителят да е разбрал какво затруднява бизнеса. Собственикът трябва да получи аргументи: какво запазваме, какво променяме, какви рискове има и как предложението обслужва плановете му.

Какво може да направи собственикът, за да вземе по-добро решение, без самият той да е технически специалист?

Да опише няколко реални ситуации от работния ден и да поиска изпълнителят да обясни как ще се обработва всяка от тях.

Какво се случва с поръчката, ако един от продуктите липсва? Как се обновяват цените от доставчик? Какво ще трябва да правят служителите, когато започнат продажби в още една държава? Отговорите разкриват много повече от списък с имена на интеграции.

Бих го посъветвал и да поиска ясно разграничение между това, което влиза в проекта, и това, което остава ръчна работа. Понякога двете страни смятат, че са се разбрали, защото в офертата пише „интеграция със склад“, но си представят различни процеси.

Накрая трябва да уточнят как ще проверят дали инвестицията е помогнала. При обработката на поръчки могат да следят времето и необходимите ръчни действия. При каталога — усилието за обновяване и грешките. Ако целта е нов пазар, трябва да е ясно как екипът ще го обслужва.

Това е разговорът, който искаме да проведем още в началото. „Искаме нов сайт“ е отправна точка. За да предложим смислено решение, трябва да стигнем до това как хората ще работят с него в понеделник сутрин.