Een eigen Medusa-module wordt beter te begrijpen wanneer zij één herkenbaar bedrijfsbegrip beheert. Dat kan een adviesselectie, een installatievoorwaarde of een goedgekeurde productcombinatie zijn. Begin niet met een verzameling extra velden op verschillende plekken. Beschrijf eerst welk begrip een eigen betekenis en levenscyclus heeft. Daarmee krijgt het maatwerk een grens die ook niet-technische collega’s kunnen uitleggen.
Zoek het begrip achter de handmatige administratie
Bekijk welke lijsten of notities medewerkers naast de webshop gebruiken. Vaak staat daarin kennis die niet goed in het standaard product- of ordermodel past. Vraag wat één regel van zo’n lijst vertegenwoordigt. Is het een productkenmerk, een tijdelijke beoordeling of een afzonderlijke afspraak? Alleen dat laatste soort afgebakende begrip vraagt mogelijk een eigen model en proces.
In een fictieve winkel voor beursinrichting beoordelen medewerkers welke standopstelling geschikt is voor een gekozen ruimte. De beoordeling kan een eigen status, toelichting en productrelatie hebben. Het is dan nuttig haar als installatiebeoordeling te beschrijven. De module hoeft niet meteen ook de volledige planning en klantcommunicatie over te nemen. Die blijven andere verantwoordelijkheden.
Schrijf drie voorbeelden en één tegenvoorbeeld op. Een beoordeling voor stand A hoort erbij; een algemene productomschrijving niet. Deze eenvoudige oefening voorkomt dat een module tijdens het project steeds meer losse wensen verzamelt. Wanneer een nieuwe wens binnenkomt, kan het team beoordelen of zij hetzelfde begrip verdiept of eigenlijk een ander onderdeel betreft.
Bepaal gegevens, beslissingen en relaties
Medusa ondersteunt eigen modules voor afgebakende functionaliteit. Relaties met andere modules worden afzonderlijk vormgegeven, onder meer via module links. Voor de opdrachtgever betekent dit dat de eigen gegevens en de verbinding met producten, klanten of orders bewust moeten worden ontworpen. Een technische relatie heeft pas waarde als haar betekenis duidelijk is.
Maak onderscheid tussen gegevens die de module zelf bepaalt en gegevens die zij elders leest. De installatiebeoordeling kan bijvoorbeeld een toelichting en uitkomst beheren, terwijl productafmetingen uit de catalogus komen. Een kopie van alle productinformatie in de nieuwe module maakt bronbeheer ingewikkelder. Bewaar alleen wat voor het eigen begrip en de noodzakelijke historie relevant is.
Beschrijf vervolgens wie een beslissing mag nemen en wanneer zij verandert. Een conceptbeoordeling kan worden aangepast; een beoordeling die bij een geplaatste bestelling hoort, vraagt mogelijk een andere behandeling. Dit is een proceskeuze die vóór de interface moet worden besproken. De ontwikkelaar kan haar niet betrouwbaar afleiden uit een veld met de naam status.
Laat de module één complete taak ondersteunen
Een gegevensmodel alleen is geen bruikbaar product. Laat een medewerker het begrip aanmaken, beoordelen en terugvinden bij het juiste commerceobject. Gebruik hiervoor een fictief voorbeeld dat de hele route doorloopt. Vraag de medewerker in eigen woorden te vertellen wat de uitkomst betekent en welke volgende stap mogelijk is. Onduidelijke antwoorden wijzen op ontbrekende procesuitleg.
Leg bij oplevering ook vast hoe nieuwe regels worden toegevoegd en welke voorbeelden bij toekomstige wijzigingen opnieuw moeten worden gecontroleerd. Zo blijft de module inhoudelijk herkenbaar wanneer het assortiment groeit. Het team hoeft niet iedere technische beslissing te begrijpen, maar moet wel kunnen aanwijzen waar de bedrijfsbetekenis wordt vastgelegd en wie daarover beslist.
Voor Medusa-maatwerk geeft één helder bedrijfsbegrip richting aan ontwerp en onderhoud. Als de module informatie aan andere bedrijfsapplicaties levert, past die uitwisseling in een expliciete integratieaanpak. De module wordt dan een afgebakende drager van eigen bedrijfskennis, met herkenbare relaties en een concrete taak voor de mensen die ermee werken.