Mecánica de distribución: EOL – los productos no mueren de la noche a la mañana, mueren con mucha antelación.
Tarde o temprano, todos los dispositivos llegan al mismo punto: fin de vida útil (End of Life). El fabricante anuncia su descontinuación, el producto desaparece de la lista de precios y, en algún lugar de una sala de reuniones, un cliente final pronuncia la frase que todo revendedor teme: "¿Cómo que ya no está disponible? Tenemos 3.000 de ellos en funcionamiento. Hoy hablaremos de por qué esa frase nunca debería tener que pronunciarse. Porque los productos de nuestra industria no desaparecen de la noche a la mañana. Llegan al final de su vida útil con un anuncio público y prolongado; solo hay que prestar atención.
En primer lugar, ¿por qué un fabricante descontinuaría un producto que aún se vende bien? Rara vez por elección. Lo más habitual es que no sea el producto el que ha llegado al final de su vida útil, sino algo en su interior: un chip que ya no se fabrica. Una pantalla que ha dejado de producirse. Una certificación inalámbrica que ya no cumple con las nuevas normativas. Un sistema operativo que ya no recibe actualizaciones de seguridad. El fabricante no dice: "Ya no queremos fabricarlo". Dice: "Ya no podemos producirlo a un coste comercialmente viable". Así funciona la industria y, lo que es más importante, es predecible porque sigue una secuencia definida de etapas.
Todas esas etapas tienen nombres, y comprenderlas es el verdadero truco. Primero llega el anuncio de fin de vida útil (End-of-Life). Luego viene el período de Última Compra (Last Buy o Last Time Buy), durante el cual todavía se puede pedir el producto. A continuación, viene el envío final. Solo años después finaliza el servicio: el punto en el que ya no se ofrecen reparaciones y no se almacenan piezas de repuesto. A menudo transcurren cinco años o más entre el anuncio inicial de fin de vida y el fin del servicio. Esto no es una guillotina; es una despedida larga y ordenada. Si conoces las cuatro fechas, no tienes un problema de fin de vida útil. Pero si ignoras la primera, eventualmente las cuatro llegan a la vez.
El fin de vida útil se vuelve especialmente crítico donde convergen grandes volúmenes y la estandarización: durante las implementaciones. Un cliente final con 3.000 dispositivos idénticos en 400 tiendas no quiere que el dispositivo número 3.001 sea diferente. Su software ha sido validado para ese modelo específico. Sus soportes de montaje encajan en esa carcasa. Sus empleados conocen esos botones de memoria. Para ellos, un anuncio de fin de vida útil no es simplemente una actualización de catálogo; es un proyecto. O bien aseguran suficiente stock durante la ventana de Última Compra para mantener el ciclo de vida restante —unidades de reemplazo, expansión, stock de contingencia— o bien comienzan a migrar al producto sucesor con tiempo suficiente. Ambas son opciones sensatas. Solo la tercera opción es mala: no hacer nada y ser sorprendido.
Aquí es precisamente donde la distribución demuestra su valía, porque es donde estamos más cerca del origen. Recibimos las notificaciones de fin de vida útil primero. Conocemos las hojas de ruta de los productos. Sabemos qué sucesor es genuinamente compatible y cuál solo lleva un nombre similar. Un buen distribuidor se pone en contacto contigo antes de que exista el problema: "El dispositivo de su implementación se va a descontinuar. La ventana de Última Compra cierra en esta fecha, quedan estas unidades disponibles y esta es la ruta de migración recomendada". Consolidamos las cantidades de Última Compra entre varios revendedores, reservamos el stock restante para proyectos en curso y mantenemos inventario para el cliente que, inevitablemente, se da cuenta —después de la fecha de última venta— de que todavía necesita otras 50 unidades. No es un trabajo glamuroso, pero se vuelve invaluable el día que salva la implementación de un cliente final.
Así que aquí está mi consejo, sin complicarlo más de lo necesario: no trate las descontinuaciones de productos como una inconveniencia. Trátelas como una oportunidad de venta. Cada anuncio de fin de vida útil crea una razón natural para hablar con su cliente: sobre migración, productos sucesores, stock de contingencia o el próximo proyecto. Los revendedores que entienden esto se benefician dos veces de cada descontinuación: una vez de la compra final del producto saliente y otra vez de la primera compra de su sucesor. Todos los demás se quedan explicando a su cliente por qué el proyecto ya no puede continuar.
Así que recuerde esto: "Un producto muere dos veces: una en la lista de precios y otra en el campo. Si se pierde la primera muerte, te enfrentarás a la segunda completamente desprevenido".
Mecánica de distribución: A partir del 11 de septiembre, las cosas se ponen serias: la Ley de Resiliencia Cibernética también te afecta
En las últimas semanas, he escrito sobre el mercado gris y por qué esa ganga de un intermediario podría acabar siendo el dispositivo más caro que jamás compre....
En las últimas semanas, he escrito sobre el mercado gris y por qué esa ganga de un intermediario podría acabar siendo el dispositivo más caro que jamás compre. Hoy, llegamos al lado legal de la misma historia, y es considerablemente menos romántico que cualquier cosa que pudiera decir sobre las garantías. La Ley Europea de Ciberresiliencia ya está en vigor. El 11 de septiembre de 2026, entrará en vigor el primer requisito importante: la obligación de informar sobre vulnerabilidades explotadas activamente. A partir del 11 de diciembre de 2027, todos los productos nuevos con elementos digitales que se introduzcan en el mercado deberán cumplir los requisitos completos.
Sé exactamente cómo suena eso. Otra regulación, otro acrónimo, otra cosa para los fabricantes en lugar de para usted, directo a la carpeta donde el RGPD y la Ley de la Cadena de Suministro ya están acumulando polvo. Y ahí es precisamente donde reside el error de concepto. La regulación reconoce tres funciones: fabricante, importador y distribuidor, y las tres conllevan obligaciones. Como distribuidor, usted debe, entre otras cosas, comprobar cuidadosamente si un producto cumple los requisitos antes de ponerlo a disposición, y no debe venderlo si tiene motivos para creer que no cumple la normativa. Y cualquiera que introduzca mercancías en la UE desde terceros países fuera de los canales oficiales puede ser clasificado legalmente como importador mucho antes de lo que le gustaría, junto con las obligaciones considerablemente menos agradables que ello conlleva. De repente, esa compra ventajosa de hace unos días adquiere un significado completamente nuevo.
Lo bueno de esta regulación es que finalmente obliga a hacerse una pregunta que siempre fue la correcta de hacer: ¿recibirá este dispositivo actualizaciones de seguridad y durante cuánto tiempo? En el futuro, los fabricantes tendrán que especificar un período de soporte y abordar las vulnerabilidades durante ese tiempo. Esto convierte algo que antes era una cuestión de confianza en algo que realmente se puede verificar, y finalmente le da algo tangible en una conversación de ventas que no se puede discutir fácilmente.
Porque es precisamente aquí donde los productos de calidad profesional se diferencian de los que simplemente parecen baratos. Tome un dispositivo que su cliente pretende utilizar durante cinco años. Opción A: 900 €, con un período de soporte declarado que cubre toda la vida útil prevista. Opción B: 640 €, procedencia desconocida, y cuando pregunta por las actualizaciones, todo el mundo en la cadena de suministro se encoge de hombros. Su cliente ahorra 260 € por dispositivo y está encantado. Pero si el dispositivo tiene que ser reemplazado después de tres años porque ya no se le permite operar en su red, ha amortizado efectivamente 640 € y tiene que volver a pagar todo. En 200 dispositivos: 52.000 € ahorrados, 128.000 € perdidos. Nadie quiere enfrentarse a su propia reunión de dirección con esas cifras.
Hay un segundo nivel en esto que pronto importará más a sus clientes de tamaño mediano que cualquier descuento: las empresas que están sujetas a requisitos de seguridad más estrictos tienen que documentar su cadena de suministro. El comprador que hoy solo le pregunta por el precio, pronto le preguntará por las declaraciones de conformidad, los períodos de soporte y la procedencia del producto. Si tiene respuestas claras preparadas, vende. Si su respuesta es: "tendré que comprobarlo", acaba de enterrar su propia oferta, y ya he escrito extensamente en esta serie sobre lo que pienso de frases como esa.
Y ahora, la parte incómoda, afortunadamente es corta. Consiga la documentación de conformidad y los períodos de soporte declarados para sus productos más importantes y archívelos correctamente; se los pedirán, puede estar seguro. Compre de fuentes que realmente puedan proporcionar esta documentación y evite los productos cuyo origen nadie parece dispuesto a explicar. Y haga que el período de soporte sea una línea estándar en cada presupuesto, justo al lado del plazo de entrega y la garantía. No le cuesta nada y cambia la conversación de precio.
Normalmente no soy partidario de utilizar las regulaciones como argumento de venta, me parece demasiado como vender con el dedo acusador, y todos hemos tenido suficiente de eso en los últimos años. Pero esta regulación en particular aclara algo que ha estado molestando a nuestro mercado durante mucho tiempo: comparar precios de cosas que simplemente no son comparables. Hasta ahora, un dispositivo con soporte garantizado y procedencia documentada y uno sin ellos podían coexistir pacíficamente en la misma columna de Excel como si fueran gemelos. Eso pronto será cosa del pasado. Y lo admito libremente: estoy deseando que llegue.
Así que recuerde: "Un dispositivo sin soporte de seguridad garantizado no es un dispositivo más barato. Es un dispositivo con fecha de caducidad de la que nadie le informó."
Mecánica de distribución: la queja que nunca existió
Hay una cifra en nuestro negocio de la que a nadie le gusta hablar porque es vergonzosa para todos los implicados: una proporción significativa de dispositivos...
Hay una cifra en nuestro negocio de la que a nadie le gusta hablar porque es vergonzosa para todos los implicados: una proporción significativa de dispositivos devueltos como defectuosos están en perfecto estado. Ni avería, ni componente defectuoso, nada. Configurados incorrectamente, emparejados incorrectamente, la fuente de alimentación equivocada, ninguna introducción adecuada, o simplemente un usuario que esperaba algo para lo que el dispositivo nunca fue diseñado. La industria ha ideado una abreviatura maravillosamente indulgente para esto: »NFF – no fault found« (sin avería encontrada). Cualquiera que dirija un centro de servicio conoce su porcentaje con bastante precisión. Simplemente no lo dicen en voz alta.
El instinto de culpar al usuario es comprensible, pero sigue siendo erróneo. Porque el usuario no es quien paga el proceso. Usted lo es. Haga los cálculos: envío de salida y de vuelta juntos, 30 €. Pruebas, incluso si finalmente no se encuentra nada, un estimado de 45 €. Su propio tiempo dedicado a recibir la devolución, registrarla, hacer preguntas y hacer seguimiento a las personas – llamémosle generosamente una hora a 75 €. Y luego está la semana durante la cual una de las estaciones de trabajo de su cliente está inactiva. Incluso si ignoramos generosamente este último punto, ya son 150 €. Veinte casos así al año suman 3.000 €. Nunca los verá en ningún informe porque se distribuyen perfectamente a lo largo de doce meses, como todas las cosas realmente caras.
Y ahora la parte incómoda: la mayoría de estos casos podrían haberse resuelto con una llamada telefónica de veinte minutos. Ningún curso de formación, ningún proceso, ningún contrato de servicio, ningún proyecto con un comité directivo. Solo una llamada en la que alguien pregunta: »¿Qué sucede exactamente cuando pulsas el botón?« En la mayoría de los casos, eso es suficiente para solucionarlo. Por eso no veo el soporte como un centro de costes, sino como la palanca más eficaz para reducir su tasa de devoluciones. Y, pura coincidencia, también es la más barata.
Hay un segundo punto que casi siempre se subestima: una devolución también es una cuestión de confianza. Su cliente compró algo, no funcionó, lo devolvió, y tres semanas después el dispositivo regresa con una nota que dice que todo está perfectamente bien. Desde su perspectiva, esa nota dice: »Fue culpa tuya y nadie te ayudó.« Puede tener toda la razón en los hechos y aun así perder al cliente. Cuando llegue el próximo despliegue, no recordarán su buen precio; recordarán esas tres semanas. Tener razón y hacer negocios son dos disciplinas diferentes en nuestra industria, y puede ser un campeón en una y descender en la otra.
Lo que realmente ayuda: primero, una evaluación inicial con cuatro preguntas que son siempre las mismas. ¿Desde cuándo? ¿Afecta a todos los dispositivos o solo a uno? ¿Qué cambió recientemente: firmware, red, ubicación, accesorios? Y: ¿funciona un dispositivo idéntico en otra estación de trabajo? Esas cuatro preguntas eliminan la mitad de los casos antes de que alguien toque una caja de cartón. Segundo: siempre que sea posible, proporcione un dispositivo de reemplazo in situ en lugar de enviar el defectuoso. Tercero, y esta es la parte que requiere un poco de coraje, revise sus propios casos una vez al trimestre y cuente cuántos fueron »sin avería encontrada«. El número sorprende a todo el mundo. A mí también me sorprendió, en su momento.
Aquí también señalo explícitamente en nuestra propia dirección. Un distribuidor que simplemente procesa devoluciones en lugar de intentar ayudar primero se lo está poniendo demasiado fácil. Para el distribuidor, el caso está ordenadamente cerrado; para usted, es un cliente que ahora piensa mal de usted. Así que la pregunta que debe hacer a su proveedor no es »¿Qué tan rápido procesa una RMA?«. Es: »¿Qué hace para asegurarse de que no la necesite en primer lugar?« Las respuestas pueden ser notablemente reveladoras. También lo pueden ser algunas de las caras.
Hay una razón por la que entro en tanto detalle aquí. Un dispositivo que se envía y se devuelve sin avería encontrada no genera ingresos, ni margen, ni satisfacción. Es el único proceso en toda nuestra cadena en el que todos los implicados pierden, y el único que podría haberse evitado con una llamada telefónica.
Así que recuerde: »La queja más cara es aquella en la que resulta que no había nada roto en primer lugar.«
Opinión: por qué ya no envío listas de precios en PDF
Ya he dicho lo que opino sobre PowerPoint en esta serie, y la respuesta fue tan abrumadoramente positiva que pensé en seguir mientras tuviera el viento a favor....
Ya he dicho lo que opino sobre PowerPoint en esta serie, y la respuesta fue tan abrumadoramente positiva que pensé en seguir mientras tuviera el viento a favor. Porque hay un segundo documento que circula en nuestra industria con exactamente la misma regularidad incuestionable: la lista de precios en PDF. Cuarenta páginas, actualizadas hasta algún momento de la semana pasada, enviadas por correo electrónico una vez, y eternas a partir de entonces. Estoy convencido de que todavía circulan listas de precios de Jarltech con productos que ya no existen desde hace años. Guardadas en algún disco duro, en una carpeta llamada "importante".
El problema no es el formato. Es la vida útil. Desde el momento en que se crea un documento así, está, en el mejor de los casos, aproximadamente correcto. Los tipos de cambio fluctúan, los fabricantes anuncian ajustes de precios, las promociones terminan, los productos se descatalogan. Cuatro semanas después, ya no es un documento de trabajo; es una fuente histórica. Y esa es la parte peligrosa: en el día cien, parece tan oficial como lo era en el día uno. Al menos un cartón de leche te dice cuándo se ha estropeado. Un PDF simplemente está ahí, callado amablemente mientras cometes errores en tus cálculos.
Permítanme ponerle una cifra a lo que eso puede costarles. Usted calcula el precio de un proyecto de 150 unidades basándose en una lista que tiene dos rondas de precios desactualizadas. El precio de compra ha subido un 4 por ciento desde entonces, mientras que su precio de venta ya está en la cotización y se lo ha enviado al cliente. A un precio unitario de 480 €, eso son poco más de 19 € por unidad, o casi 2.900 € en total, de su margen, no del cliente. Eso es más de lo que la mayoría de las empresas habrán cedido como descuento en la misma licitación. Al menos obtuvieron un resultado negociado a cambio. Usted obtuvo una carpeta vieja.
La segunda razón es aún más incómoda: un PDF no sabe nada sobre la disponibilidad. Te dice cuánto cuesta un dispositivo, pero no si realmente existe. Y seamos sinceros: en los últimos años, la pregunta crucial en los proyectos raramente ha sido "¿Cuánto cuesta?" y casi siempre "¿Cuándo puedo conseguirlo?". Si usted está con un cliente y puede decirle inmediatamente cuántas unidades hay en stock hoy y cuántas más llegan en tres semanas, tiene una ventaja sobre la persona que dice: "Lo comprobaré y le responderé mañana". Ya he hablado de esa frase en otro lugar de este blog. Hay formas realmente elegantes de enredarse en nuestro negocio.
La alternativa no es glamurosa, que es precisamente por lo que casi nadie habla de ella: se obtienen precios y niveles de stock de donde se originan, en tiempo real. A través del inicio de sesión de su tienda, a través de una interfaz conectada a su sistema ERP, o a través de un feed que su sistema descarga automáticamente durante la noche mientras usted duerme. Esto no es una fantasía de digitalización ideada para la presentación de un consultor. Las empresas que lideran el negocio de proyectos lo hacen desde hace años. La implementación lleva unos días y un solo pedido como el anterior la amortiza. Después de eso, nunca más tendrá que preguntarse si la lista de precios que tiene en su carpeta sigue siendo correcta.
Y ahora, la parte incómoda, porque no quiero ser un hipócrita: nosotros mismos seguimos enviando listas de precios. Los clientes las piden, y no voy a obligar a nadie a cambiar su forma de trabajar. Pero hoy en día aclaro lo que contienen: una instantánea, válida hoy, no para el resto del trimestre. Si la utiliza para calcular un proyecto que no se pedirá hasta dentro de seis semanas, asume un riesgo que nadie le quitará de encima después. Si en su lugar utiliza datos en tiempo real, nunca tendrá que tener la conversación sobre la renegociación en primer lugar. Y seamos sinceros, a nadie le gusta tener esa conversación dos veces.
Y ya que estoy confesándome aquí: genuinamente me entusiasma una interfaz limpia. De verdad. Muéstrenme precios, niveles de stock y estados de pedidos fluyendo entre dos sistemas sin que nadie tenga que tocarlos, y creo que es algo hermoso. Probablemente no sea la pasión más emocionante que una persona pueda tener, pero he visto cosas peores. La razón detrás de ello es, sin embargo, completamente práctica: se trata del tiempo de respuesta. La diferencia entre enviar una cotización en veinte minutos y enviarla a la mañana siguiente decide quién gana el pedido con más frecuencia que una diferencia de precio del 5 por ciento, porque una vez que el cliente ha encontrado el primer proveedor que puede entregar, la decisión a menudo ya está tomada en su cabeza. Todo lo que viene después son solo cotizaciones de comparación. Y las cotizaciones de comparación se escriben en su mayoría para dar algo que hacer al sistema de archivo.
Así que, para terminar con una autopromoción descarada: en Jarltech, tenemos un equipo de API que pasa todo el día haciendo exactamente esto: llevar precios, disponibilidad, datos de productos y estados de pedidos directamente a su sistema, ya sea una plataforma ERP, una tienda online o su propia herramienta de costes. Llámenles. La conversación no le cuesta nada, dura media hora, y al final sabrá si tiene sentido financiero para usted. Si después de eso todavía quiere trabajar con PDFs, está perfectamente bien, pero al menos será una decisión consciente, en lugar de simplemente porque nadie le ha sugerido nunca una alternativa.
Así que recuerde: "Un PDF te dice lo que costó un dispositivo la semana pasada. Tu cliente quiere saber lo que cuesta hoy, y cuándo puede conseguirlo."
Desde 1988 desarrollamos nuestro propio software.
Hace unas semanas, un revendedor especializado me preguntó si podíamos imprimir notas de entrega para sus clientes finales con su logotipo, sus datos de remitente y...
Hace unas semanas, un revendedor especializado me preguntó si podíamos imprimir notas de entrega para sus clientes finales con su logotipo, sus datos de remitente y su sistema de numeración. Lo preguntó con el tono de disculpa que uno adopta cuando está acostumbrado a recibir un "no" a este tipo de preguntas. En un distribuidor que utiliza software estándar, la respuesta habría sido, de hecho, no, o más precisamente: se habría abierto una incidencia con el proveedor del software, habría ocupado un lugar en el calendario de versiones y la implementación se habría fijado para algún momento del año que viene. Nuestra respuesta fue: a partir del lunes.
La razón se remonta a treinta y ocho años y, en aquel momento, no fue una estrategia sino una necesidad. Cuando empezamos en 1988, simplemente no había software adecuado disponible para comprar para lo que hacíamos. Podríamos haber comprado algo y adaptado nuestros procesos para que encajaran. Hicimos lo contrario y adaptamos el software a nuestros procesos. Mirando atrás, fue la decisión más trascendental que jamás tomó esta empresa, y quiero ser sincero: en aquel momento, no tenía ni idea de lo importante que resultaría ser.
Porque un sistema ERP estándar hace algo muy específico para un negocio. Obliga a tus propios procesos a encajar en una estructura que alguien más ha diseñado para la media de todos sus clientes. Cada excepción se convierte en una solución provisional, cada solución provisional termina en una hoja de cálculo de Excel aparte, y al final la mitad de la empresa está trabajando en torno a su propio software. Por cierto, se detecta bastante fácilmente desde fuera: cada vez que haces una pregunta que debería ser sencilla y la respuesta es que lamentablemente no se puede hacer porque el sistema no lo permite. Ningún sistema se niega a permitir algo. Nadie ha escrito el código para ello, eso es todo.
La segunda parte llegó en 1995, aunque nadie lo llamaba todavía la nube. Teníamos clientes que se conectaban a nuestro sistema para ver lo que teníamos en stock, en un momento en que la forma habitual de obtener esa información era que alguien te devolviera la llamada después de haber comprobado el almacén. El beneficio era el mismo entonces que hoy: no preguntas, lo ves por ti mismo. Nada de esto es espectacular. Es simplemente la diferencia entre trabajar y esperar.
La mejor manera de entender por qué esto importa es cambiar de perspectiva por un momento y preguntar a un fabricante qué necesita realmente de un distribuidor. La respuesta rara vez es "ingresos". Lo que quieren es saber dónde terminan sus dispositivos, de forma rápida y en su formato, no en el nuestro. Quieren que un proyecto registrado esté genuinamente protegido en lugar de ser anulado tres semanas después por un precio de lista. Quieren que un cambio de precio realizado de la noche a la mañana se refleje en todas las listas de precios de los clientes en lugar de terminar en renegociaciones. Si hay un problema de firmware, quieren saber qué números de serie están afectados, no que les digan que lamentablemente solo rastrean los productos a nivel de artículo. Y quieren que un nuevo producto esté disponible para pedir el día que se anuncia, completo con todas sus especificaciones técnicas, en lugar de cuatro semanas después, cuando alguien en algún lugar finalmente ha actualizado los datos maestros.
En un sistema estándar, cada uno de esos requisitos es o bien un módulo adicional costoso o bien un proceso que dos personas tienen que manejar manualmente. Para nosotros, es una pregunta para nuestros propios desarrolladores. Por eso los fabricantes confían en nosotros para cosas que de otro modo harían ellos mismos: preconfigurar gamas completas de dispositivos, crear paquetes específicos para el cliente y aprovisionar según un plan de implementación en lugar de por orden de llegada de los pedidos. Estos no son procesos estándar, que es precisamente la razón por la que el software estándar no puede acomodarlos.
Para usted como revendedor, el mismo mecanismo funciona simplemente desde la otra dirección. Sus números de producto en lugar de los nuestros en el pedido. Su lista de precios, que su colega también ve cuando llama un viernes. Sus acuerdos marco con pedidos de provisión repartidos en varios meses. Un flujo en directo de niveles de stock y precios a su propia tienda web en lugar de un archivo CSV que llega por correo electrónico por la mañana y ya está desactualizado al mediodía. Números de serie en la nota de entrega para que pueda proporcionar a su cliente final documentación para sus dispositivos sin tener que copiarla manualmente. Y, por supuesto, una nota de entrega con su logotipo cuando enviamos directamente a su cliente final.
Calcule el valor en tan solo uno de esos puntos. Un revendedor que introduce manualmente doscientos pedidos al mes en lugar de procesarlos a través de una interfaz, dedica, con cuatro minutos por pedido, más de trece horas al mes a escribir, más de ciento cincuenta horas al año en las que nadie está vendiendo; alguien está simplemente volviendo a introducir información que ya era digital en primer lugar. Y un operador de tienda web cuyos datos de stock están desactualizados medio día venderá de forma fiable algo varias veces al mes que ya no está disponible. Cada una de esas cancelaciones les cuesta no solo el margen del pedido, sino el cliente.
El verdadero quid de la cuestión, sin embargo, es que ambas partes están hablando del mismo sistema. La información que el fabricante necesita y los datos que usted quiere extraer son simplemente dos extremos del mismo proceso. Si compra un sistema y le añade otro a un lado, terminará con dos sistemas y una hoja de cálculo de Excel que los conecta, y esa hoja de cálculo tendrá que ser mantenida por alguien que debería estar, en realidad, hablando con usted.
Ahora, la parte incómoda, porque este enfoque no es gratuito. Si construye su propio software, usted asume los costes de desarrollo solo; con un producto estándar, esos costes se comparten entre mil clientes. Pagamos cada línea de código nosotros mismos, y también pagamos cada error nosotros mismos. Porque introducimos errores que no existirían en software comprado, y cuando eso sucede, no hay ningún proveedor al que podamos señalar con el dedo. Eso es incómodo, pero es el acuerdo más honesto: las personas que cometieron el error son también las que lo arreglan.
En última instancia, es el mismo principio sobre el que escribí recientemente. Si una decisión aquí lleva un día o un trimestre no depende de lo listo que sea alguien, sino de cuántas puertas hay entre su pregunta y la decisión. En lo que respecta al software, hay exactamente una. Por eso nuestra respuesta a un requisito inusual casi nunca es "eso no se puede hacer", sino "¿cuándo lo necesita?".
Recuerde: "Ningún sistema se niega a permitir algo. Nadie ha escrito el código para ello; la única pregunta es si la persona que puede está en el mismo edificio."