iPaaS vs point-to-point vs middleware: com triar

La majoria dels parcs d'integracions del mid-market no es van dissenyar mai. Es van acumular. Algú va connectar el CRM a l'ERP perquè una comanda havia d'arribar a finances. Una altra persona va connectar la plataforma d'ecommerce perquè el magatzem havia de preparar les expedicions. Una tercera va connectar el sistema de magatzem amb un transportista. Cada decisió era assenyada per separat i la va prendre algú competent, i el resultat agregat és un parc que ningú no és capaç de dibuixar en una pissarra.

El cost d'això arriba més tard i de manera indirecta. Apareix com una estimació de projecte que sembla desproporcionada respecte al canvi sol·licitat, perquè el canvi toca quatre connexions no documentades. Apareix com una actualització de l'ERP que s'encalla perquè ningú no sap què depèn d'una interfície concreta. Apareix com un informe que no coincideix amb un altre informe per motius que triguen dos dies a rastrejar-se.

Aquest article tracta de la decisió estratègica més que de la connexió individual: quin enfocament d'integració adoptar com a estàndard, quant costa realment cadascun al llarg de la seva vida i —la pregunta que gairebé ningú no fa en el moment de la selecció— quant costa abandonar-lo.

L'article 16 d'aquesta sèrie aplica les mateixes opcions arquitectòniques específicament al flux de comandes d'ecommerce. Aquest text aborda la decisió a escala de tot el parc.

Per què això importa

L'arquitectura d'integració determina el cost del canvi, i el cost del canvi determina amb quina rapidesa una empresa pot fer qualsevol cosa.

Una empresa del mid-market, al llarg de cinc anys, normalment afegirà o substituirà diversos sistemes: una nova plataforma d'ecommerce, un sistema de magatzem, una migració de CRM, una adquisició que arriba amb el seu propi conjunt d'aplicacions. L'enfocament d'integració triat avui fixa el cost marginal de cadascun d'aquests esdeveniments. Una plataforma ben governada converteix cadascun en una qüestió de setmanes. Un parc point-to-point no documentat converteix cadascun en un projecte amb una estimació imprevisible.

També hi ha una dimensió de resiliència. Els parcs point-to-point concentren el coneixement en persones concretes, i les empreses del mid-market no retenen aquestes persones durant tota la vida de la integració. Quan qui va escriure la connexió se'n va, la connexió esdevé una caixa negra que tothom envolta en lloc de travessar, que és la manera com els parcs adquireixen fluxos de dades duplicats i contradictoris.

I hi ha una dimensió d'auditoria que aflora en els moments més inoportuns. Quan es qüestiona una xifra financera, la resposta sovint exigeix rastrejar com han arribat les dades al llibre major. Un parc sense traçabilitat documentada no pot respondre a això amb rapidesa, i «no estem segurs de com ha arribat aquí aquest número» és una frase desagradable davant d'un auditor.

D'un cop d'ull: els tres enfocaments al llarg de la seva vida

La fila que els clients examinen menys i lamenten més és el cost de sortida. La lògica implementada dins d'una plataforma s'expressa en els constructes d'aquella plataforma, i moure-la significa reimplementar-la i no migrar-la. Això no és un argument contra les plataformes: és un argument a favor de mantenir un registre en llenguatge planer del que fa cada flux, independent de l'eina que l'implementa.

Què funciona i sobre què cal ser honest

Què funciona:

Estandarditzar un únic enfocament, amb excepcions documentades. El problema en la majoria dels parcs no és l'enfocament triat: és que tres enfocaments coexisteixen sense que ningú no hagi decidit. Triï un com a opció per defecte i exigeixi justificació per a apartar-se'n.

Nomenar un responsable abans de construir el primer flux. Els parcs d'integracions es degraden per acumulació de fluxos no documentats. Un responsable amb autoritat sobre la nomenclatura, la documentació i la revisió ho evita. És la decisió de governança amb més valor i no costa res.

Documentar cada flux amb independència de l'eina. Per a cada flux: origen, destinació, objectes, sentit, esdeveniment desencadenant, regles de transformació en llenguatge planer, comportament davant d'errors, responsable. Això és el que fa que el parc sigui comprensible per a la persona següent, sobrevivible quan canviï la plataforma i defensable davant d'un auditor.

