ebusiness architectuur

[frank.custers]

???

Ik ben sinds enige tijd bezig met het opzetten van een bedrijf in de financiele dienstverlening voor MKB+ bedrijven.

 

De eerste dienst wordt het elektronisch verwerken van inkomende facturen. Ik wil hiervoor een standaard applicatie gebruiken. Deze bestaan globaal gezien uit een scanning en OCR module en een workflow module. Ik zou echter voor de workflow module een bredere oplossing willen, want ik verwacht deze ook nodig te hebben voor latere diensten, bijv. uitgaande facturen, betalingsverkeer, enz.

Verder moeten er interfaces worden gebouwd met de boekhoudsystemen van de klanten. Hiervoor lijkt mij een middleware/eai/messagebroker aplicatie een goede oplossing, ook weer met het oog op later toe te voegen fuctionaliteiten.

Tenslotte moet er het geheel nog webenabled worden gemaakt, incl. beveiliging (extranet-achtig).

 

Kan iemand mij op het spoor zetten van de juiste architectuur/hardware/software om dit op te bouwen dan wel een persoon/bedrijf kunnen aanraden die mij hierover onafhankelijk kan adviseren (dus zonder dat ze een bepaald platform of leveranciers van oplossingen vertegenwoordigen, en ook zonder dat ze direct een consultancy opdracht van tig dagen willen schrijven).

Frank

[Alef Arendsen]

De eerste dienst wordt het elektronisch verwerken van inkomende facturen. Ik wil hiervoor een standaard applicatie gebruiken. Deze bestaan globaal gezien uit een scanning en OCR module en een workflow module.

Een klant van ons heeft hier eens onderzoek naar gedaan(crediteurbeheer en workflow). De applicaties die beschikbaar zijn om dit alles te doen zijn schreeuwend duur heb ik me laten vertellen. Maar goed, jij zal dat misschien beter weten dan ik. Als je een betaalbare oplossing weet (zonder crediteuren op te dragen een bepaald format voor hun factuur te hanteren), koop ik het meteen :).

 

Ok, workflow. Wij hebben hier redelijk wat ervaring mee en ik heb dan inmiddels ook meerdere workflow applicaties uitgeprobeerd. Nog nooit is er mij er eentje goed bevallen (van de standaard pakketten tot en met de opensource libraries aan toe).

 

Zelf heb ik een aantal keren workflow in een applicatie moeten inbouwen en veelal hebben we dat zelf ontwikkeld.

 

De basis van je applicatie zal inderdaad een of ander EAI platform moeten worden. Het klinkt alsof je je redelijk op het integratievlak begeeft en dat dat ook het belangrijkste is, naast het workflow verhaal. Laat ik even kort door de bocht gaan: de huidige oplossingen / platformen / systemen die workflow bieden doen dit op een zodanige manier dat het of te traag wordt naarmate je meer workflow toevoegd, of eisen stelt aan de systemen waarop acties uitgevoerd worden die workflow moeten generen. Ik wil wel ingaan op de redenen waarom dat zo is, maar dat zou te ver voeren. Om to-the-point te komen, de oplossing is om beveiliging en workflow aan het systeem te externaliseren. Workflow moet niets te maken hebben met financiele boekingen, facturen, of iets dergelijks, maar met acties en gebeurtenissen in het systeem in het algemeen. Dat probeer ik te zeggen met externaliseren.

 

<>Laat dat externaliseren nou net mogelijk zijn met het nieuwste buzz-word: AOP. De toekomst in de EAI-markt en enterprise applications in het algemeen is aspect oriented programming en design. Bestaande platformen werken nog niet met deze technologien (das niet helemaal waar: BEA WebLogic heeft wat AOP functionaliteit); het is pas net een beetje mainstream aan het worden.

<>

 

