Rapportagesysteem voor EDI-producten (afstudeerproject)

[theduke1989]

Goedemorgen iedereen,

Zit met het volgende, momenteel volg ik de opleiding Systeembeheer niveau 4 aan het Da Vinci College te Dordrecht, en zit in me afstudeerfase bij een bedrijf wat zich specialiseert in EDI/-ERP-systemen.

EDI=Electronic data interchange

Ze hebben momenteel een nieuwe dienst genaamd ''managed services'' en kunnen klanten voor een bepaald bedrag bij dit bedrijf terecht voor EDI-support, en het gaat de laatste tijd veel beter.

Nu mijn vraag:

Hier een samenvatting.
Projectdoelstelling
Doelstelling van het project is :

• Het documenteren van de te beheren systemen van de “managed services” klanten
• Het opstellen van een lijst met uit te voeren taken per klant (dagelijks, wekelijks, maandelijks, jaarlijks)
• Het opstellen van een procedure voor maandelijkse rapportage naar het ons bedrijf management
• Het opstellen van een procedure voor maandelijkse rapportage naar de klant met uitgevoerde werkzaamheden.
• Het aandragen van geautomatiseerde hulpmiddelen voor het opvolgen van de uit te voeren beheerswerkzaamheden (workflow-pakket ?).
• Het aandragen van geautomatiseerde hulpmiddelen voor het versturen van de maandelijkse rapportages naar de klanten
• Het aandragen van geautomatiseerde hulpmiddelen voor het versturen van de maandelijkse rapportages naar het management van ons bedrijf

Op te leveren producten

• Documentatie en procedureboek per klant met uit te voeren beheersactiviteiten (dagelijks, wekelijks, maandelijks, jaarlijks)
• Voorbeelden van rapportages die verstuurd kunnen worden naar de klanten.
• Voorbeelden van rapportages die verstuurd kunnen worden naar het ons bedrijf management.
• Advies over te implementeren programma’s voor geautomatiseerde ondersteuning van “managed services”. Hierbij valt te denken aan workflow tools en rapportage-tools.

Mijn zoektoch
Wat me als eerste opkwam was TOPDESK , hun hebben vrijwel voor elk iets wel een softwarepakket(los eventueel) Maar op hun site kan ik helaas niks terug vinden over EDI / ODEX / DARWIN systemen etc om zo'n rapportage tool te maken.

Toen heb ik bij me zelf gedacht, om een EDI-ontwikkelaar in te huren die een op-maat-gemaakte software kan maken voor dit eindproject. Denk daarbij aan optimizers/ call2 etc.

Maar nog geen succes

Heeft iemand nog meer tips en tricks waar ik terecht kan voor dit project?
Ik weet dat het mijn afstudeerproject is, maar ben absoluut niet in dit straatje als het gaat om:
ODEX/ XLATE/ DARWIN/ EDI

[ Voor 3% gewijzigd door theduke1989 op 19-05-2015 11:38 ]

[sypie]

theduke1989 schreef op dinsdag 19 mei 2015 @ 11:27:
Maar op hun site kan ik helaas niks terug vinden over EDI / ODEX / DARWIN systemen etc om zo'n rapportage tool te maken.

En wat hebben ze je aan de telefoon verteld toen je het probleem had uitgelegd?

[theduke1989]

Ik heb ze aan de lijn gehad en mijn vraagstelling uitgelegd.
Moest toen een bericht naar een specifiek iemand sturen die daar over gaat.
Maar nog geen response daarvan!

[sypie]

Mailen is leuk maar als je daarna achterover gaat leunen om af te wachten wat voor antwoord er op volgt... Vandaag mailen is overmorgen bellen: heb je de mail ontvangen, gelezen? Heb je een antwoord voor me? Kun je me verder helpen? Als jullie het niet kunnen, weet je dan een bedrijf die het mogelijk wél zou kunnen? (bedrijven kennen de markt heel goed en kunnen je vast verder op weg helpen).

Afwachten is tijdverspilling.

[theduke1989]

Ik ben ook niet aan het afwachten ondertussen ben ik hard op zoek naar een softwarepakket.
Echter nooit in aanmerking geweest met EDI systemen (Electronic data interchange) echt meer met windows based software en wat er zich omheen speelt.

Maar voor EDI kan ik zo 1-2-3 niks vinden.
Dacht toen om een ontwikkelaar zelf in te huren, probleem is dan met de tijdschema.
Ik heb ongeveer 4 maanden hier tijd voor, dus mocht er een ontwikkelaar zijn moet het ook weer niet te lang duren voor de implementatie.