Gestió centralitzada d'errors amb triatge mitjançant agents. Un tractament de fallades consistent i visible en tots els fluxos és un dels arguments més sòlids a favor d'una plataforma. Un agent que classifica les fallades, resol les mecàniques i encamina la resta amb el seu context és el que ho fa operativament sostenible en lloc d'una cua que ningú no llegeix.

Revisió periòdica per retirar fluxos morts. Els parcs acumulen fluxos que serveixen processos que ja no existeixen. Una revisió anual, retirant el que no s'utilitza, manté el parc proporcionat al negoci.

Sobre què cal ser honest:

Una plataforma no salvarà una empresa que no estigui disposada a governar-la. Les plataformes sense governança esdevenen parcs point-to-point amb una quota de llicència: la mateixa lògica no documentada, en una interfície més agradable. La disciplina és el producte; la plataforma només abarateix la disciplina.

Els preus en funció del volum poden sorprendre'l. Els costos de plataforma escalen amb el volum de transaccions, i el trànsit d'ecommerce i de marketplace escala de manera imprevisible. Modeli els seus costos amb el triple del volum actual abans de comprometre's, i entengui què compta com a transacció facturable.

El middleware tradicional acostuma a ser la resposta equivocada a escala mid-market. És capaç, i exigeix perfils especialitzats que les empreses del mid-market tenen dificultats per contractar, retenir o substituir. L'excepció és una empresa que ja tingui la plataforma, ja tingui els perfils i tingui un parc substancial ja construït al damunt.

El point-to-point no sempre és un error. Per a una empresa amb dos sistemes i sense plans d'afegir-ne més, una connexió directa ben documentada és proporcionada. La fallada no és triar-lo: és triar-lo repetidament.

La migració és feina de veritat, i endarrerir-la l'empitjora. Traslladar un parc existent a una plataforma implica funcionar en paral·lel, conciliar i fer el tall flux a flux. És un projecte de debò. També és més barat aquest any que el següent, perquè el parc continua creixent.

Marc de decisió: triar i governar

Recorri'l en ordre. Aturi's a la primera coincidència.

1. Sabria dibuixar el seu parc d'integracions actual, cada flux, de l'origen a la destinació?
Si no, elabori primer aquest inventari. Habitualment triga d'una a dues setmanes i rutinàriament troba fluxos que ningú no sabia que existien, més com a mínim un duplicat. Totes les decisions posteriors depenen de saber què té.

2. Té exactament dos sistemes que necessitin integració, sense plans d'afegir-ne més?
Una connexió point-to-point documentada és proporcionada. Documenti-la externament i fixi un desencadenant de revisió per quan aparegui un tercer sistema.

3. Té tres o més sistemes, o el pla d'afegir-ne un en un termini de dos anys?
Estandarditzi una plataforma d'integració. Assigni un responsable i defineixi estàndards de documentació abans del primer flux. La majoria de les empreses del mid-market que llegeixen això són aquí.

4. Ja té middleware substancial i els perfils per operar-lo?
Conservi'l, i governi'l. Migrar un parc de middleware que funciona i està ben dotat de personal rarament compensa la disrupció. Reavaluï-ho quan els perfils especialitzats esdevinguin difícils de sostenir.

5. Actualment està en point-to-point amb tres o més sistemes?
Planifiqui una migració, seqüenciada flux a flux fora dels períodes punta, amb funcionament en paral·lel i conciliació. Comenci pel flux que es trenca més sovint: l'alleujament operatiu finança el capital polític per a la resta.

6. Té una plataforma sense responsable designat i sense estàndard de documentació?
Arregli la governança abans d'afegir fluxos. Està acumulant el problema que va comprar la plataforma per evitar, i el cost de documentar a posteriori puja cada mes.

7. Parc governat, documentat i tot i així car de canviar?
És probable que la restricció sigui als sistemes i no a la integració: una personalització de l'ERP que converteix un objecte estàndard en no estàndard, o un sistema sense una API utilitzable. Això és un problema d'aplicació, no d'integració.

Cost i esforç indicatius

