PS

Even op voorhand : navolgende is veel te lang en veel te wazig ... ::) Misschien erg laat gereageerd, maar hopelijk nog nuttig : Voordat je op zoek gaat naar "standaarden" in deze, moet je eerst xx andere studies volgen, c.q. moet je veeeeel meer ervaren zijn in deze "wereld". Zeker niet negatief bedoeld, maar gewoon waar. En, zo ga je je klant niet helpen hoor ! En het vervelende is dat ik langs deze weg ook niet echt kan bijdragen aan de kennis, omdat het (vak)gebied gewoon te groot is. Echt. Maar wel een zeer globale poging : Als leveranciers en klanten elektronisch met elkaar kommuniceren, wordt dit in de wandelgangen EDI genoemd. Kijk ook maar naar de afkorting : Electronic Data Interchange. Is dat een standaard ? nee natuurlijk. Terzijde de opmerking dat dit niets met bestellen via Internet te maken heeft, tenzij er webservices aan de orde zijn (kom ik misschien nog op terug). Een niet onbelangrijke opmerking is dat EDI feitelijk verouderd is. Immers, EDI zoals ooit bedacht mag je zien als een ascii file met daarin regels die representatief zijn voor verkooporders, verkooporderregels, Inkooporders enz., maar net zo goed pakbonnen, vrachtbrieven, en 100x etc. (kom ik zo op terug); Wil je ooit tot je kunnen nemen wat EDI inhoudt/omvat dan mag je eerst alles van bedrijfsprocessen en (keten)logistiek. Weet je dat een beetje dan ben je nog nergens, omdat je vervolgens aan de gang moet met de software. Software die je zelf gaat maken ? ... mij krijg je niet gek hoor. Die software is er al ("ERP"), en de EDI funktionaliteit is daarin verweven of De sofware is er al en EDI funktionaliteit moet worden toegevoegd (kan alleen als de software intrinsiek de betreffende processen ondersteunt), denk aan een manjaartje of wat of De software is er niet en dan houdt het op. Niet helemaal, want je kunt de (ERP) software aanschaffen. Denk aan xxx.xxx euro voor goede software voor de food. Ben ik nou klaar ? nee, net begonnen. "EDI" zoals we het al jaren noemen is verouderd omdat het tegenwoordig met XML moet. Dit dus versus de asii files zoals eerder genoemd (en voor de nerd : ja, XML is ook ascii). Aha ! een nieuwe standaard ? welnee, over standaards hebben we het nog niet gehad; Zie EDI en XML maar als het "transportmedium" waarover de elektronische opdrachten worden getransporteerd (klopt letterlijk niet, maar zie het even zo voor het begrip "standaard"). Dit kan dus via de aloude EDI-methode en via de XML-methode. Maakt dit verschil ? ja, veel, maar waar ik het even niet over wilde hebben omdat het daar (wat mij betreft) niet om gaat; Waar het wel om gaat, is dat een zendende partij van een "bericht" niet zo maar kan kiezen of hij EDI of XML "doet". Immers, als de ontvangende partij alleen maar EDI "kan", heb je mooi pech. En zo werkt praktisch iedereen -althans in Nederland- nog steeds met het aloude EDI ... Dus is EDI verouderd ? ja, kwa techniek wel, maar verder is het gewoon bij praktisch iedereen in gebruik. Hebben we nu de "standaard" gevonden voor de food ? welnee, we zijn nog steeds niet begonnen (heb wel het gevoel al te moeten stoppen want het wordt veel te lang); EDI als transportmiddel maakt gebruik van standaards ... aha ! nou ... bijvoorbeeld voor europa wordt EDIFACT gehanteerd en bijv. in Amerika hebben ze iets anders. Wat voor een standaard is dat dan ? wel, dat betreft de definities van de berichten die bestaan en het geheel is genoteerd op meer dan 1.000 A4 (heb je nog zin ?). 1.000 A4 met typen berichten, of eigenlijk, typen bedrijfsprocessen waar je verstand van moet hebben. EDIFACT mag als een echte standaard worden gezien, en die kan worden vergeleken met de ebXML standaard; wat EDIFACT doet voor de "ascii" bestanden, doet ebXML voor de XML bestanden. Klaar ? nee, want hier kun je helemaal niets mee, behalve dat je nu misschien kun bepalen dat het gebruik van XML niet handig is, omdat de leverancier op de hoek nog met het oude EDI werkt (eh, of nog helemaal niet aan EDI doet zoals 95% ...). Wel is het in dit stadium goed om te weten dat alles wat XML als basis heeft, ontzettend breed kan worden ingezet. Zo kommuniceren webservices ook met XML-achtigen. XML is dus zeker the way to go; als iedereen maar mee doet (en binnen 10 jaar zal dat wel zijn gebeurd). Weer even terzijde : er bestaan natuurlijk aan alle kanten converters, die EDI naar XML en andersom kunnen vertalen. Zo, dus bijvoorbeeld in Nederland gebruikt iedereen die "EDI" gebruikt, EDIFACT ? JA ! nou, als dat geen standaard is ... Ehh ... wel jammer dat de standaard zo enorm breed is dat ze onbruikbaar is (wat moet ik met 1000 A4). In de praktijk wordt EDIFACT echter wel degelijk altijd gebruikt, maar is het intussen een "protocol" geworden. Een drager die volgens afspraken de berichten transporteert en die afspraken zijn vervat in EDIFACT. En die ascii file dan ? O jee, niet meer te volgen ... Verwijzend naar een club als EDI-Tie maken die standaards ... standaards voor de DoeHetZelf branche, voor de Metaal, voor de Food ... Maar wat behelst dat echt ? wel, aftreksels van EDIFACT. De van toepassing zijnde stukjes zeg maar, vervat op 50 A4 voor de DHZ. Nou, nu zijn we dus echt in de buurt, want kennelijk kunnen we EDI-Tie opbellen en om een setje EDI voor de Food vragen. En passent krijg je je berichten ook in het Chinees of op z'n kop als je dat wilt, en van het oorspronkelijke EDIFACT herken je niets meer. 1 ding blijft : het bericht wordt toch wel in het letterlijke EDIFACT verzonden (niet proberen te begrijpen). Als je bovenstaande ooit hebt kunnen volgen, dan zie je dat er EDI providers (EDI-Tie) aan de orde zijn, die standaards maken ... Oh, dat zijn er dus meerdere ? yep. Meerdere providers die meerdere standaards maken. Echt ! en dus moet je in de slag met leveranciers enz. om "de standaard" af te stemmen met elkaar. En er kan nogal wat fout gaan hoor. Datums die in andere notaties worden geschreven, credit bedragen die ook nog met een - (min) moeten worden geschreven zijn bekende voorbeelden. Stem je de software daar niet op af, dan is het hommeles. Software ? ja, de zgn. "in-house" software. Software die altijd nog nodig is om de EDI berichten te "interpreteren" naar je eigen wensen. Had ik al gezegd dat een bedrijf die EDI voor enkele simpele berichten implementeert zo maar een jaartje bezig is ? heeft niets te maken met ontwikkelen van software. Gewoon alles gebruiken wat er bestaat, en dan een jaar zwoegen en er half aan dood gaan. Laat ik dit maar afsluiten met te noemen dat een EDI provider gebruikt maakt van een speciaal voor EDI ingericht netwerk, zodat de berichten daarover veilig kunnen worden getransporteerd. Helaas is dat ook al zo goed als voorbij, sinds we tegenwoordig best veilig het internet kunnen gebruiken. Maar ja, ook de "postbus" zoals bekend van EDI is een standaard, en via internet werkt dat weer anders. Het bovenstaande zal niet zijn te volgen, en het is ook niet mijn bedoeling geweest echt iets uit te leggen; ik moest even reageren gezien de vraag van de threadstarter gezien het werkelijk onmogelijke van zijn bedoeling. Als ik hem was zou ik heel snel adviseren om eerst maar eens een ERP pakket geschikt voor de Food aan te schaffen; Over webservices heb ik het maar niet meer ... Peter

