El Fantasma Empresarial: Quan les decisions de despatx ignoren la realitat tècnica
Per què les iniciatives multimilionàries fallen quan es prioritza el prestigi d'un proveïdor sobre la viabilitat de l'arquitectura.
En les meves tres dècades en l’enginyeria de programari, he vist un patró recurrent que és molt més car que qualsevol error de codi: el projecte d’alt nivell que és “massa gran per fallar”, fins que finalment ho fa.
He estat testimoni d’iniciatives amb pressupostos de vuit xifres que es descarten completament abans d’arribar a producció. No es tracta de simples fallades tècniques; són el resultat d’una desconnexió fonamental entre la sala de juntes i el codi. Sovint, es pren la decisió d’adoptar una “solució global”, ja sigui un ERP massiu, un sistema de facturació especialitzat o un motor de processos BPM no perquè encaixi en l’arquitectura existent, sinó perquè és un nom “segur” per presentar davant un consell d’administració.
La trampa del prestigi
La direcció sol estar sota una pressió immensa per justificar la despesa tecnològica. Seleccionar un tità se sent com comprar una assegurança: si el projecte falla, sempre poden dir que van contractar els millors del món. Però “el millor” per a una empresa pot ser una camisa de força per a una altra. Quan es gasta una fortuna en una llicència, el programari deixa de ser una eina per convertir-se en un mandat. He vist equips obligats a “fer que funcioni” amb sistemes incompatibles, cosa que porta a anys de pegats i reconstruccions, per acabar abandonant el projecte quan la complexitat esdevé immanejable i de pas culpant-los a ells del fracàs.
El cicle de vida d’una iniciativa fallida
El camí cap a aquests projectes “fantasma” sol començar amb un procés de compra que prioritza les demostracions comercials d’alt nivell sobre l’encaix arquitectònic real. S’adquireix una solució global basada en una presentació impecable que ignora el 90% de les casuístiques reals de l’empresa, deixant l’equip d’enginyeria amb la tasca impossible de cobrir aquest abisme. Una vegada signat el contracte i esgotat el capital polític, la iniciativa entra en una fase d’imposició; la direcció, cegada pel cost de l’oportunitat perduda, sol descartar les advertències tècniques primerenques com a simples “queixes de desenvolupadors” i persisteix en l’stack imposat.
Amb el pas dels mesos, el projecte entra inevitablement en una espiral de complexitat. Esdevé una caixa negra tècnica que és massa cara per aturar, però està massa trencada per desplegar. L’etapa final és l’inevitable tancament, que només passa quan la distància entre la visió de la directiva i la realitat tècnica és tan vàsta que ja no es pot ignorar. En aquest punt, el projecte s’abandona discretament i el cicle sol començar de nou amb el següent proveïdor “revolucionari”, deixant el deute arquitectònic subjacent sense resoldre.
El pragmatisme és la verdadera assegurança
El programari és una inversió, però el seu valor resideix en la seva utilitat, no en la seva marca. Els sistemes més robustos i escalables que he construït en 30 anys no van començar amb un acord de llicència massiu. Van començar amb una comprensió profunda del domini de negoci i l’elecció d’eines estables i extensibles, com l’ecosistema .NET o Microsoft Business Cental/NAV, que resolen problemes en lloc de crear conflictes polítics.
Si sou una part interessada en el negoci, els vostres enginyers sènior no són “difícils” quan qüestionen un mandat imposat des de dalt. Us estan proporcionant l’actiu més valuós en IT: un sistema d’alerta tècnica precoç. El paper d’un consultor sènior és tancar aquesta bretxa: proporcionar la veritat arquitectònica abans que es converteixi en una pèrdua milionària en el vostre balanç de resultats.