Ok, wat belangrijk is, is ten eerste de juiste gereedschappen kiezen. Als je technisch gezien een beetje vernieuwing wel aandurft, kijk dan naar de opensource wereld. Daar zijn op het gebied van AOP en enterprise software nog steeds (vind ik) de beste gereedschappen te vinden.

 

Architectuur: ik blijf Microsoft extreem geschikt vinden voor het MKB (maar dan niet het groter MKB). Java/J2EE wordt interessant als het om grotere bedrijven / complexe modellen gaat of als je een application service provider wil worden. Dat zijn de enige keuzes mijns inziens (geen PHP of Perl ofzo voor dit soort systemen). Als ik het nu zou moeten zeggen zou ik voor Java/J2EE gaan (maar ik ben bevooroordeeld hier :) ).

 

Hardware: geen zorgen over maken nog. Via hebben een compleet custom verkoopmanagement systeem met workflow en offerte generatie voor een bedrijf met 200 man draaien op een machine van 3500 euro, dus maak je daar geen zorgen om.

 

(dus zonder dat ze een bepaald platform of leveranciers van oplossingen vertegenwoordigen, en ook zonder dat ze direct een consultancy opdracht van tig dagen willen schrijven).

Iemand anders dan onszelf aanwijzen kan ik niet :). Als je verder wilt discussieren over dit onderwerp kan dat wat mij betreft hier. Dan hebben de overige leden van het forum er ook nog wat aan. Zodra het te specifiek wordt of je teveel informatie prijs moet geven, geef je maar een gil :).

 

p.s. misschien kun je wat meer vertellen over hoe je dingen denkt in te gaan steken en hoezeer je dingen zelf wil gaan bouwen, etcetera.

 

 

[Pim de Bokx]

He Frank, leuk je hier tegen te komen. Dit onderwerp blijft je facineren hè? Mij ook trouwens. Belachelijk dat zelfs bij al die ITbedrijven zoveel nog met papierhandel te maken heeft.

 

In de US is het electronisch factureren, bestellen etc al veel meer ingeburgerd. In nederland zijn wel bedrijven met ervaring op dat vlak met name in ketens van leveranciers. EDI/XML zijn daar bekende protocollen voor secure gegevensuitwisseling. Je zou eens met www.lunatech.com in Rotterdam kunnen praten, die hebben daar dacht ik ervaring mee.

 

Inscannen: ik zie het voordeel van inscannen niet zo, het is vast niet minder werk dan de gegeven overtikken. Ik heb ook het idee daat je aan de verkeerde kant begint, je zou eerst een principe moeten hebben hoe je eenvoudig cashmanagement in beeld brengt en managed. Als je wat op US websites surft kom je hele makkelijke functies tegen en integraties met boekhouding en betaalmodule waar je van gaat watertanden tegen zeer scherpe prijs (<100 euro). De kracht van deze software ontstaat pas als de juiste interfaces hun werk kunnen doen, ook voor je klant. Het inscannen van facturen is dan een optionele interface papier>digitaal (XML formaat).

 

Mijn droom: uit je registratiesysteem maak je een factuur, deze wordt per email verzonden. Onderaan de email zitten knoppen waarmee de ontvanger aangeeft wat hij ermee wil:

- betalen: via prepay account/ el bankieren/ girotel/ creditcard

- importeren in boekhouding: kiezen voor welke

- afwijzen met toelichting

 

Ik krijg rekeningen binnen via email: ik stuur ze naar een speciale emailbox waar de email wordt ingelezen (geschikt voor platte tekst, rich text, html en pdf), voordat de fact in mijn systeem wordt opgenomen kun je net als met OCR nog even controleren. Na de check wordt het een boeking in mijn systeem, waarmee de nodige acties kunnen worden uitgevoerd. Indien ik wil dat een accountmanager of uitvoerder de rekening checkt heb ik de workslowmodule als add-on aangeschaft. Deze is geintegreerd met email of met mijn ERPsysteem.

 

etc.

 

Succes in ieder geval!

 