Als ontwikkelaar van een ERP pakket (Enterprise Resource Planning) mag ik het wel uit een iets technischer hoek bekijken. Iets wat naar mijn mening Gooz ook al aardig deed (stukje terugover omloopsnelheid en voorraadwaardering). Ik voeg er ietwat brainstormend dit aan toe : Om te beginnen acht ik de voorraad(waarde) niet te hoog, althans, niet sec genomen. Immers, met denken dat de problemen de wereld uit zijn als je eenmalig! 40.000 euro (uiterst maximaal) tot je beschikking krijgt, kom je er niet/nooit. Merk op dat hiermee alle op zich goede ideeen om je voorraad te verkopen relatief minder waardevol zijn. Je moet je omzet verhogen ? ... ik vraag het me af; als ik het zo zie ontstaan de problemen juist door het verhogen van de omzet. Of beter, door de mogelijkheden die je eerst moet kreeren om tot de verhoging te komen. Naar je eigen idee is dat ... voorraad. Vergeet ook niet dat je zelf het gevoel hebt dat het door de voorraad komt, zonder dat je er de vinger op kunt leggen; Waar je niet aan denkt, is dat de omzet verhoging zal zijn gerealiseerd middels additionele produkten. De schoenen bijvoorbeeld. Dus, voordat je de schoenen in het assortiment had was je voorraad in schoenen 0,00 en je omzet ook. En nu ? wel, kijk zelf maar. Ik houd het erop dat je bijvoorbeeld voor 1.000 euro aan schoenen hebt omgezet, maar voor 1.600 hebt liggen ... Met de schoenen als voorbeeld, moeten er nu een aantal dingen duidelijk worden : - Als je nu "pas" 1.000 hebt omgezet in de schoenen ervaar je dit als verlies. Immers het kostte 1.600 om ze te verkopen; - Je hoeft maar te wachten tot je meer dan 1.600 hebt omgezet in de schoenen, om jouw "verlies" om te zitten in winst. Laat dit het "na 3 jaar winst maken" verhaal maar zijn. - Er klopt niets van, want zo wordt de "winst" helemaal niet bepaald. Dus, als je 1.000 hebt omgezet zul je bijvoorbeeld 250 winst hebben gemaakt hierop (!). Dat je ook nog 1.600 aan voorraad hebt maakt niets uit, zolang je er maar niet op hoeft af te schrijven. Dus, gewoon 250 winst. - ... en als je dit verhaaltje volgt, blijkt dat je 1.600 + 750 - 1000 = 1.350 minder cash hebt als voordat je met de schoenen begon ... Wat er hier aan de hand zal zijn, is dat je door een berg enthousiasme je assortiment maar blijft uitbreiden, terwijl dat nog niet verantwoord is. Let wel, nog niet, want het is slechts een kwestie van wachten totdat je de omzet hebt gehad die de voorraadwaarde betaalt. Voor de schoenen voorraad van 1.600 in mijn voorbeeld betekent dat dus 1.600/250 = 6,4 x 1.000 = 6.400 omzet in schoenen. En niet de omzet verhogen ten opzichte van nu, want dat werkt averechts !! immers, de 5 paar voorraad van een maat volstaat dan niet meer, en wederom ben je eerst geld aan het uitgeven ! Uiteraard zijn de schoenen maar een voorbeeld van wat er aan de hand is, is het voorbeeld slechts indikatief en houdt geen rekening met verdere kosten. Het (blijven) uitbreiden van het assortiment mag wel op het moment dat het steeds is voorgefinancierd, mits je de afschrijving in de gaten houdt; Kan er niets meer worden gefinancierd, dan ga je nu gewoon rustig "lineair" verkopen en na een verkoop koop je het betreffende gewoon weer in. Bekijk wel even of de marge die je haalt toereikend is voor de algemene kosten en salarissen, maar wat niet nodig zou moeten zijn omdat er anders geen winkel meer in Nederland bestond. Dus, 110.000 minus 9.000 en verdere poespas ad bijv. 30.000 (lijkt me hoog ingeschat, maar zeg het maar) = 71.000. Zeker geen vetpot, maar niets iets waarvan je kunt zeggen "we redden het niet". Zit ik ergens mis ? Peter