Webwinkel voor 'moeilijke' producten

[wizzkizz]

Een familielid van me is een aantal jaren geleden een eigen zaak gestart en daarvoor heb ik destijds de webwinkel gemaakt (op zakelijke basis, werkt prima). Nu zijn we een aantal jaren verder en ondanks dat de site voor de belangrijkste functionaliteit voldoet, is er toch een wens om een aantal grote wijzigingen aan te brengen in met name de beheerderskant. Ook moet er meer 'gecommuniceerd' gaan worden, dat wil zeggen met resellers en het boekhoudpakket.

Volgens mij kun je met wat eigen modules hiervoor goed terecht bij de bekende grote open-bron webwinkels. Het grootste probleem hiervoor wordt echter gevormd door de producten die verkocht worden, deze hebben behoorlijk afwijkende verkoopspecificaties. Per product zijn er namelijk tot 8 verschillende 'sales units':
- Rond met een vaste diameter
- Rond met een variabele diameter
- vaste lengte en vaste breedte
- variable lengte en vaste breedte
- variable lengte en variable breedte
- per stuk
- een aantal variaties hierop die technisch gezien niet afwijken

En dit levert voor mij een uitdaging op. Want wellicht is het mogelijk om met wat creatief modwerk in de in veel pakketten aanwezige mogelijkheid om opties mee te geven aan producten deze producten nog wel verkopen, maar er een adequaat voorraadbeheer op na houden lijkt me aanzienlijk grotere aanpassingen vergen.

Deze moeilijke producten zijn niet de enige requirements, ook:
- gebruikersvriendelijk
- voorraadbeheer
- koppeling met boekhoudpakket, verregaande integratie
- automatisering reselling
- coupons/kortingscodes (op product en orderniveau, al of niet gekoppeld aan een klant, sommige acties van klanten leiden automatisch tot het verkrijgen van een coupon)
- rechten individueel in te stellen
- meertaligheid
- validatie formuliervelden afhankelijk van land van bestemming
- apart afleveradres met cadeauoptie (dan dus geen factuur erbij en een persoonlijke boodschap of eventueel anoniem), maar alleen wanneer met iDeal betaald wordt (met natuurlijk weer de uitzondering dat voor betrouwbare klanten de cadeauoptie ook mogelijk is bij op rekening kopen)
- zo veel mogelijk integratie met de aanvraagsystemen van de pakketdiensten voor semi-automatisch aanmelden en het versturen van track&trace informatie
- nog een aantal andere (meer of minder) triviale vereisten

Ik heb me redelijk geörienteerd op reeds verkrijgbare systemen, maar volgens mij moet ik bij bestaande systemen zoveel inlezen en aanpassen en is er voor de meeste pakketten best wel een leercurve, dat het qua tijd en kosten niet veel gaat uitmaken of ik de huidige site ga refactoren of dat ik een open-bron pakket vergaand ga uitbreiden.

Dan eindelijk mijn dilemma waar ik graag jullie mening over wil horen:
is het handiger om de huidige site te refactoren (en dan bedoel ik heel grondig refactoren en bijna rakend aan een 'nieuwbouw', want op dit soort fratsen is de huidige architectuur absoluut niet berekend) of toch gaan voor het uitbreiden/aanpassen van een bestaand systeem?

Bij bovenstaande vraag moet ik wel aantekenen dat ik een (sterke) voorkeur heb voor een .Net oplossing, vanwege de goede raamwerken en ik daar (en in classic ASP) ervaring mee heb en in PHP alleen af en toe wat geprutst heb. Oh ja, bestaande oplossingen die creditcardgegevens in de eigen database opslaan vertrouw ik niet

[RobIII]

