ERP

Desplegament d'un ERP

Tipus de desplegament

Tradicionalment, les aplicacions ERP/CRM/BI han estat allotjades a les instal·lacions de les organitzacions compradores de les llicències de l’aplicació, desplegament conegut majoritàriament com a on-premise i, en menor grau, com a in-house. Però això està canviant.

La història dels tipus de desplegament de les aplicacions de gestió empresarial ha anat lligada a l’evolució que ha tingut la tecnologia. En aquests moments podem dir que estem entrant en una nova època: l’època de la informàtica en núvol (cloud computing) i amb ella, diversos models de desplegament (IaaS, PaaS i SaaS) que s’imposaran o conviuran amb el model tradicional on-premise.

Per saber on som ens convé, en un primer lloc, conèixer els tipus de desplegament que hi ha hagut al llarg de la història i, per poder dur a terme desplegaments en el moment actual, ens cal poder distingir els requeriments associats.

En la primera època (la dècada dels 60 i dels 70) les aplicacions residien en grans ordinadors (mainframes) ubicats en les dependències de l’organització i els usuaris disposaven de terminals (pantalles sense memòria ni capacitat de procés) connectades amb l’ordinador central.

La segona època arriba en la dècada dels 80, amb l’eclosió dels ordinadors personals. Les aplicacions empresarials van anar adoptant l’arquitectura de dues capes (client-servidor), en les quals continua existint l’ordinador central (servidor –un o diversos–) que conté les bases de dades i en la qual la terminal de l’anterior època queda substituïda per l’ordinador personal que, en disposar de memòria i capacitat de procés, incorpora les aplicacions a executar. L’arquitectura client-servidor ensopega aviat amb el problema del manteniment de les aplicacions, ja que cada vegada que la lògica de negoci canvia o evoluciona cal actualitzar l’aplicació en tots els ordinadors personals clients.

Per aquest motiu, s’adopta ben aviat l’arquitectura de tres capes (presentació-negoci-dades) en la qual els clients tenen aplicacions senzilles que únicament presenten les dades subministrades per un o diversos servidors d’aplicacions, contenidors dela capa de negoci, que ha confeccionat aquelles dades a partir de la informació subministrada pels servidors de la capa de dades.

La tercera època s’inicia a mitjans de la dècada dels 90, coincidint amb el boom d’Internet i va acompanyada de la contínua millora de l’ample de banda. Les aplicacions empresarials cerquen mecanismes per facilitar la connexió dels òrgans de comandament de les empreses des d’ubicacions remotes. Això fa que proliferin programaris que, aprofitant Internet, faciliten la connectivitat remota i obren en els dispositius remots (portàtils i PDAs) sessions client contra el servidor d’aplicacions. De ben segur que un dels programaris més coneguts és l’escriptori remot del sistema operatiu Microsoft Windows. Però aquests programaris presenten un problema: cal tenir instal·lat en el dispositiu remot el programari adequat per poder establir la connexió i això no sempre és factible. Ara bé, sense por a equivocar-nos, quin és el programari que tenen avui en dia tots els dispositius que es connecten a Internet, sigui quin sigui el sistema operatiu utilitzat (Windows, Linux, Mac, iOS, Android…)? Un navegador, oi? En conseqüència, es tracta d’aconseguir que a través del navegador puguem executar les aplicacions empresarials.

Durant la primera dècada del segle XXI, encara dins la tercera època, les aplicacions empresarials es van acomodant a la nova situació tecnològica i faciliten solucions accessibles des dels navegadors web. L’arquitectura de tres capes continua sent vàlida per a la nova situació. Simplement cal afegir un servidor web davant el(s) servidor(s) d’aplicacions per permetre la connexió des dels navegadors. Els clients tradicionals poden continuar existint i es comuniquen directament amb el(s) servidor(s) d’aplicacions.

En aquesta nova arquitectura hi ha desavinences sobre la capa on ubicar el servidor web. Hi ha autors que, a causa del fet que el servidor web simplement s’encarrega de confeccionar les pàgines que es visualitzen en el navegador, el consideren com a part de la capa de presentació. D’altres, com que és un servidor d’aplicacions, l’ajunten amb els servidors d’aplicacions on hi ha la capa de negoci. Per últim, hi ha autors que parlen d’arquitectura de quatre capes, destinant una capa específicament al servidor web.

