De ce esueaza proiectele e-commerce (2)
Viziunea
Se intampla ca proiectul de fapt sa fie pornit de la cerinte de genul: trebuie sa facem si noi e-commerce, “avem nevoie de un magazin online”, hai sa legam magazinul online cu fluxurile offline (omni-channel), hai sa schimbam procesatorul si sa introducem fluxuri noi de plata, etc. Si skip la toata partea de analiza si setat obiective. Obiective SMART ar zice consultantii, dar daca ne referim la articolul anterior, definirea acelui SMART depinde de partener, experienta lui relevanta pentru proiectul in care se implica. Partea de viziune nu inseamna ca am zis ca facem un magazin online, livreaza cu solutia X, foloseste platforma Y, ci obiective de business, sa zicem ca proiectul e gata, cum imi dau seama ca e gata? La ce ma uit.
Asteptari nerealiste
Cumpar solutia X ca e cea mai scumpa, si face de toate, are imagine foarte buna, m-a invitat si agentia care vrea sa o vanda/implementeze la conferinta, prezentat clienti din Fortune 500 cum au facut si au lansat in 2 luni, si Agile si alte buzzwords. Glam.
Dar, in platforma asta de fapt, ca sa importi produse, trebuie sa faci un fisier XML, pe un format insuficient documentat. Poate nu e deloc user friendly pe multe module, pentru ca de fapt alea, in general nu sunt folosite, ci clientii mai folosesc alte solutii diferite (PIM, OMS, etc). Deci acel feature din platforma, nu prea e ce iti trebuie tie.
Dar, in Romania, poate nu au nici un parter care sa aiba experienta. Sau aia pe care ii au abia acum invata. Si cand te lovesti de o situatie, trebuie sa iti gasesti o resursa talentata de prin Rusia, Cehia sau America Latina. Asta e ca anecdota aia cu a lovit cu ciocanul o data, a rezolvat si a facturat 10.000$. Sunt oameni de astia si factura e pe masura.
Asa ca, in procesul de selectie, imi setez asteptari nerealiste iar cand ajung sa implementez efectiv, ma lovesc de ce poate face efectiv.
Lipsa de flexibilitate in fluxuri
Exista uneori un stakeholder, poate in zona aia C-level, care are idei rigide, as zice. Si anume, fluxul cutare sa se faca doar asa. Platforma si restul sistemelor, nu pot face aia… ar putea face o alternativa, care livreaza un rezultat similar. Dar, decizia e pe ideea initiala. Si incepe sa apara partea de “scope creep”. Si unplanned work, de custom development. Si asta se leaga atat de partea de viziune (pentru ca de fapt conteaza rezultatul cat timp e obtinut intr-o maniera rezonabila) si partea de asteptari de la platforma (ce poate face si ce nu poate face standard — OOB).
Increderea oarba
Am incredere oarba in partener. Tot ce zice el e bine. Il las pe el sa ia deciziile, ca stie mai bine, a implementat foarte bine la altii, stie ce face. Daca el imi zice ca e ok sa fie downtime de 5 zile cand migrezi platforma, e ok. Ca doar e expert. Nu mai cer o opinie secundara, ca ce rost are. Orice feedback e respins, ca fiind hate. Poate mai bag si un atac personal, sa se invete minte, ce e cu critica asta.
Expertiza in-house
Sau mai degraba, lipsa ei. cand implementezi o platforma sau o solutie sau inlocuiesti o parte din ecosistemul folosit, e bine sa ai si expertiza in-house. Care sa fie implicati in proiect sa isi dea seama la timp daca lucrurile deviaza. Partenerul care implementeaza are vizibilitate limitata pe procese, business, etc. Ca urmare, lucrurile pot devia rapid si repunerea pe sine, inseamna unplanned work.
Lipsa automatizarii
Nu includ in proiect automatizarea unor procese, care pe parcursul proiectului sunt repetitive. Cum ar fi procesul de go-live, de exemplu. Care pare ca e one time, dar de fapt il faci de mai multe ori pe parcursul proiectului (pentru diverse medii de testare/qa/acceptanta, pentru load testing, etc). Cand iti setezi ca trebuie sa automatizezi un proces, trebuie sa documentezi clar fiecare pas si iti dai seama ce iti scapa. Prin 2012, tin minte ca am lucrat la un proiect in care am rulat de zeci de ori procesul automatizat, inclusiv cu migrarea de date (care a decalat cam cu 3 saptamani lansarea), pentru ca ori dura prea mult, ori datele nu erau consistente. Asa a cerut CTO-ul.
Lista probabil o sa mai fie continuata/completata, invatarea e un proces continuu. Am vazut multe din 2002 incoace de cand am tangeta cu platformele de comert online si din 2004 de cand am facut prima integrare cu un ERP, in timp record.
Si mai e o vorba, care poate fi adaptata: nu lasa 5 minute de citit documentatia sa te scuteasca de 18 ore de debugging. (versiunea mea de traducere)
