Categorieën
Article

RPA in mensentaal

RPA staat voor Robotic Process Automation. Het is een software die in staat is manuele handelingen ‘na te doen’. Beeld je in: een medewerker moet vandaag gegevens die via de website per email binnenkomen, overtikken in een software pakket om de verdere opvolging te kunnen doen. Wel, dit soort handelingen kunnen geautomatiseerd worden met RPA, zonder aan de bron en doel applicatie iets te veranderen.

Elke organisatie kent manuele repetitieve taken die vandaag door medewerkers moeten worden uitgevoerd. Daarin is de manuele handeling niet meer dan een brug tussen een applicatie en een andere, dikwijls gebonden aan een aantal regels. En dat kan deels of geheel overgenomen worden door een RPA oplossing. RPA is dus geen integratie tussen systemen, maar een soort slimme plakband.

RPA kan een oplossing bieden voor taken die:

  • Repetitief zijn.
  • Gebaseerd op eenduidige logische regels.
  • Gaan over het bewerken van gestructureerde data.

RPA kan bijvoorbeeld emails openen en informatie er uithalen, databases lezen, data invullen, berekeningen uitvoeren op data, logica toepassen.

Wat vindt Foursevens van RPA?

We wegen in onze projecten steeds een aantal dingen af. Het antwoord op die vragen zal afhangen van de specifieke context, maar de vragen blijven dezelfde.

Wat is het precieze probleem?

Is de oplossing gebruiksvriendelijk?

Manueel overtikken van gegevens, het doet wat denken aan het Middeleeuws scriptorium maar dan in digitale vorm. Niemand wordt daar echt gelukkig van. In de juiste context is het overnemen van deze activiteiten door een RPA oplossing dus zeker het overwegen waard.

Is de oplossing duurzaam in de bredere architectuur van de organisatie?

Maar zoals problemen nooit los van elkaar staan, zo zijn los van elkaar staande oplossingen al snel een kluwen. Het gevaar van RPA is dat het een stopmiddel wordt voor slecht ontwerp van je enterprise architectuur. Daarmee veeg je dingen onder de mat, maar kan op termijn een totaal ondoorzichtelijk kluwen van automatische processen ontstaan waar niemand nog precies de inhoud van kent. RPA is maar het overwegen waard indien een API oplossing echt niet mogelijk is. Een API biedt een veel betere manier om te integreren dan RPA. Vaak loont het de moeite om dit goed te analyseren.

Zorgt RPA voor tijds of geldwinst?

Als RPA kan zorgen dat de weg naar een verdere digitalisering van je organisatie sneller gaat, vinden wij RPA het overwegen waard. Wij geloven dat het dan een transitie-oplossing kan zijn, of een goedkope oplossing om een paar losse eindjes aan elkaar te knopen (denk oude custom software links of rechts in minder kritische hoeken van je processen). Oude applicaties kunnen al eens in de weg staan van een doorgedreven digitalisering, RPA kan zeker onderdeel zijn van een oplossing daarvoor. Zeker als blijkt dat RPA een goedkopere oplossing is dan het eventueel aanpassen of herbouwen van die oude applicaties.

Ook bij het migreren van data tussen oude en nieuwe applicaties kan RPA een rol spelen. Weerom een tijdelijke.

RPA is dus applicatie-plakband, die in sommige gevallen heel goed van pas kan komen, maar waar voorzichtig mee moet worden omgesprongen.

Categorieën
Video

Digitale Dienstverlening

TV Foursevens sprak met Steve De Veirman, Online Strategist bij CM, over de weg naar digitale dienstverlening voor zijn organisatie.

Categorieën
Article

RFP procedures block digital innovation

When choosing enterprise solutions ‘RFP procedures’ are a common practice in most large organisations. RFP stands for Request for Proposal. RFPs tend to contain a bucket list of features. They aim at turning different product offerings into lines of comparable items in an Excel sheet. Belief is that a quick calculation of ‘off the shelf’, ‘no can do’ and ‘custom work needed’ answers will direct the decision makers towards the right product to buy.

changeyourmind

The list of features is usually based on three sources of information. First of all the product the company is currently using. The focus then lies especially on features that are missing from the current product and the frustrations that currently exist around bad features. Features that are heavily used with success often don’t make it to the list. Secondly the feature list is filled with what is currently fashionable. A quick read of marketing material from competing products serves that purpose. Vendor road maps with no relation whatsoever to the companies own maturity in the matter also serve as inspiration. And last but not least a totally random guess by management about where things are heading, adds the last few feature requests. Actual users of the current product don’t play a role in most RFP processes.

This is why an RFP will never favour products that answer a need or solve a problem in a totally innovative way. When product selection is based on old criteria, common solutions to existing problems, only products that answer needs in an old fashioned way can win the race.

Is there an alternative? We believe there is; first talk to your users, you’ll be surprised about how much they know and how clear their vision on the problem at hand can be. Then look at what products have achieved in other companies and make your shortlist. Then let the vendor prove what his product is worth by doing a proof of concept onsite. Will this take time? Yes it will, but so does your classic approach. Will this cost money? You probably want to be fair and pay candidates a little for their proof of concept work. But compared to the long-term cost of a wrongly chosen product, oh boy will this be cheap!

Are you lost at how to take it from here, we’ve done this before, we can do it again; Contact us!