L’arquitectura de quatre capes (aplicacions empresarials que permeten l’accés web) és d’extrema actualitat. Les aplicacions que no incorporen aquesta funcionalitat estan abocades a la desaparició. Poden sobreviure a causa del cost que suposa un canvi total de programari però difícilment podran ampliar la seva quota de mercat.

Finalment, ens trobem en el futur que ja és present: la quarta època. La informàtica en núvol (cloud computing) és un sistema d’emmagatzematge i ús de recursos informàtics basat en el servei en xarxa, que consisteix en oferir a l’usuari un espai virtual, generalment a Internet, en què pot disposar de les versions més actualitzades de maquinari i programari.

Hi ha tres models d’informàtica en núvol:

• Infraestructura com a servei (IaaS, de Infraestructure as a Service), en el qual l’usuari contracta únicament les infraestructures tecnològiques (capacitat de procés, d’emmagatzematge i/o de comunicacions) sobre les quals hi instal·la les seves plataformes (sistemes operatius) i aplicacions. L’usuari té el control total sobre les plataformes i aplicacions, però no té cap control sobre les infraestructures.
• Plataforma com a servei (PaaS, de Platform as a Service), en el qual l’usuari contracta un servei que li permet allotjar i desenvolupar les seves pròpies aplicacions (ja siguin desenvolupaments propis o llicències adquirides) en una plataforma que disposa d’eines de desenvolupament per tal que l’usuari pugui elaborar una solució; en aquest model, el proveïdor ofereix l’ús de la seva plataforma que a la vegada es troba allotjada en infraestructures, de la seva propietat o d’altri. L’usuari no té cap control sobre la plataforma ni sobre la infraestructura però manté el control total sobre les seves aplicacions.
• Programari com a servei (SaaS, de Software as a Service), en el qual l’usuari contracta la utilització d’unes determinades aplicacions sobre les quals únicament pot exercir accions de configuració i parametrització permeses pel proveïdor. L’usuari no té cap control sobre l’aplicació, la plataforma i la infraestructura.

Els models IaaS i PaaS ja fa temps que s’estan utilitzant (des que l’ample de banda ho ha fet possible) i el model SaaS també en aplicacions vinculades a Internet, com per exemple el correu electrònic. En canvi, fins fa ben poc (cap a l’any 2010) no han començat a aparèixer aplicacions empresarials (ERP/CRM/BI) sota el model SaaS.

No hem de confondre tenir una aplicació empresarial en el núvol, de la qual nosaltres n’hem adquirit llicències però hem optat per tenir-la instal·lada a Internet (model IaaS o PaaS) enlloc de tenir-la a casa nostra (on-premise), amb contractar la utilització d’una aplicació que algú té allotjada en el núvol (model SaaS) i per la qual no hem d’adquirir cap llicència sinó únicament prestacions (nombre d’usuaris i funcionalitats).

Entre els beneficis del model SaaS, cal considerar:

• Integració comprovada dels serveis en xarxa.
• Prestació de serveis a nivell mundial.
• Cap necessitat d’inversió en maquinari.
• Implementació ràpida i sense riscos. La posada en marxa només precisa de la configuració i parametrització permesa pel proveïdor.
• Actualitzacions automàtiques ràpides i segures.
• Ús eficient de l’energia, davant l’energia requerida pel funcionament d’una infraestructura on-premise.

Entre els inconvenients del model SaaS, cal considerar:

• Dependència dels proveïdors de serveis.
• Disponibilitat de l’aplicació lligada a la disponibilitat d’Internet.
• Por a sostracció o robatori de les dades “sensibles” del negoci, ja que no resideixen a les instal·lacions de les empreses.
• Perill de monopolis referents als serveis facilitats pels proveïdors.
• Impossibilitat de personalitzar l’aplicació, fora de la configuració i parametrització permesa pel proveïdor.
• Actualitzacions periòdiques que poden incidir de manera negativa en l’aprenentatge dels usuaris d’orientació no tecnològica.
• Existència de focus d’inseguretat en els canals a recórrer per arribar a la informació, si no s’utilitzen protocols segurs (HTTPS) per no disminuir la velocitat d’accés.
• Possible degradació en els serveis subministrats pel proveïdor davant l’augment de clients.

