Licentie aanschaffen

Jopje

Tijdens deze stage heb ik gemerkt dat het werken met Navision fijn is, en dat je er veel mensen blij mee kunt maken

Naast het blij maken van mensen heb ik ook geleerd regels gelijk op papier te zetten om onnodig steeds opnieuw aan te passen te voorkomen. Mail en paraafjes vragen helpt altijd [-o<

Dit bedrijf zit in de voedselbranche en heeft veel modificaties/maatwerk in Navision. Omdat er vaak mensen een rapport nodig hebben en er veel stagiaires zijn, lijkt het mij een goed voorstel om:

"Table Designer" aan te schaffen in de licentie. Dit mede doordat er veel snelheid kan worden gehaald bij het aanpassen van tabellen en het aanmaken van flowfields. (10 min voor een op maat gemaakt rapport is gewoon veel tijd). Terwijl het met een flowfield minder als 10sec kan duren (getest tezamen met begeleider vanuit school).

Toch gaat het om veel geld en een bedrijf ziet zeker naar zijn uitgaven, maar daarnaast ook wat het hun kan opleveren.

Zelf kan ik punten bedenken waarom het bedrijf "Table Designer" moet aanschaffen, maar graag zou ik iets sterker staan in mijn argumenten zodat ook het aanpassen en het maken van rapporten gemakkelijker wordt tijdens de rest van mijn stage.

Wat vooral voor mij van belang is, is de snelheid en tijdswinst die ermee behaald kan worden, en eventuele kostenbesparing door middel van het zelf aan te kunnen passen van tabellen en daarbij niet steeds de dealer een opdracht te geven.

Mijn vraag aan jullie is of jullie goede sterke argumenten hebben om mij het bedrijf te overtuigen dat het een goede investering is.


Met vriendelijke groeten,

DenSter

Ik denk dat je op de juiste weg zit. Wat beslissers ertoe beweegt een bepaalde keus te maken is omdat het gekozen alternatief het meest efficient is qua kosten. Als je een goed onderbouwd verhaal wil brengen naar de beslisser, dan zal je alle alternatieven op een rijtje moeten zetten. Het ziet ernaar uit dat jij denkt dat de table designer het minst kost, en dus zal je een verwachting moeten opnemen van de besparing die jij ziet. Vergeet niet dat ze niet zitten te wachten op een verhaal 'ik denk dat dat geld gaat besparen', je zal het moeten onderbouwen met cijfers.

Je hebt gelijk dat je geld kan besparen door dingen zelf te doen, maar dat moet je dus kunnen kwantificeren.

Aan de andere kant, je kan niet zomaar onbeperkt flowfields toevoegen aan een tabel. De technische grens is niet zomaar bereikt, maar je kan zomaar een enorm verschil in performance maken door de 'verkeerde' tabel aan te raken. Dat soort argumenten spelen dus ook een rol. Naast de aanschafkosten van de licentie, zulen ze dan ook moeten investeren in het opleiden van personeel, en het onderhouden van die kennis. Het probleem van je eigen mensen opleiden is dat die dan de verleiding krijgen om bij een solution center te gaan werken.

Het zit dus helaas niet zo simpel in elkaar, maar het is wel een interessant vraagstuk voor een stage. Ik ben benieuwd wat de reacties zijn van je bedrijf.

Jopje

Achter de reactie kom ik zometeen, 9.30 uur bespreking.

Het bedrijf heeft doorgaand een ruim overschot aan stagiaires al zeggen de medewerkers dat zelf, en die hebben en krijgen de tijd om zich daarin te gaan verdiepen. Daar ben ik er zelf dus ook één van, maar helaas doe ik zoveel extra naast mijn stage.
Eén van de redenen om te kijken naar Table Designer en het te kijken hoeveel het kan opleveren door het niet op de 'hardprogrammeren' te doen.

Ook speel ik het politieke spel in het bedrijf mee, waar iedereen zichzelf het belangrijkst vindt, en dat je altijd op moet passen wat je (toe)zegt, zo heb ik mijzelf in een belangrijke positie weten te plaatsen door RUS4M te geven. ( 'Remco's Update Sessie 4 Management' , om zo algemene computertechnische kennis over te dragen aan het management).

De directeur was al onder de indruk toen ik hem het verschil in tijd liet zien tussen de harde programmering en met een flowfield (aangemaakt met licentie van school in testomgeving, daarna licentie weer verwijderd van bedrijfsnetwerk )
Heb dus al gewerkt aan mijn betrouwbaarheid en hoop dat mijn idee/keuze in goede smaak valt.

kriki

De klant table designer laten kopen is een mes dat snijdt aan 2 kanten.
Als je de klant toelaat om dingen aan te passen, wordt dat voor het Solution Center een hel om onderhoud te doen. Vooral een upgrade naar een nieuwe versie wordt stukken langer en gecompliceerder.
Het kan ook dat een klant iets veranderd in een veld waar hij zou moeten afblijven. Als alles dan in het honderd loopt, geeft hij de schuld aan het NSC. Als NSC moet je dan alles goed bijhouden en documenteren om te kunnen bewijzen dat het de klant is dat iets uitgehaald hebt. En zelfs al kun je dat perfect bewijzen, dan steek je er nog veel tijd in om het te bewijzen.
En als alles bewezen is, moet je dan ook alles terug in orde brengen (als dat al mogelijk is) (EN de klant betaald natuurlijk!) en zijn besparing verdwijnt als sneeuw voor de zon. En hoe het ook gaat (schuld van klant bewezen of niet bewezen), de klant is ontevreden (dit hangt van de klant af:er zijn klanten die hun schuld blijven ontkennen) (als je een goede klant hebt, dan zal hij tevreden zijn).
Ook moet je denken aan het NSC voor wie je werkt. Het is belangrijk kunnen factureren!
En als de klant moet betalen voor elke futuliteit die hij wil, zal hij wel even nadenken. Dikwijls denken ze dat ze iets nodig hebben, ze veranderen iets en dan gebruiken ze het toch niet...maar de DB voelt het verschil wel in performantie en het NSC om alles werkende te houden en de klant die ervoor moet betalen (meer maatwerk=>meer tijd om upgrades te doen =>hogere kostprijs [wilden we dit juist niet vermijden]).

Mijn conclusie (gebaseerd op meer dan 6 jaar ervaring met Navision [zowel in Belgie als Italie]) : laat een klant geen objecten aanpassen. Dat brengt enkel problemen.

DenSter

Jep daar ben ik het in grote lijnen mee eens. Wij hebben een aantal klanten dat heel bewust en doordacht omgaat met hun table designer, die bijvoorbeeld altijd hun ontwerp documenten aan ons voorleggen voor advies over de haalbaarheid en of we misschien suggesties hebben. We hebben echter ook veel gezien dat klanten het niet zo nauw nemen met de grondigheid van hun research en klakkeloos flowfields aanmaken.

Het klinkt allemaal heel eenvoudig, en ik kan zo een hele indrukwekkende demo doen, maar er liggen een paar enorm giftige adders onder het gras. Stop bijvoorbeeld 1 veld middenin een sumindex sleutel definitie en je hele boekings programma kan in het 100 lopen. Maak 1 flowfield te veel aan of maak een klein foutje met dupliceren van een sumindex sleutel en je systeem loopt ineens de grond in.

Ik heb geen enkel probleem met een klant die table designer koopt, als die klant ook de kennis koopt die nodig is om daar goed mee om te gaan, weet wat de consequenties kunnen zijn, en als ze maar zelf de verantwoordelijkheid nemen als het inderdaad fout gaat. Zoals Alain al zei, er zijn zat klanten die die verantwoordelijkheid NIET willen nemen, de boel verschteren, en vervolgens vingers gaan lopen wijzen naar het NSC.

Overigens, ik wil niemand op de tenen trappen, maar het bezorgt mij een beetje dat een bedrijf het onderhoud van hun ERP systeem overlaat aan een aantal stagieres. Ontwikkelen in Navision is relatief gezien vrij eenvoudig, maar vanwege de eenvoud is het ook erg makkelijk om groot in de fout te gaan. Naar mijn mening moet dit soort werk gedaan worden door een professional, en dan maakt het mij niets uit of die persoon bij een NSC werkt of niet.

kriki

DenSter wrote:

Naar mijn mening moet dit soort werk gedaan worden door een professional, en dan maakt het mij niets uit of die persoon bij een NSC werkt of niet.

Volledig mee eens. Maar ook : een stagair of beginneling onder controle van een professional.

Jopje

Het hangt er ook vanaf hoe er wordt getest, ben nu 3 maanden bezig en heb ondertussen enkele dingen ingevoerd hier in het bedrijf, onder andere om onnodige rapporten te laten ontwerpen:

Het geval:

Men kwam bijeen om een rapport samen te stellen, iedereen was 'tevreden'.
Rapport werd opgeleverd.. Na het uitprinten moest er toch nog informatie bij, was de layout niet goed [-X . De managers dachten niet goed na over welke informatie ze daadwerkelijk nodig hadden. Tevens zijn er nooit echte duidelijke afspraken gemaakt op het gebied van Report Design :-$ .

Functionele ontwerpen helpen hier bij, op het moment dat een rapport niet een bepaald probleem kan oplossen en er niet van iedereen een paraaf staat op het ontwerp, dan komt er geen rapport. Eenmaal met paraaf wordt er niets aangepast, wat volgt? Managers denken nu wel beter na over hun wensen en prioriteiten

Hetzelfde geldt voor Navision, ze draaien altijd een backup en aanpassingen gebeurden tot nu to in de Live-Database. Nu gebeurd dat in een test omgeving \:D/. Dit betekend dat een aanpassing eerst getest moet worden, dat een 'implementatie' moet worden voorbereid en dat er een backup wordt gedraait voordat het wordt geïmplementeerd in rustige tijden. Dit willen ze vooral over laten aan stagiaires, deze zijn er namelijk altijd, en die hebben de tijd en nieuwe kennis om deze dingen te doen (bedrijfsvisie).

Als ik eind December weg ga, dan komen er 2 nieuwe stagiaires die met Navision bezig gaan, ik laat documentatie voor ze achter en probeer overige medewerkers mijn ervaringen en kennis over te dragen. ](*,)

Dit bedrijf: van de Leur banketspecialiteiten bv is een veeleisende klant met veel maatwerk, maar heeft een goede samenwerking met Schouw Informatisering. In dit bedrijf heeft kwaliteit de hoogste prioriteit (en voor stagiaires zelfverrijking erbij), dit betekend dat zulke rampscenarios niet zullen voorkomen (enorm veel worden vermeden).

Ik kan natuurlijk wel begrijpen dat het 'angstzweet' uitbreekt bij zowel de Solution Centre en het bedrijf zelf... Maar ik geloof heilig in het feit dat Table Design een goede investering is om geld te besparen. (alle wijzigingen worden gelijk doorgespeeld aan S.I.), mits er nauwkeurig te werk wordt gegaan (gezien mijn ervaringen met dit bedrijf zal dat geen probleem zijn). "

Fanclub
Bij de implementatie zat Van de Leur zelf aan het stuur. "Het begin was even moeilijk, er moesten wat noten gekraakt worden, maar uiteindelijk heeft Schouw Informatisering gezorgd voor een perfecte implementatie. Normaal gesproken staat er zes tot negen maanden voor zo'n traject, maar we hebben het binnen drie maanden en binnen het budget geklaard. Vooraf volgden alle gebruikers een cursus. Een gouden greep. Mensen werden nieuwsgierig en wilden met het nieuwe pakket aan de slag. Vaak zie je juist het tegenovergestelde, mensen zijn een beetje bang en afwachtend. Wij hadden een fanclub in plaats van tegenstanders van het systeem."

Er liggen hier dan ook honderden boekwerken :-# , mijn punt is dat ik niet verwacht dat het extra geld gaat kosten en dat er géén grote fouten van zullen komen. De omgang met Navision is helemaal vastgelegd, enkel het aanvragen van nieuwe rapporten is niet goed gestructureerd.

Jopje

Gelukkig maar dat ik word ondersteund door een pro...

Niet alleen dit lieve forum, maar ook mijn begeleider van school:
dhr. E.A. Huizinga


Het aanpassen van de tabellen gaat vooral om snelheidswinst en het genereren van rapporten (Omzet per klantgroep, productgroep, klantengroep met onderverdeling in productgroep)..

Omdat de dimensies in het Rapportageschema niet goed zijn ingericht (alleen kostenplaats en kostendrager)... bereik ik daar ook niet veel mee..

DenSter

Dat bedoel ik dus.....

In plaats van een flowfield aanmaken voor elk omzet rapport, kan je dus beter bestaande sumindex velden gebruiken en door de juiste filters te zetten in het rapport de juiste waarden rapporteren.

Je kan wel flowfields blijven aanmaken, maar dat gaat ten koste van je performance en op een gegeven moment heb je er teveel en krijg je problemen met het openen van tabellen.

Ik wil niet zeggen dat je op de foute weg zit, ik denk alleen dat je niet zomaar voor elk rapport een tabel aanpassing hoeft te maken. Het is beter om 1 sumindex veld te hebben dat je voor 100 rapporten kan gebruiken met 100 verschillende filters, dan 10 flowfields aan te maken, voor elk rapport 1. Om het verschil te kunnen aanduiden, heb je kennis nodig van database ontwerp, en ik ben niet overtuigd dat het de juiste weg is om dit door de klant zelf te laten doen.

Overigens....
Wel een fantastische stageplek, als je zoveel vrijheid krijgt

Jopje

Daar was ik ook al over verbaast,

maar je advies is dus om de aanpassingen te laten doen i.p.v. het aanschaffen van 'Table Designer'. Zolang ik er ben blijft het natuurlijk goed gaan :P maar ja... als ik éénmaal weg ben dan weet ik natuurlijk niet wat er allemaal volgt.

Het zit namelijk zo, de managers hier hebben vaak overzichten nodig waarbij altijd wordt vergeleken met een voorgaande periode.

Bijv Omzetoverzicht per jaar. Nu ik niet alles weet, maar wel tezamen met mijn begeleider heb gekeken naar de flowfields die er meteen voor zorgde dat het rapport werkte en binnen 4 sec de juiste gegevens gaf.

Maar als er andere manieren zijn om dit te vereenvoudigen, dan hoor ik het graag!

Schetsje:

Omzet (dit jaar, vorig jaar, verschil, verschil%)

Klantengroep (moet te filteren zijn)
- Productgroep (moet te filteren zijn)
Totaal Klantengroep

UITKOMST:

Horeca(dit jaar, vorig jaar, verschil, verschil%)

- Open vlaai 20 _ 10 _ +10 _ +100%
- Quiche 40 _ 80 _ -40 _ -50%
- Petits Fours 15 _ 10 _ +5 _ +33,3%

Totaal 75 _ 100 _ +25 _ -25%

Het is 5 uur geweest nu naar huis, tot morgen!

DenSter

Een flowfield is niks meer dan een calculatie op een sumindexfield, met een dynamische filter op een of meerdere velden uit een andere tabel. In plaats van 100 verschillende flowfields aanmaken in de customer tabel, kan je beter gebruik maken van een sumindex field uit de betreffende ledger tabellen, en de filters aanpassen in het rapport. Dat hoeft als je het goed doet geen enkel verschil uit te maken in vergelijking met een flowfield.

Aan de andere kant, je kan ook flowfilters aan je tabel toevoegen en die opnemen in een fowfield definitie, en op die manier je rapportage flexibeler maken. Je kan het op meerdere manieren doen, als je er maar bewust van bent en een doordachte keuze maakt.

De filters die jij toevoegt aan de flowfield definitie kan je ook aan je rapport toevoegen. Wat je dan alleen wel moet doen is een dataitem voor de betreffende ledger tabellen toevoegen en zo de juiste link leggen, of textboxen in de secties en het via programmeren doen.

Mijn advies is niet om geen flowfields aan te maken, maar om daar goed over na te denken (i.e. alle consequenties op een rijtje te zetten) voordat je klakkeloos velden toevoegt.