[Meekoh]

Ik snap het nog niet helemaal, zoek jeeen EDI systeem of iets om het EDI systeem te "managen"?

[theduke1989]

Ik zoek een product wat de bestaande EDI systemen wat al bij de ''grote klanten'' die managed services gebruiken bij dit bedrijf geinstalleerd staan documentatie/ rapportages genereert op basis van die hierboven genoemde informatie staat.

Alle bedrijven bij dit bedrijf, worden al voorzien van EDI en werken onderandere meer via DARWIN/ XLATE/ DINET/ODEX systemen en willen hiervor een rapportagesysteem ingebouwd wat kan inzien hoeveel er aan besteed is en de foutraporten etc naar dit bedrijf en naar de klant opstuurt.

[The Eagle]

Dan ben je ongeduldig. Hier zit geen directe verkoopmogelijkheid aan vast, dus dat krijgt logischerwijs minder prio

Having said that: je vliegt het denk ik een beetje verkeerd aan
EDI of ERP staat inhoudelijk los van je opdracht. Ipv EDI cq ERP kun je ieder ander softwaresysteem of configuratie-item (hint: ITIL term ) lezen

Wat ze van jou willen is dat je simpelweg inventariseert wat er per dag / week / maand allemaal voor een klant moet gebeuren. En dat in een draaiboek. Dat worden dus een hoop Word-documentjes. Als je slim bent gooi je ze in een template
Vervolgens willen ze ook dat adviseert over een systeem dat die meuk kan bijhouden. Als je de boel geinventariseerd heb, kun je in een ITSM systeem (topdesk en co) standaard recurring taken definieren. Daar kun je dan ook op rapporteren, evenals op de voorkomende incidenten, changes, veel voorkomende problemen (indicent -> problem -> change) etc.

Dus:recurring tasks, inciednt, change en problem management, configuratie management, en speficieke rapportage-eisen (inhoud, wat moet er op komen etc) zijn allemaal dingen die je op moet werken voor een pakketselectie.Dat geldt ook voor de mogelijkheid (extern en/of geautomatiseerd) te mailen vanuit het systeem.

Kortom:
- inventarisatie van de standaardprocedures bij de klanten
- maken eisen- en wensenpakket ITSM systeem
- longlist opstellen van ITSM systemen
- maken van een shortlist en aanbevelingen doen op basis van eisen/wensen /longlist

En mijn eerste aanbeveling richting de opdrachtgever zou zijn: vertel maar eens hoe nu tickets / indicenten / whatever worden bijgehouden en opgelost. Als dat papier is: mooi, dan heb je carte blanch voor het fatsoenlijk implementeren van ITIL procedures

[theduke1989]

hoe ze het nu doen is nog telefonisch of loggen in via rdp/stepco/vpn bij de klant.
En via ODEX workstation gaan ze alle logtools af om het probleem te vinden.

Ik zal zeker ITSM aanhouden, ITIL based werken.
Zal deze topic en jou reactie hier aanhouden.

Veel info.

[ Voor 29% gewijzigd door theduke1989 op 19-05-2015 12:19 ]

[The Eagle]

Dat is de praktische afhandeling. Nu het bijhouden van wat wanneer gedaan wordt, waarom en door wie

[CAPSLOCK2000]

Kun je in één zin aangeven wat je vraag is? Ik zie wel een hele afstudeeropdracht maar geen vraag aan ons.
Wat is de relatie met NOS?

De eisen die je noemt wijzen er op dat je een ticket-systeem nodig hebt. Volgens mij hoeft dat systeem geen inhoudelijke kennis van EDI te hebben.

PS. Het inhuren van developer is waarschijnlijk veel te duur voor je afstudeeropdracht en het kost ook nog eens te veel werk.

[theduke1989]

Goedenavond,

Inderdaad er hoort ook een ticket-systeem te komen, waarbij hun klanten een ticket kunnen openen wanneer ze iets willen. Daarnaast willen ze een redelijke/grote uitgebreide rapportage/documenten systeem wat deze op dagelijks, wekelijks, maandelijks, jaarlijkse een rapport maakt voor ieder bedrijf wat in managed services zit bij hun.

Inderdaad daar dacht ik ook aan, omdat wanneer je een ontwikkelaar inhuurt ook denk mijn 4/5 maanden overschrijd en me diplomering zou moeten uitstellen wat ik dus niet wil.