Es pressuposen volums de transaccions de mid-market i una única instància d'ERP. Els parcs multiinstància o multientitat allarguen aquests terminis. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

Com comparem els costos de les plataformes quan els models de preus són diferents?
Modeli el cost total a tres anys amb el seu volum previst, no amb el volum actual, i estableixi amb precisió què compta com a unitat facturable: un missatge, un registre, una execució de flux. Dues plataformes amb preus de tarifa semblants poden diferir substancialment a volum real per la manera com compten.

El vendor lock-in és una raó per evitar les plataformes?
És una raó per mitigar-lo, no per evitar-les. Mantingui documentació independent de l'eina sobre la lògica de negoci de cada flux i convertirà una sortida d'un exercici d'enginyeria inversa en una reimplementació. L'alternativa —point-to-point— té el seu propi lock-in, cap a persones concretes, que és més difícil de gestionar.

On encaixen els agents?
A sobre de qualsevol d'aquests enfocaments, gestionant excepcions i no el transport. La integració mou les dades; l'agent gestiona què passa quan la dada és incorrecta, incompleta o no quadra. Seleccionar una plataforma per la seva capacitat d'agents és raonable; esperar que un agent compensi un mal encaix arquitectònic no ho és.

Hauríem de construir la nostra pròpia capa d'integració?
Gairebé mai a escala mid-market. És un compromís de desenvolupament de producte —monitoratge, reintents, registre d'esdeveniments, gestió de credencials, versionat— que competeix per la capacitat d'enginyeria que hauria d'anar al seu negoci real. L'excepció és un requisit genuïnament inusual que cap plataforma no suporta, cosa més rara del que els equips es creuen.

Com justifiquem això quan ara mateix no hi ha res trencat?
Plantegi-ho com a cost del canvi i no com a cost de la fallada. Prengui els tres darrers projectes que van tocar la integració i estimi quant se'n va anar en cadascun a entendre les connexions existents. Aquesta xifra és l'impost recurrent, i és el cas de negoci honest.

Un cop triat, quant es triga realment a aixecar un iPaaS o una capa de sincronització?
Menys del que la majoria d'equips pressuposta, si primer es pren la decisió d'amunt. Un partner d'implementació certificat — Stacksync, en concret per a sincronització bidireccional en temps real — sol poder tenir una primera integració en producció en poques setmanes. El que triga més és justament allò de què tracta aquest article: acordar el patró, mapejar el model de dades i decidir qui és propietari de les excepcions. Tria la plataforma després d'aquesta feina, no abans, i el desplegament deixa de ser el coll d'ampolla.

Tancament — Propers passos

L'estratègia d'integració és una decisió sobre el cost marginal de cada futur canvi de sistema, presa abans de saber quins seran aquests canvis. Per això els criteris que importen no són funcionalitats sinó governança: qui n'és el responsable, com es documenta, com es gestionen les fallades i quant costa sortir-ne.

El punt de partida és el mateix amb independència de quina fila del marc li correspongui: inventariï el parc. Una o dues setmanes, i trobarà fluxos que ningú no recorda, com a mínim un duplicat i normalment el motiu pel qual un projecte recent va costar més del previst.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultoria de NetSuite que atén clients del mid-market a tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen la introducció manual de dades entre els equips de vendes i de finances. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació, convertint fluxos de comandes fragmentats en sistemes fiables que es supervisen ells mateixos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fonts

Els URL són a nivell d'editor i s'han de verificar abans de la publicació.

• Oracle NetSuite, documentació de SuiteTalk i d'integració — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, recerca sobre plataformes d'integració i Magic Quadrant for iPaaS (en gran mesura d'accés reservat a clients) — https://www.gartner.com
• The Open Group, TOGAF — orientacions d'arquitectura d'aplicacions i d'integració — https://www.opengroup.org
• Comissió Europea, VAT in the Digital Age (ViDA) — implicacions de les dades estructurades i de la facturació electrònica en el disseny d'integracions — https://taxation-customs.ec.europa.eu
• Experiència de projectes d'Atypical Tech, parcs d'integracions del mid-market a tota la península Ibèrica
• Stacksync, blog de la plataforma d'integració i sincronització en temps real — https://www.stacksync.com/blog