Sembla que el model SaaS és una tendència de futur, sobretot per petites i mitjanes empreses que no disposen de recursos informàtics adequats per poder respondre al repte d’adquirir llicències d’una aplicació empresarial (ERP/CRM/BI) i procedir a la seva instal·lació/configuració/personalització (ja sigui sota model on-premise o sota models IaaS/PaaS). Llavors, endinsar-nos en la implementació, explotació i adequació dels sistemes de gestió empresarial sembla una incongruència, oi? Prenguem-nos-ho per la banda positiva: ens convé introduir-nos en els sistemes de gestió empresarial per poder assessorar a les petites i mitjanes empreses que ens demanin consell i per dur a terme un correcte desplegament en aquelles organitzacions per optin pels models on-premise o IaaS/PaaS.

Requeriments

Els desplegaments d’aplicacions empresarials avui en dia poden tenir lloc sota dos models: on-premise (a casa del comprador de les llicències) o IaaS/PaaS (dues modalitats d’informàtica en núvol). En qualsevol cas, hem de pensar que l’aplicació empresarial està desenvolupada sota l’arquitectura web de tres capes i, per tant, cal disposar de:

• Servidor d’aplicacions.
• Servidor web, que possiblement compartirà maquinari amb el servidor d’aplicacions.
• Servidor de dades (SGBD) que molt possiblement serà un SGBD relacional o objecte-relacional.

Per atendre a aquestes necessitats, cal avaluar què necessitem i què tenim. Aquesta tasca, però, s’escapa de les capacitats d’un desenvolupador de programari i són tasques per encomanar a consultors i administradors de sistemes. Però, és possible que ens toqui fer-ho en una PIME que ens hagi demanat consell i no hi hagi consultors ni administradors de sistemes. En un cas així, caldrà:

• Identificar els requeriments directes de maquinari (bàsicament RAM, CPU i capacitat de disc dur) especificats pel programari de gestió empresarial que s’ha d’instal·lar, tenint en compte la conveniència o no de virtualitzar els servidors.
• Identificar l’SGBD amb el que pot treballar el programari que s’ha d’instal·lar. Algunes vegades, un mateix programari de gestió empresarial permet utilitzar diferents SGBD, situació en la qual cal analitzar quin d’ells és millor en funció de les necessitats de l’empresa i del seu cost, tenint en compte que n’hi ha de molt potents amb versions gratuïtes. Així, per exemple, una botiga de bicicletes que adquireixi un ERP per dur la gestió informatitzada dels circuits compravenda, inventari i comptabilitat és possible que en tingui prou amb un SGBD ofimàtic, com ara Microsoft Access, mentre que un supermercat, amb el mateix ERP, és possible que no en tingui prou amb un SGBD ofimàtic i en precisi un de major potència.
• Identificar els requeriments indirectes de maquinari a partir dels requeriments de maquinària propis de l’SGBD escollit.
• Identificar mecanismes idonis per a efectuar còpies de seguretat de les dades que permetin la recuperació segons les necessitats de disponibilitat de l’organització. Tot programari de gestió empresarial ha d’anar acompanyat d’un mecanisme de recuperació adequat que cal testar periòdicament. En una organització amb disponibilitat 24×7 (és a dir, que no pot aturar en cap moment) caldrà preveure una estratègia de còpies de seguretat en calent i això repercutirà en l’elecció de l’SGBD. En canvi, en una organització que s’aturi unes hores al dia, podem preveure una estratègia de còpies de seguretat en fred. En qualsevol cas (còpies en calent o en fred), cal pensar en la necessitat o no de disposar d’un sistema de còpies que permeti, davant d’una catàstrofe, la recuperació de tots els moviments efectuats des de la darrera còpia de seguretat fins al moment de la catàstrofe. És a dir, si la darrera còpia de seguretat (en calent o en fred) és de les 0.00h de la nit anterior i a les 11.30h es produeix una catàstrofe que ens obliga a tibar de la còpia de la nit anterior, podem assumir haver perdut tots els moviments efectuats des de la nit anterior fins al moment de la catàstrofe? Els grans SGBD permeten activar mecanismes de registre diari (log en anglès) que emmagatzemen cronològicament en un fitxer les operacions de processament de dades efectuades a la base de dades, de manera que davant una caiguda del sistema i de la darrera còpia de seguretat, permeten restablir tots els moviments efectuats en el sistema.
• Identificar mecanismes per recuperar el sistema informàtic davant un error de maquinari. Davant un mal funcionament de qualsevol peça de maquinari (placa base, memòria, processador o disc dur), tot i que tinguem contractat un servei de manteniment, podem assumir tenir el sistema aturat? Hi ha ocasions en què és possible (botiga d’informàtica, en la qual si fem alguna venda podem anotar-la a mà) i ocasions en què no és possible (us imagineu una botiga en línia d’Internet en la qual falla el sistema informàtic i ha d’estar aturada unes hores?). En el cas que no sigui possible una aturada d’hores, quina és la millor solució? Avui en dia la utilització de servidors NAS per a l’emmagatzematge amb funcionalitats RAID activades conjuntament amb la virtualització dels servidors és, possiblement, la millor solució. Hi ha sistemes que permeten tenir els servidors virtualitzats en un servidor de virtualització que cap en un llapis òptic (és a dir, pot no ser en un disc dur) de manera que, davant una aturada de la màquina (problema de placa base, processador o memòria) podem utilitzar el llapis òptic per posar en marxa ràpidament el servidor de virtualització en qualsevol altra màquina (encara que tingui menys prestacions). A més, un problema en l’emmagatzematge en el servidor NAS queda cobert per les funcionalitats RAID activades, de manera que la recuperació pot ser molt ràpida.