Mijn vraag is:
Zijn er systemen wat op basis van EDI/ ODEX/ DARWIN/ etc een ticket/rapporten systeem werken.
Aangezien ik vrijwel veel managed services en EDI oplossingen ook door andere bedrijven terug vindt op google, zie ik niet wat ik zelf zoek of er in deze richting dus dat soort systemen zijn. ''The Eagle'' heeft wel het een en ander verteld en ITSM ....

[CAPSLOCK2000]

Misschien snap ik gewoon niet wat EDI is maar wat voor features moet zo'n ticketsysteem hebben die andere systemen niet hebben?

Aangezien ik nog steeds geen relatie zie met Non-Windows Operating Systems verplaats ik dit topic even naar het WSS forum.

[theduke1989]

EDI of (Electronic data interchange) is een standaard voor het uitwisselen van bijvoorbeeld afroepschema's orders/ facturen en veel meer. Dit soort systemen worden vaak bij AUDI/ BMW/ DAF en noem zo maar op gebruikt die met hun toeleveranciers in contact zijn via zo'n EDI-systeem.

Maar om EDI echt te kennen werk je ook nog met ander soort systemen die de EDI-berichten systeem kunnen lezen etc, denk daarbij aan ODEX Workstation dat is een software wat fouten kan zien wanneer er tussen een bedrijf als AUDI en hun leverancier fout is gegaan met het versturen van een order etc.
Of XLATE wat bepaalde mapping omzet in EDI mapping die dan weer door ODEX gelezen kunnen worden.

NU je zelf het ook zegt EDI is niet een term wat je vaak zal/zult horen in de IT-wereld als je opgegroeid bent met windowss of ander soort software.

Om nu dus al die processen wat ze in hun managed services aanbieden mijn bedrijf, willen ze dit gedocumenteerd en gerapporteerd hebben zodat dit (geautomatiseerd) naar ons bedrijf als de klant toegestuurd wordt.

Mijn eigen ideeen waren: TOPDESK/ULTIMO of een ontwikkelaar inhuren, maar wat je al zei een ontwikkelaar is veel te duur en kan ook nog eens tijdrovend zijn vooral omdat ik er 4 maanden over mag of zelf eerder wil doen. Maar topdesk heeft een groot assortiment aan oplossingen zoals rapportages/contractenbeheer en noem zo maar op, maar waarschijnlijk niks in de trans van EDI.

Heb er een presentatie overgehad, en begrijp hun begrip van werken wel.
Echter de project zelf dus zulk soort ITIL systemen wat niet op basis van windows werken nog nooit wat mee gedaan en op google wordt ik er ook niet echt veel slimmer van.

[ Voor 11% gewijzigd door theduke1989 op 19-05-2015 20:42 ]

[CAPSLOCK2000]

Volgens mij gaat geen enkel ticketsysteem rechtstreeks EDI doen en volgens mij is dat ook helemaal niet wat de opdrachtgever zoekt. Het lijkt mij alsof je een autogarage wil helpen met een ticketsysteem dat op loodvrije benzine werkt. Om ondersteuning te geven aan gebruikers van EDI hoeft je ticketsysteem nog niet in/met EDI te zijn gemaakt. Weet je zeker dat je wel het juiste probleem aan het oplossen bent?

[MAX3400]

Ik begrijp er eerlijk gezegd ook niet heel veel van terwijl ik toch aan de achterkant zit/werk/fruts van applicaties als TopDesk / ServiceNow etc.

In de essentie wil/zoek je het volgende: welke data (opgeslagen aan de achterkant van een organisatie zoals een ticketsysteem of een ordersysteem) moet ik opvragen, samenvoegen, organiseren en rapporteren om uiteindelijk een geautomatiseerd "dumb front-end" te hebben waarmee er verschillende rapporten (operationeel, SLA, SLR, whatever) naar klant of leverancier wordt gestuurd.

In mijn optiek zit je al halverwege het oplosproces maar heb je 0 idee wat de input is. Termen als EDI, XLATE, ODEX etc lijken een verplichting in jouw oplossing/uitwerking maar zijn zeker niet de enige termen of mogelijkheden om data naar boven te krijgen. Hierdoor is het voor ons eigenlijk al bij voorbaat kansloos om constructieve input te leveren op wat er aan data ingaat (zoals 9 miljard regels uit een SQL Express Database van "TopDesk"), hoe het verwerkt moet gaan worden (waar jij dus mee bezig moet zijn) en hoe het uiteindelijk wordt uitgeprint/weggestuurd (proces van niks dus niet over nadenken).