P.S. ik ken drie ondernemers bij ons die in dit onderwerp geinteresseerd zijn: www.fenetre.nl www.exa-omicron.nl en www.speedlinq.nl alle drie vanuit een ander oogpunt overigens.

 

 

 

 

[frank.custers]

Heren, dank voor de reactie. Misschien heb ik iets nog niet duidelijk gemaakt: het is de bedoeling om deze factuurverwerkingsdienst als een soort ASP aan te bieden en dus zonder investeringen vooraf voor de klanten (ik kom dus graag eens langs bij jullie voor een sales pitch om e.e.a. toe te lichten :)). De applicaties die hiervoor in de markt zijn, zijn duur, maar in een ASP model gaat dit werken. De klant kan dus arbeidskosten besparen omdat de handmatige verwerking van de facturen nu elctronisch door ons wordt gedaan. Verder zijn er veel verborgen kosten in het factuurverwerkingsproces (die ik ook graag eens kom toelichten :) :)).

 

Pim, voor betreft het handmatig verwerken vs. scannen en OCR'en: dit is wel degelijk sterk kostenbesparend (diverse studies, eigen onderzoek en diverse prospects bevestigen dit). En ik denk dat je droom een stuk dichterbij komt, wanneer mijn project draait. Voorlopig alleen aan de kant van mijn klant en niet bij de klant z'n leveranciers (dus alleen de tweede alinea van je droom), maar dat is een kwestie van tijd. Zou je verder enkele voorbeelden kunnen geven van de US cash mngt sites die jij beschrijft.

 

Ten aanzien van de opmerkingen van 'Aleph': kun je aangeven wat de belangrijkste nadelen zijn van de standaard workflow pakketten en hoe je die door zelf te ontwikkelen hebt omzeild. Het externalisren van de workflow klinkt interessant, maar ik begrijp nog niet helemaal hoe dat zou moeten werken.

 

T.a.v. platform/architectuur: de meeste standaard applicaties voor factuurverwerkingen 'moeten' draaien op een Windowsplatform (server + operating system). Als dan de workflow + eai op een ander platform draaien, heb je dan 2 verschillende systemen nodig ( ??? of begrijp ik het nu niet helemaal)? Ik denk dat hier mijn technische kennis te beperkt is: wat is het verschil tussen de architectuur en de gereedschappen?

 

Het is/was verder de bedoeling zo veel mogelijk gebruik te maken van standaard applicaties. De meeste van de applicaties die ik nl beschikbaar wil maken voor MKB+ bedrijven draaien al jaren bij de grote multinationals, en waarom het wiel opnieuw uitvinden als dat al eens is gedaan. Echter, om tot een homogeen geheel te komen als ik een aantal functies naast elkaar heb draaien (ik geef toe, dit is toekomstmuziek), moet ik nu nadenken over functionaliteiten die overlapend zijn (zoals de workflow en de intergratie met de systemen van de klant). Misschien kunnen we buiten de uitzending om eens een afspraak maken om hierover verder te praten. Pim, dat geldt ook voor jou (en de ondernemers binnen BViT) natuurlijk!

 

 

[Alef Arendsen]

Heren, dank voor de reactie. Misschien heb ik iets nog niet duidelijk gemaakt: het is de bedoeling om deze factuurverwerkingsdienst als een soort ASP aan te bieden en dus zonder investeringen vooraf voor de klanten (ik kom dus graag eens langs bij jullie voor een sales pitch om e.e.a. toe te lichten :)). De applicaties die hiervoor in de markt zijn, zijn duur, maar in een ASP model gaat dit werken. De klant kan dus arbeidskosten besparen omdat de handmatige verwerking van de facturen nu elctronisch door ons wordt gedaan. Verder zijn er veel verborgen kosten in het factuurverwerkingsproces (die ik ook graag eens kom toelichten :) :)).