wizzkizz schreef op dinsdag 23 juni 2009 @ 20:06:
Dan eindelijk mijn dilemma waar ik graag jullie mening over wil horen:
is het handiger om de huidige site te refactoren (en dan bedoel ik heel grondig refactoren en bijna rakend aan een 'nieuwbouw', want op dit soort fratsen is de huidige architectuur absoluut niet berekend) of toch gaan voor het uitbreiden/aanpassen van een bestaand systeem?

Die vraag kun je alleen zelf beantwoorden als je een (realistische) schatting maakt in uren/dagen hoe lang je bezig bent met ver/herbouwen of met aanpassen van een bestaand systeem. En voor je die schatting gedegen kunt maken zul je minimaal even wat tijd moeten steken in het "proeven" aan bestaande systemen aanpassen en zien hoe dat bevalt.

Echter; gezien je waslijst met requirements en je aantekening-alinea, gaat deze vraag geheid dan richting "welk systeem zou hieraan voldoen" zodat je iig weet aan welk(e) syste(e)m(en) je zult moeten snuffelen. Niet?

[ Voor 12% gewijzigd door RobIII op 23-06-2009 21:05 ]

[wizzkizz]

RobIII schreef op dinsdag 23 juni 2009 @ 21:02:
[...]gezien je waslijst met requirements en je aantekening-alinea, gaat deze vraag geheid dan richting "welk systeem zou hieraan voldoen" zodat je iig weet aan welk(e) syste(e)m(en) je zult moeten snuffelen. Niet?

Nope, ik schat in dat mijn zoekvaardigheden goed genoeg zijn om zelf zulke dingen te vinden en heb geen letmegooglethatforyou links nodig. De impliciete vraag is of het zelf ontwikkelen van een architectuur opweegt tegen het gebruiken en aanpassen van een reeds bestaande architectuur in meer algemene zin. Ik heb geen zin om het wiel zelf opnieuw uit te vinden, maar het aanpassen van een bestaande zonder over veel documentatie te beschikken is ook niet echt je-van-het. Tips en ervaringen van mensen die hier eerder mee te maken hebben gehad, zijn dus zeer welkom.

Verder ben ik bezig met een ERD, dus daar zal ik in dit topic ook nog wel feedback op gaan vragen. Ik vraag namelijk liever in het ontwerpstadium feedback van anderen dan dat ik op eigen houtje later tegen deze problemen aanloop. Ik zit niet in een bedrijf/team waar ik feedback kan krijgen, dus daarom dan maar op deze manier.

Ja misschien is een ERD voorbarig als ik nog niet weet of ik zelf alles ga ontwerpen of bestaand ga hergebruiken, maar voor mij is het een prima manier om na te denken over hoe ik het zou willen hebben en met het bomen-bos verhaal af te rekenen door (mezelf) een beeld te schetsen van wat en hoe

[RobIII]

wizzkizz schreef op woensdag 24 juni 2009 @ 08:29:
Ja misschien is een ERD voorbarig

Dat is maar net hoe je het ziet; een "globaal" of "schets" ERD kan al een hele goede hulp zijn bij het maken van een schatting van de vereiste tijd; het dwingt je namelijk over de voornaamste zaken na te denken; details komen later wel en dien je in te calculeren

[Boss]

Ik denk dat zowel jij als de klant beter gebaat zijn bij gebruik van een meer gangbaar pakket (OS) en dat aanpassen / configureren. De initiele investering is misschien even vervelend, maar daarna kan je heel goed meegroeien met nieuwe modules.

Het maakt je eigen werk ook rendabeler: in plaats van _alles_ maken, hoef je je alleen nog maar bezig te houden met dingen die nu nog niet in de shop van jouw keuze kunnen. Daarmee kan je dan ook mooi een actieve bijdrage leveren aan een mooi OS project.

[RobIII]

Boss schreef op woensdag 24 juni 2009 @ 10:55:
Daarmee kan je dan ook mooi een actieve bijdrage leveren aan een mooi OS project.