/edit: zoals je leest denk ik hier alleen over de rapportages na; de processen/procedures voor dagelijks "beheer" liggen op een ander vlak.

[ Voor 5% gewijzigd door MAX3400 op 20-05-2015 07:24 ]

[F_J_K]

Eerlijk gezegd is me nog niet duidelijk wat er nu concreet aan functionaliteit en aan rapportages nodig gaat zijn.

Zo te lezen wordt je niet gevraagd om de workflow van de berichten aan te passen (code business van je opdrachtgever?) maar de 'workflow' van / rond technisch applicatiebeheer van de systemen (of ook functioneel beheer?). Ik denk dat je naast evt. info over performance, uptime, etc. hooguit (!) iets moet met foutmeldingen over mislukte berichten. Of is het de bedoeling dat de rapportage aan de klant inhoudelijk is? ('Deze maand 5.000 linkerbuitenspiegels geleverd, waarvan 120 defect en 300 te laat geleverd'). Lijkt me niet. Dat is in ieder geval een andere tak van sport.

Hoe is het relevant dat er tussen verschillende systemen EDI-berichten worden uitgewisseld, XLATE aan transformatie en translatie doet etc? (Gedachtespel: zoek EDI en vervang door overtypen door tiepmiepen in een zwarte doos, wat verandert er dan aan je opzet?)

Wat The Eagle in "Rapportagesysteem voor EDI-producten (afstudeerproject)" etc zeggen dus.

---

Heeft IBM geen standaardoplossingen voor wat je wilt? ==> bel eens met jullie account manager daar. (Als de vraag helder is).

[theduke1989]

Het is inderdaad niet de bedoeling om de workflow berichten aan te passen maar de berichten en foutmeldingen die niet zijn aangekomen te rapporteren en dus in een soort van product (ITSM) door te sturen naar de klant.

Ik heb al een draaiboek bijvoorbeeld nu samengesteld:
wie doet wat
wat doet elke medewerker precies
hoeveel tijd heeft die nodig
wie is afhankelijk van wie
wat moet eerst, en wat kan er later.

Mijn idee was (denken)
1. De consultant gaat elke morgen controleren hoe het systeem de dag ervoor heeft gedraaid, en of er problemen waren (volgens het technisch draaiboek) en of krijgt via een system ITSM/ ander oplossing een email etc met de errors indien ze er zijn.

2. Dit documenteert hij in (nog onbekend) systeem) (ITSM waarschijnlijk)
En rapport hoe lang de er mee bezig is.

3. Het ITSM product genereert een rapport met wat er gedaan is en hoe lang het heeft geduurd op dagelijks, wekelijks, maandelijks afhankelijk van hoe elke klant het wilt en stuurt deze naar hun op, en een kopie/melding naar ons bedrijf zelf.

Zo iets had ik dus zelf in de planning staan met behulp ook van The eagle wat die zei over zo'n draaiboek.
Maar ik zit met het punt, omdat ERP-systemen of EDI systemen en vooral die werken in DiNET of ODEX/XLATE niet via topdesk denk ik werken, het vee moeilijker is dan ik eerst had gedacht.

[Question Mark]

theduke1989 schreef op woensdag 20 mei 2015 @ 12:04:
Het is inderdaad niet de bedoeling om de workflow berichten aan te passen maar de berichten en foutmeldingen die niet zijn aangekomen te rapporteren en dus in een soort van product (ITSM) door te sturen naar de klant.

En hoe wordt nu geconstateerd dat die berichten niet aankomen?

• Word logging doorgespit?
• Wordt dit in eventlogs gerapporteerd?
• etc.

Dat proces moet je gaan automatiseren, dat is iets wat bv. met SCOM gedaan kan worden. En dan maakt het totaal niet uit wat voor software of pakketen heen-en-weer verstuurd worden. Je geeft je monitoringtool opdracht om alert X te generen bij situatie Y.

Je opdracht is volgens mij ook tweeledig:

1. Automatiseren van het constateren van verstoringen
2. Rapportage opstellen van de verstoringen.

[theduke1989]

Nu hebben ze helemaal geen documentatie elke consultant doet alles op zijn manier.
Het documenteren van fouten die de dag ervoor zijn gemaakt worden op verschillende manieren gedocumenteerd die niet voor iedereen even makkelijk terug te vinden is.