Què és un ERP

En el mercat hi ha moltes aplicacions de gestió empresarial i no totes elles poden ser considerades un ERP; són simplement aplicacions de gestió i hi ha diferències fonamentals entre les aplicacions de gestió i els ERP, malgrat l’intent de moltes empreses, mitjançant estratègies de màrqueting, d’intentar vendre els seus productes amb la denominació ERP per tal d’obtenir un valor agregat als seus productes sense incrementar la seva funcionalitat.

Hi ha tres característiques fonamentals que defineixen un ERP:

• És un sistema integral: la pròpia definició d’ERP indica que és una aplicació que integra en un únic sistema tots els processos de negoci de l’empresa, així manté les dades d’una forma centralitzada. Això implica que la informació no pot estar duplicada i que només s’introdueix una única vegada. Aquesta definició descarta:
  • Programes basats en múltiples aplicacions (en ocasions denominades suite) independents o modulars que dupliquen la informació (malgrat l’enllacin automàticament).
  • Programes que no centralitzen la informació en una única base de dades.
  • Programes que no emmagatzemen les dades en un SGBD sinó que utilitzen sistemes gestors de fitxers, anteriors als SGBD.
• És un sistema modular: un ERP es compon de diversos mòduls on cada mòdul es centra en una àrea de negocis de l’empresa. Normalment els ERP tenen un mòduls troncals (bàsics) que s’adquireixen amb la compra de l’ERP (gestió de compravenda, control d’inventari, comptabilitat) i d’altres mòduls que s’adquireixen segons les necessitats de l’organització (gestió de projectes, gestió de campanyes, gestió de terminals punt de venda, comerç electrònic, producció per fases, traçabilitat, gestió de la qualitat, gestió de la cadena de subministrament…). És molt possible que una empresa no necessiti utilitzar, en un inici, tots els mòduls que facilita l’ERP, però és important saber que l’ERP els contempla, de cara a possibles necessitats de futur. En cas que sigui necessària la seva utilització, l’organització no es veurà abocada a un canvi de programari en les àrees on ja estava utilitzant l’ERP.
• És un sistema adaptable: no hi ha dues empreses iguals i, per això, els ERP han de permetre l’adaptació a necessitats diverses, objectiu que s’assoleix a través de la configuració i parametrització dels processos empresarials. Fins i tot alguns ERP disposen d’eines de desenvolupament integrats que permeten desenvolupar processos d’acord a les necessitats de cada empresa.

Enllaços

Material adaptat del material de l'IOC [1]