Als het specifiek maatwerk is heeft de "OS community" daar natuurlijk geen zak aan. Daarbij is verbouwen van een bestaand pakket soms minder gunstig dan maatwerk bouwen (en dan meteen helemaal goed doen i.p.v. je in allerlei bochten moeten wringen). En wat betreft nieuwe modules e.d.: die moeten dan ook maar net werken met je aanpassingen (en dus dien je daar ook weer rekening mee te houden etc.).

[418O2]

Links- of rechtsom; het is een pens werk. Ik zou persoonlijk van scratch beginnen, bestaande pakketten modden is vaak niet heel chill, helemaal niet als het zo over de kop moet. Maar als je zo weinig programmeerkennis hebt, zijn beide oplossingen lastig.

Dus bedenk je of je het aan kan...

[Marzman]

Je kan toch ook vaak iets in verschillende kleuren bestellen als afwijkende verkoopspecificaties? Lijkt me dat dit wel vaker voor komt.

[wizzkizz]

418O2 schreef op woensdag 24 juni 2009 @ 10:59:
Links- of rechtsom; het is een pens werk. Ik zou persoonlijk van scratch beginnen, bestaande pakketten modden is vaak niet heel chill, helemaal niet als het zo over de kop moet. Maar als je zo weinig programmeerkennis hebt, zijn beide oplossingen lastig.

Dus bedenk je of je het aan kan...

Waar heb ik gezegd dat ik weinig programmeerkennis heb? Ik heb alleen gezegd dat ik weinig ervaring met PHP heb, ik heb zeker wel de programmeerkennis om dit uit te voeren. Maar ik ga pas coden als ik een goed TO heb, tot die tijd hooguit wat vingeroefeningen met aanpassen van bestaande oplossingen.

offtopic:
Mijn enige php project was het opzetten van een systeem waarbij klanten abonnementen konden nemen op een ssh-tunnel, waarbij betaling, tweeweg-communicatie met LDAP-server en verlengen/stoppen/veranderen van abonnementen via de webapp kon en er meerdere (in de testomgeving 2) servers voor het inloggen gebruik maakten van LDAPS. Niet omdat daar vraag naar was, maar om te kijken of ik het kon.

[wizzkizz]

Marzman schreef op woensdag 24 juni 2009 @ 11:00:
Je kan toch ook vaak iets in verschillende kleuren bestellen als afwijkende verkoopspecificaties? Lijkt me dat dit wel vaker voor komt.

Ja dat klopt, maar hier gaat het om heel afwijkende sales units waarvoor ook andere prijzen gelden maar die wel als 'eenheid' gepresenteerd moeten worden. Dus het uiterlijk is zeg maar het product en voor verschillende sales units gelden andere prijzen. En dat is helaas niet zo eenvoudig als een enkelvoudige (of procentuele) toeslag bij bijvoorbeeld een luxere afwerking.

Bijkomend is dat daar misschien nog wel omheen te klussen zou zijn, maar dat voor de fysieke inkoop (en dus het voorraadbeheer) rond een ander product kan zijn dan voor de vierhoekige (losse inkoop van ronde producten vs een rol voor de vierhoekige), maar het kan ook zo zijn dat rond uitgesneden wordt uit rollen waarvan ook de vierhoeken gesneden worden.

[weerdo]

wizzkizz schreef op woensdag 24 juni 2009 @ 11:27:
Ja dat klopt, maar hier gaat het om heel afwijkende sales units waarvoor ook andere prijzen gelden maar die wel als 'eenheid' gepresenteerd moeten worden. Dus het uiterlijk is zeg maar het product en voor verschillende sales units gelden andere prijzen.

Ik denk dat je het als volgt kunt oplossen: Elke sales unit is een apart artikel en zal je als zodanig intern behandelen. Elke sales unit kent zijn eigen eigenschappen (prijs, omschrijving) en 1 of meerdere gemeenschappelijke kenmerken.

