Tiešsaistes pasūtījums no klienta puses izskatās vienkāršs. Izvēlieties preci, samaksājiet, izvēlieties piegādi vai paņemšanu. Aiz tā mazumtirgotājs, iespējams, pārbauda noliktavu, divus veikalus, ERP, maksājumu pakalpojumu un atsevišķu pasūtījumu sistēmu, pirms tiek parādīta apstiprinājuma lapa.
Lielākā daļa mazumtirdzniecības skursteņu netika izstrādātas uzreiz. Šī sadrumstalotība ir viens no iemesliem, kāpēc mazumtirgotāji turpina ieguldīt platformas, kas paredzētas krājumu un pārdošanas pārvaldībai vairākos kanālos. Tur jau bija POS sistēma. E-komercija ieradās vēlāk. Pēc tam tika pievienota lojalitāte. Mazumtirgotāji arvien vairāk cenšas savienot šīs tiešsaistes un veikalu sistēmas vienā daudzkanālu darbībā.
Tā ir īstā daudzkanālu problēma. Nevis “izmantojot vairākus kanālus”, bet saglabājot to pašu pasūtījumu, klientu, cenu un krājumu stāvokli, kamēr šie kanāli turpina nodot datus viens otram.
1. Ģēnijs
Pieņemsim, ka mazumtirgotājs vēlas jaunu mobilo lietotni. Labi. Pati lietotne var nebūt sarežģītā daļa.
Tam joprojām ir nepieciešami produkta dati no kaut kurienes. Droši vien Stock dzīvo kaut kur citur. Klientu vēsture var būt no CRM. Veikala saņemšanas pasūtījumam ir jānonāk pareizajā vietā, jārezervē prece, jāpārdzīvo atcelšana un pēc tam jāatjaunina klienta konts, kad pirkums ir pabeigts.
Geniusee strādā ap šo slāni, izmantojot to mazumtirdzniecības programmatūras izstrādes pakalpojumi. Projekts var ietvert klientiem paredzētu programmatūru, taču tikpat viegli tas var būt aiz tā esošās sistēmas vai savienojumi starp programmatūru, ko mazumtirgotājs jau izmanto.
Mazumtirgotājs var atrast krājumu problēmu visstulbākajā iespējamajā veidā: kāds tiešsaistē nopērk pēdējo pāri, kamēr kasiere to jau skenē veikalā. Nekas nav avarējis. Vietne vienkārši saņēma atjauninājumu dažas sekundes par vēlu. Pievienojiet saņemšanas rezervāciju, ERP ar savu daudzumu, un pēkšņi ir trīs atbildes uz ļoti vienkāršu jautājumu: vai prece joprojām ir tur?
Atgriešana rada citu haosu. Atgriešanās var atklāt, cik atvienotas sistēmas patiesībā ir. Veikals pieņem preci, bet atmaksa var tikt reģistrēta pirms krājumu labošanas, savukārt lojalitātes punkti paliek neskarti, līdz to panāk cita sistēma. Cenu noteikšana izraisa tādas pašas nesaskaņas, ja vietnei ir jaunāks piedāvājums nekā POS.
Arī iekšējie rīki ne vienmēr ir vienkārši. Ekrāns, kurā tiek rādīti tikai izmēri vai tiek nosūtīts noliktavas pieprasījums, joprojām var būt atkarīgs no aktuālajiem krājumiem, produktu datiem un jebkuras jau esošās veikala programmatūras. Ja viena plūsma ir novēlota, ekrāns var izskatīties labi, vienlaikus sniedzot nepareizu atbildi.
2. Pāreja
Parasti dažām sistēmām ir grūti pieskarties.
Varbūt ERP ir vecs, bet finanses ir atkarīgas no tā. POS ir neglīts, bet katrs veikals zina, kā to izmantot. Produktu plūsmas no piegādātājiem tiek saņemtas vairākos formātos. Noliktavas sistēma tiek nomainīta, tikai ne šogad. Pat pamata POS un e-komercijas integrācija var ietvert krājumu, pasūtījumu, atgriešanas un klientu datu pārvietošanu starp sistēmām
Tad kāds lūdz universālo kanālu.
Tajā brīdī izstrāde galvenokārt ir saistīta ar viena gabala nomaiņu, nepārtraucot pārējo bezsaistē.
Vecajām un jaunajām sistēmām kādu laiku var nākties darboties blakus. Pasūtījumi nevar pazust, kamēr tiek pārvietoti ieraksti. Produktu ID ne vienmēr sakrīt. Klientu vēsturē var būt nepilnības. Veikala krājumus var atjaunināt pēc cita grafika nekā e-komercija, lai gan krājumu redzamība reāllaikā ir pamats no daudzkanālu mazumtirdzniecības.
Itransition ir pieredze ar pielāgotām mazumtirdzniecības sistēmām un lielākām platformām, kas tiek izmantotas saistībā ar tirdzniecību, CRM, ERP, krājumiem un veikala darbībām. Projekti šajā vidē var ietvert tādas lietas kā:
- Veco ierakstu kartēšana jaunā datu modelī;
- Darījumu uzturēšana migrācijas laikā;
- E-komercijas savienošana ar piegādātāju vai noliktavu sistēmām;
- Produkta informācijas dublikātu labošana;
- Vienas integrācijas aizstāšana, atstājot pārējo steku atsevišķi.
Itransition darbojas ar pielāgotu mazumtirdzniecības programmatūru, kā arī platformām, kas tiek izmantotas saistībā ar ERP, CRM, tirdzniecību, krājumiem un veikala darbībām. Tāpēc projektā var būt iekļauta programmatūra, kas paliek neskarta līdzās citam komponentam, kas tiek pilnībā nomainīts.
Liela daļa migrācijas darbu notiek detaļās, kuras neviens neredz. Divas sistēmas vienu un to pašu lauku var saukt ar dažādiem nosaukumiem. Noliktavā izmantotais produkta ID var nesakrist ar e-komercijā saglabāto. Vēsturiskie pasūtījumi var būt pilnīgi vienā datu bāzē un trūkstošie lauki citā.
Šis darbs var būt sāpīgi ikdienišķs. Komandas var pavadīt vairākas dienas, vienojoties par to, kurai datu bāzei pieder viens lauks, pirms kāds pieskaras lapai, kas to izmanto.
3. Vention
Vention ir piemērota citai situācijai: mazumtirgotājam jau ir tehniskie vadītāji, produktu vadītāji un arhitektūra, kuru tas neplāno aizstāt.
Problēma ir kapacitāte.
Kase tiek pārbūvēta. Mobilais telefons atpaliek no grafika. Maksājumu migrēšana pēkšņi ir kļuvusi steidzama. Aizmugursistēmas inženieri ir aizņemti ar klientu kontiem, un QA tagad ir iesaistīta trīs laidienos vienlaikus.
Vention šādam projektam atbilst atšķirīgi. Tas ļauj mazumtirgotājam pievienot inženierus norēķinu komandai, mobilajai komandai vai aizmugursistēmas straumei, nenododot visu tirdzniecības grupu.
Tas var nozīmēt backend palīdzību vienā gada daļā un mobilos inženierus citā. Vai papildu kvalitātes nodrošināšana, kamēr vairākas savienotās sistēmas mainās vienlaikus.
Modelis lielā mērā ir atkarīgs no tā, vai mazumtirgotājs zina, ko tas vēlas uzbūvēt. Vairāk inženieru nenovērš neskaidras īpašumtiesības, sliktu arhitektūru vai piecas komandas, kas pieņem pretrunīgus lēmumus.
4. ScienceSoft
Pasūtījumu maršrutēšana var ātri kļūt neglīta. Tuvākajā noliktavā var būt krājumi, taču tā joprojām ir nepareiza izvēle, ja ņemat vērā piegādes izmaksas. Tuvākā veikalā, iespējams, tiek glabātas dažas pēdējās vienības, lai saņemtu pieprasījumu, savukārt citā vietā ir krājumi, bet rinda ar pasūtījumiem. Klients izvēlas piegādi nākamajā dienā.
Tagad reiziniet to ar vairākiem reģioniem. ScienceSoft mēdz parādīties šajā back-office slānī, kur krājumi, maršrutēšana, integrācijas, ziņojumi un infrastruktūra skar vienu un to pašu darījumu. Nelielas noteikumu izmaiņas var pārņemt vairākas darbības komandas.
Liela vide arī padara migrāciju lēnāku.
Vecā sistēma var palikt darbināta, kamēr tikai daļa satiksmes tiek pārvietota uz nomaiņu. Vēsturiskajiem pasūtījumiem ir jāpaliek pieejamiem. Dažas integrācijas tiek nekavējoties aizstātas. Citi izdzīvo mēnešus, jo no viņiem joprojām ir atkarīga cita nodaļa.
Risks ir sadalīts visā biznesā. Slikts krājumu atjauninājums sasniedz veikalu. Maršrutēšanas problēma tiek izpildīta. Maksājumu problēma sasniedz atbalstu un finanses, pirms izstrādātāji ir pabeiguši žurnālu lasīšanu.
Nekam par to nav vajadzīgs spilgts interfeiss.
Pirms izvēlaties uzņēmumu
Nesāciet ar pārdevēja komplektu. Sāciet ar vienu reālu pasūtījumu. Izsekojiet vienam pirkumam no produkta lapas līdz samaksai, izpildei un atgriešanai. Pierakstiet katru sistēmu, kas nolasa vai maina secību. Pēc tam atkārtojiet vingrinājumu saņemšanai, atcelšanai un atgriešanai veikalā.
Daži jautājumi parasti atklāj faktisko darbu:
- Kurai sistēmai pieder inventārs;
- kur vispirms tiek rediģēta informācija par produktu;
- Cik ātri uzglabā un e-komercijas apmaiņas akciju datus;
- vai tiešsaistes pirkumi ir redzami POS;
- Kam pieder cenu noteikšanas un veicināšanas noteikumi;
- Kā tiek maršrutēti pasūtījumi, ja krājumi ir vairākās vietās;
- Kura vecā sistēma paliek neatkarīgi no tā.
Izpildiet vienu pasūtījumu pietiekami tālu, un projekta spīdīgā daļa var ļoti ātri pazust. Jūs atklājat, ka krājumu plūsma kavējas, atgriešana ir manuāli jālabo, vai vecs POS savienojums ir aizlāpīts tik daudz reižu, ka neviens vairs nevēlas tai pieskarties.