Haha. Hmmm, zelf probeer ik m'n het aantal crediteuren (en ook het aantal facturen wat ze sturen) zoveel mogelijk te limiteren. Dit lukt me aardig :). Maar je hebt gelijk, het kost veel tijd!

 

Ten aanzien van de opmerkingen van 'Aleph': kun je aangeven wat de belangrijkste nadelen zijn van de standaard workflow pakketten en hoe je die door zelf te ontwikkelen hebt omzeild. Het externalisren van de workflow klinkt interessant, maar ik begrijp nog niet helemaal hoe dat zou moeten werken.

Het verhaal wordt een klein beetje technisch als ik dit uit wil leggen, maar ik zal het even proberen. Workflow is typisch iets wat je extern moet houden aan de elementaire acties binnen je systeem (inladen van een factuur, muteren van een grootboek, etcetera). Ditzelfde geld - zoals gezegd - voor beveiliging.

 

Het probleem bij veel huidige workflow systemen is dat het modelleren van de workflow die deze elementaire acties aan elkaar koppelt veelal als onderdeel wordt gezien van deze elementaire acties. Dit heeft een aantal nadelen. De belangrijkste is dat er een heel sterke afhankelijkheid bestaat tussen de elementaire acties binnen een systeem en de workflow. Iets concreter: het feit dat iets uitgevoerd moet worden en wanneer heeft niets te maken met wat er daadwerkelijk moet worden uitgevoerd. Deze scheiding moet je handhaven, at all costs. In applicatieontwerp en heb je het dan over crosscutting concerns. Dit is 1 van de meer uitdagender problemen de afgelopen paar jaar in systeemontwerp.

 

Je vraagt hoe wij het opgelost hebben. Nou, door veel te focussen op die separation of crosscutting concerns zoals het mooi heet, maar vooral ook niet meteen alles te willen. Helaas heeft nog niemand een ideaal workflowsysteem geschreven, ook wij niet :).

 

T.a.v. platform/architectuur: de meeste standaard applicaties voor factuurverwerkingen 'moeten' draaien op een Windowsplatform (server + operating system). Als dan de workflow + eai op een ander platform draaien, heb je dan 2 verschillende systemen nodig ( ??? of begrijp ik het nu niet helemaal)? Ik denk dat hier mijn technische kennis te beperkt is: wat is het verschil tussen de architectuur en de gereedschappen?

Concreet heb je de keuze tussen twee architecturen. .NET en J2EE. .NET draait (tot nader orde alleen op Windows), J2EE draait overal op (Windows, Unix, Linux). Voor de duidelijkheid, we hebben het alleen over de server-achitectuur.

 

Met de keuze van gereedschappen bedoel ik min of meer de keuze voor het gebruik van bepaalde standaardsystemen of componenten.

 

Het is/was verder de bedoeling zo veel mogelijk gebruik te maken van standaard applicaties. De meeste van de applicaties die ik nl beschikbaar wil maken voor MKB+ bedrijven draaien al jaren bij de grote multinationals, en waarom het wiel opnieuw uitvinden als dat al eens is gedaan. Echter, om tot een homogeen geheel te komen als ik een aantal functies naast elkaar heb draaien (ik geef toe, dit is toekomstmuziek), moet ik nu nadenken over functionaliteiten die overlapend zijn (zoals de workflow en de intergratie met de systemen van de klant).

 

Misschien kunnen we buiten de uitzending om eens een afspraak maken om hierover verder te praten. Pim, dat geldt ook voor jou (en de ondernemers binnen BViT) natuurlijk!

Geen probleem. Ben erg benieuwd naar hoe je een en ander denkt aan te pakken! Het idee klinkt goed moet ik zeggen!

 

groeten,

 

Alef Arendsen

[2thePoint]