Als je het zo insteekt hoeft er aan de administratieve kant bijzonder weinig tot niets te veranderen, hooguit iets aan de presentatiekant (groepering/filtering zodat de producten correct getoond worden) en dat is technisch gezien een stuk eenvoudiger.

Alle andere eisen zitten in 1 of meerdere webwinkeloplossingen en daar kun je Googlend wel uitkomen. Voor het voorraad probleem (en met name de optimalisatie daarvan) is een bedrijfsspecifieke oplossing gewenst, maar die zou ik uit de webshop-oplossing houden en apart oplossen.

[ Voor 8% gewijzigd door weerdo op 24-06-2009 11:45 . Reden: Voorraad-oplossing toegevoegd ]

[wizzkizz]

weerdo schreef op woensdag 24 juni 2009 @ 11:41:
Ik denk dat je het als volgt kunt oplossen: Elke sales unit is een apart artikel en zal je als zodanig intern behandelen. Elke sales unit kent zijn eigen eigenschappen (prijs, omschrijving) en 1 of meerdere gemeenschappelijke kenmerken.

Dat is inderdaad een manier waar ik nog niet aan gedacht had, waarbij ik een aparte tabel kan gebruiken om bij te houden welke 'producten' bij elkaar horen. Aan de presentatiekant moet ik dan wel behoorlijk sleutelen, maar dat kan wel. Alleen (en dat is bij elke oplossing op basis van een bestaande applicatie) zal ik wel goed moeten opletten bij het doorvoeren van patches voor de oorspronkelijke app.

weerdo schreef op woensdag 24 juni 2009 @ 11:41:
Alle andere eisen zitten in 1 of meerdere webwinkeloplossingen en daar kun je Googlend wel uitkomen. Voor het voorraad probleem (en met name de optimalisatie daarvan) is een bedrijfsspecifieke oplossing gewenst, maar die zou ik uit de webshop-oplossing houden en apart oplossen.

Maar dat was ik niet van plan Vrijwel alle verkoop loopt namelijk via de webwinkel (en de affiliates, maar die komen ook elektronisch binnen) en er wordt heel weinig aan contante verkopen gedaan. Het lijkt mij daarom beter om de contante verkopen ook via het administratiegedeelte af te handelen en zo alles centraal te houden.
Doe ik dat niet, maar bijvoorbeeld in het boekhoudsysteem, dan is er 1) geen real-time indicatie op de front-end en 2) is ook dat systeem qua voorraadbeheer lastig vanwege de mapping tussen het verkochte product en de inkoop hiervan (het is een small business systeem, geen groot ERP pakket ofzo).

[TheGhostInc]

wizzkizz schreef op woensdag 24 juni 2009 @ 11:27:
[...]

Ja dat klopt, maar hier gaat het om heel afwijkende sales units waarvoor ook andere prijzen gelden maar die wel als 'eenheid' gepresenteerd moeten worden. Dus het uiterlijk is zeg maar het product en voor verschillende sales units gelden andere prijzen. En dat is helaas niet zo eenvoudig als een enkelvoudige (of procentuele) toeslag bij bijvoorbeeld een luxere afwerking.
[...]

Soms is iets er niet, omdat het tegen de algemeen geldende standaarden ingaat.
Voorraadbeheer is een ramp, overzichtelijkheid is weg en als je pech hebt worden je klanten er ook gek van.
Waarom wil je dit?

Waarom je niet met een extra laag categorien kunt werken is mij niet echt duidelijk, misschien zijn het meerdere lagen, maar dan ben je er wel. Kijk ook eens hoe ze dat doen bij bijvoorbeeld Farnell, daar heb je ook van sommige producten allerlei versies qua behuizing, leveringsvorm, minimum aantallen en prijs.

[wizzkizz]

TheGhostInc schreef op woensdag 24 juni 2009 @ 12:41:
[...]