Nu is het een van de consultants voert in de ochtend de controle uit, indien er een fout opgetreden is zoals een bericht wat veel te laat is aangekomen wordt niks mee gedaan. Maar een keychange wordt meteen aangepakt. Is allemaal vrij verschillend.

Maar er moet inderdaad dus ee rapportage opgesteld worden voor het verstoren en ook rapporten voor dit bedrijf en hun klaten om ook vanuit daar de berekeningen wat ieder klant betaald bijvoorbeeld of dit wel goed of niet goed is wat ze ervoor betalen etc.

SCOM is inderdaad ook een grote speler. Ga me trouwens verdiepen in scom want je zegt voor scom maakt dat niet uit? Ookal werken ze niet met windows based systemen ?

[MAX3400]

theduke1989 schreef op woensdag 20 mei 2015 @ 16:15:
Nu hebben ze helemaal geen documentatie elke consultant doet alles op zijn manier.
Het documenteren van fouten die de dag ervoor zijn gemaakt worden op verschillende manieren gedocumenteerd die niet voor iedereen even makkelijk terug te vinden is.

Niet makkelijk terugvinden is niet gelijk aan onvindbaar. Dan is het dus zaak dat er zo snel mogelijk wordt gekeken wat er wel op papier staat, waarom het op plek A of B staat, of dit op korte termijn anders kan, of er een standaard in kan worden gebracht en in hoeverre er een (geautomatiseerd) template van te bakken is.

Nu is het een van de consultants voert in de ochtend de controle uit, indien er een fout opgetreden is zoals een bericht wat veel te laat is aangekomen wordt niks mee gedaan. Maar een keychange wordt meteen aangepakt. Is allemaal vrij verschillend.

Wederom, geen proces in place wat zaken moet regelen, zo lees ik het. Het is ontzettend lastig om chaos te scheppen in ad-hoc werk en dan ook nog eens proberen (ooit) om er een normale rapportage van te bouwen.

Maar er moet inderdaad dus ee rapportage opgesteld worden voor het verstoren en ook rapporten voor dit bedrijf en hun klaten om ook vanuit daar de berekeningen wat ieder klant betaald bijvoorbeeld of dit wel goed of niet goed is wat ze ervoor betalen etc.

Dit klopt niet; er lijkt me toch een PDC aanwezig te moeten zijn voordat je uberhaupt iets voor een klant gaat doen. Elke dienst/service binnen de PDC moet intern al bekend zijn wat het kost per uur, welke marge erop zit en welke klant binnen welke marge-tabel valt. Indien niet, dan zou ik het als klant/leverancier heeeeel vreemd vinden, en verhaal komen halen, waarom ik elke maand een andere rekening op de deurmat zou vinden.

SCOM is inderdaad ook een grote speler. Ga me trouwens verdiepen in scom want je zegt voor scom maakt dat niet uit? Ookal werken ze niet met windows based systemen ?

Eerst verdiepen, dan vragen. Google maar eens op "SCOM Management Packs"; er gaat een wereld voor je open. Maar bijt je er niet in vast; de gemiddelde organisatie heeft minstens 1 hobbyist die ook monitoring doet middels een eigen script in een andere taal, of een Linux-afgeleid pakket of een of andere SNMP-pakket van hardware-leverancier Z.

[Question Mark]

theduke1989 schreef op woensdag 20 mei 2015 @ 16:15:
Ga me trouwens verdiepen in scom want je zegt voor scom maakt dat niet uit?

Het maakt SCOM (of welk ander pakket) niet uit of hij nu een alert moet generen uit een foutmelding uit een EDI-pakket, of een ander pakket.

Maar focus je in deze instantie nog niet teveel op software oplossing. Omschrijf eerst je probleemstelling nu eens duidelijk. Daaruit volgt wel welke stappen je moet doorlopen/oplossen om het probleem op te lossen. Vervolgens kun je eens beginnen om een planning te maken.

Hardstikke leuk dat je nu al doelstellingen meegekregen hebt, maar daar zou ik toch zeker even kritisch naar gaan kijken.

Overigens vind ik het probleem zoals het nu lijkt, geen technisch probleem. Het is meer een bedrijfskundig probleem. Het speerpunt van de opdracht gaat zitten in het concretiseren van de probleemstelling, en het opstellen van processen/workflows en gaan verzinnen wat er exact gerapporteerd moet worden. De technische oplossing om dat te bereiken komt daarna pas.