Ik wil je niet ontmoedigen, maar scannen van facturen is niet sneller...tenzij je inderdaad uniformiteit eist in de te ontvangen facturen...een goede adm. medewerk(st)er brengt facturen even snel (sneller) in dan jij een copietje kan maken, bovendien wordt er tijdens de invoer controles uitgevoerd op de factuur die jij na het scannen ook nog moet doen.

Misschien gaan de meeste wel sneller maar die facturen die niet goed ingescand worden kosten dan weer zo veel extra tijd dat je je tijdswinst ruimschoots weer kwijt bent. Probeer maar eens een factuur van SDU te scannen en daarna eentje van de Makro....

 

Ik weet uit eigen ervaringen o.a. en ook andere studies dat scanning en OCR leuk zijn voor de archiefboys maar NIET WERKEN in een boekhouding....

 

Ben tevens benieuwd wat je gaat rekenen voor deze service... en of dat goedkoper is dan mijn adm. medewerkster die ook nog koffie voor mij zet en de telefoon beantwoordt etc.....

 

 

[frank.custers]

Beste 2-the-point,

 

Dank voor je reactie. Ik heb inmiddels meerdere prospects enthousiast weten te krijgen voor mijn plannen. Dit zijn allen grotere MKB bedrijven, met tientallen/honderden mensen in dienst. Voor deze bedrijven is het wel degelijk interessant om hun inkomende facturen electronisch te laten verwerken. Hoe snel een meneer of mevrouw op de financiele afdeling ook kan werken, hetzelfde werk door machines laten doen is altijd goedkoper (zeker als dit repeterende bulkwerkzaamheden zijn volgens een vast stramien). Natuurlijk blijft er een taak bestaan voor de crediteurenadministratie (uitzonderingsgevallen, foutafhandeling, etc.), maar het aantal FTE op deze afdeling kan substantieel omlaag. Er zijn zeker grenzen aan de 'ideale' klant voor mijn propositie, maar ik ben redelijk zeker van de business case die ik van mijn verhaal heb gemaakt. Ook met jou/jullie kom ik graag eens praten over mijn verhaal en wat het voor jou/jullie kan betekenen.

 

PS Sorry voor de onpersoonlijke aanhef, maar van de meeste mensen in de verschillende fora is niet echt hun 'normale' naam te achterhalen.

[2thePoint]

hetzelfde werk door machines laten doen is altijd goedkoper

Ik ben het niet eens met je 'altijd'... ook hier mis ik weer het puntje van controles....een machine "pleurt" alles in de computer, maar een (goede) medewerk(st)er controleert tegelijk....Nu moet je dat toch nog achteraf doen ; factuurtje in de computer opzoeken, kijken/checken en de volgende opzoeken....en dat doe je normaal tegelijk met het invoeren.....is bijna even snel....want al invoerende controleer je....

Let wel ik heb het hier over een adm.mederwerk(st)er en geen DATATYPIST(E).

(zeker als dit repeterende bulkwerkzaamheden zijn volgens een vast stramien)

Als je het over Bulk-werk hebt met repeterende zaken lijkt het met slimmer om met crediteur afspraken te maken over elektronisch factureren... is nog sneller EN goedkoper....

Tuurlijk kun je het aantal FTE's naar beneden halen....maar of je de kosten ook echt naar beneden kan halen zonder af te doen aan de kwaliteit denk ik te betwijfelen....

 

Ik heb in het verleden gewerkt met Basware en die beloofden ook het een en ander...de fouten die echter door het inscannen in het systeem kwamen kostten ons achter meer tijd dan het inscannen opleverde....

 

2thepoint

(Egbert Punter)...

[Gast ivlaminckx]

Hoi,

 

kijk eens naar MS Biztalk Server. Workflow en integratie in een.

Zijn reeds goede ervaringen mee, ook in NL financiele wereld.

 

Bovendien heeft MS voor ASP'ers speciale pricingmodellen.

 

en als het lokaal moet (om wat voor reden ook) is ook daar een MKB variant van.

 

Beslist de moeite waard

 

groet en succes