Soms is iets er niet, omdat het tegen de algemeen geldende standaarden ingaat.
Voorraadbeheer is een ramp, overzichtelijkheid is weg en als je pech hebt worden je klanten er ook gek van.
Waarom wil je dit?

Waarom je niet met een extra laag categorien kunt werken is mij niet echt duidelijk, misschien zijn het meerdere lagen, maar dan ben je er wel. Kijk ook eens hoe ze dat doen bij bijvoorbeeld Farnell, daar heb je ook van sommige producten allerlei versies qua behuizing, leveringsvorm, minimum aantallen en prijs.

Waarom ik dit wil? Omdat de klant het wil, zo gemakkelijk is het.

En om je een beter beeld te geven van de onderneming: het is een kleine zaak (paar medewerkers) dat als voornaamste verkoopkanaal internet heeft. De producten die verkocht worden kunnen standaard zijn (dozenschuiven) of maatwerk (hence de sales units waarbij klant lengte, breedte en/of diameter kan opgeven en ook voor de afwerking kan kiezen). De maatwerkproducten worden dus bulk ingekocht en daarna in de door de klant gewenste maat uitgeleverd. Voor sommige producten kan de leverancier zowel in bulk als rond met een vaste diameter (dozenschuiven dus) leveren. In presentatie naar de klant toe is dat dus 1 product met meerdere sales units. Producten hebben dus een selectie uit de sales units en niet allemaal tegelijk (1tje kan ook). Heel overzichtelijk allemaal en het wordt door de klanten ook op prijs gesteld.

Farnell heeft gewoon een diepe menustructuur en indelen in categorieën wordt natuurlijk ook gedaan, maar dan 2 niveau's diep. Hoofdcategorie > subcategorie > product (verder kan wel, maar wordt niet gebruikt).
Dat is hier geen oplossing, omdat je daar hooguit in je presentatie wat aan hebt, niet in je technisch ontwerp. En voor die presentatie heb je "virtuele" categorieen middels de zoekmachine, bijvoorbeeld op vorm, afmetingen, kleur en type.

En waarom zou het een ramp zijn voor voorraadbeheer? Je kunt prima bijhouden hoeveel je inkoopt en hoeveel een verkoop je aan voorraad "kost". Het is alleen niet standaard, maar waarom zou het een ramp zijn? Zou een doe-het-zelf winkel ook alleen maar standaard dingen mogen verkopen in plaats van platen voor je op maat maken, ongeacht in welke vorm?

En als laatste een voorbeeld waarom het gebruik van de standaard opties lastig is:
Ook ronde producten met een variabele diameter kunnen afgewerkt worden. De kostprijs van het product zelf wordt bepaald aan de hand van de hoeveelheid m² die er voor nodig is om dat uit te snijden, de prijs voor de afwerking is aan de hand van de omtrek van het product.

[MSalters]

Ik vermoed dat je een heleboel verwarring zou voorkomen als je duidelijk de twee perspectieven zou onderscheiden.

Op de eerste plaats staat de klant. De klant geeft er geen zak om hoe jullie bedrijf intern werkt. De klant wil kunnen kiezen uit een lijst producten. Dat kan die klant op een heleboel manieren doen. Daarom wil je een heleboel categorieen definieren, misschien wel met subcategorieen. Die categorieen mogen best overlappen; een product mag zeker in meedere categorieen zitten. Categorieen dienen alleen om de klant te helpen met het maken van een keuze.

Op dezelfde manier wil je bij elk productoverzicht een lijst met vergelijkbare producten tonen, zodat de klant niet afhaakt maar doorzoekt als het eerst geselecteerde product toch niet helemaal is wat hij zocht.

"Rond met een vaste diameter" en "vaste lengte en vaste breedte" zijn dus twee producten.

Aan de andere kant is er logistiek - inkoop, voorraad, productie (op maat maken) en aflevering. Daar zal de groepering van producten dus op een heel andere basis gebeuren. Dit moet je voor de klant volledig verbergen, al was het alleen maar omdat het variabel is. Als een leverancier besluit om een nieuw product te voeren, wat tot nu toe een custom was, dan wil je dat waarschijnlijk direct gaan doorverkopen. De klant hoeft daar niets van te weten.

Het concept van "sales units" is dus overbodig. De klant kan er niets mee, en logistiek doet geen sales.

[wizzkizz]

MSalters schreef op zaterdag 27 juni 2009 @ 19:57:
Op de eerste plaats staat de klant. De klant geeft er geen zak om hoe jullie bedrijf intern werkt. De klant wil kunnen kiezen uit een lijst producten. Dat kan die klant op een heleboel manieren doen. Daarom wil je een heleboel categorieen definieren, misschien wel met subcategorieen. Die categorieen mogen best overlappen; een product mag zeker in meedere categorieen zitten. Categorieen dienen alleen om de klant te helpen met het maken van een keuze.

Het concept "sales units" dat gehanteerd wordt, gaat juist uit van het klantperspectief. De idee is dat de klant op zoek is naar een tafelbedekking, waarbij de klant de keuze in eerste instantie baseert op het uiterlijk van wat er op tafel komt te liggen. Daarna kiest de klant welke afmetingen het product moet zijn, eea geillustreerd in bijgaande schermafbeelding.

De indeling in categorieën en subcategorieën is inderdaad bedoeld om de klant daarbij te ondersteunen. Of de onderneming in kwestie dat op een handige manier doet, is iets waar je over kunt twisten, maar die discussie moet je als ontwikkelaars onderling niet gaan voeren.

MSalters schreef op zaterdag 27 juni 2009 @ 19:57:
"Rond met een vaste diameter" en "vaste lengte en vaste breedte" zijn dus twee producten.

Eens, maar afhankelijk van je definitie van wat de klant wil (hence: wil de klant een boormachine of een gaatje in de muur waarvoor de boormachine een ideaal werktuig is?) kun je daar wel je presentatie op aanpassen. Zo hoef je het niet nadrukkelijk als apart product te te presenteren, terwijl het dat in feite wel is.

MSalters schreef op zaterdag 27 juni 2009 @ 19:57:
Aan de andere kant is er logistiek - inkoop, voorraad, productie (op maat maken) en aflevering. Daar zal de groepering van producten dus op een heel andere basis gebeuren. Dit moet je voor de klant volledig verbergen, al was het alleen maar omdat het variabel is. Als een leverancier besluit om een nieuw product te voeren, wat tot nu toe een custom was, dan wil je dat waarschijnlijk direct gaan doorverkopen. De klant hoeft daar niets van te weten.

De klant heeft daar inderdaad niets mee te maken, maar ik als ontwerper wel. En aangezien ik de ondersteuning van de bedrijfsvoering lever in de vorm van een webwinkel, heb ik daar wel mee te maken en dat is dan ook waar mijn vraag over gaat.

[TheGhostInc]

wizzkizz schreef op woensdag 24 juni 2009 @ 16:27:
[...]

Waarom ik dit wil? Omdat de klant het wil, zo gemakkelijk is het.
[...]

Jij mag toch ook nog wel iets van een mening hebben? Of ligt dat nu aan mij?

Volgens mij verkopen ze helemaal geen eindproducten en moet je dat ook niet zo tonen.
Jij hebt een formule waarmee je de prijs kan berekenen, gebruik die dan in een applet waarin mensen alle gegevens invoeren en je bent klaar. In de PCB wereld is dit helemaal gebruikelijk, daar betaal je ook per cm2, aantal lagen, nauwkeurigheid, ... etc.
Met een leuke Ajax call kun je dan ook nog aangeven wat de levertijd is aan de hand van je voorraad en bewerkingstijd.

Het enige "complexe" is het even koppelen met je webshop/winkelwagen. Of je dynamische producten maakt, of voor gedefinieerde bedragen oid.