¿Cuándo debe su empresa desarrollar su propio software?

Todas las empresas necesitan y utilizan software, y algunas son un importante impulsor del éxito comercial. Pero a medida que las pequeñas empresas crecen hasta convertirse en medianas, pueden surgir brechas en el rendimiento del software. Encontrar nuevas soluciones de software puede solucionar problemas e ineficiencias y ayudar a los equipos a desarrollar productos y servicios innovadores. Pero los directores ejecutivos de las medianas empresas a menudo se enfrentan a una elección difícil: si actualizar a través de un proveedor o desarrollar (también conocido como "rollo") su propio código.

Se entiende ampliamente que las actualizaciones de software siempre son costosas y, a menudo, perturbadoras. A veces fallan por completo o no cumplen su promesa original. Eso significa poco o ningún retorno del dinero gastado. Pero a veces, simplemente no hay ningún software comercial disponible para abordar el problema único de una empresa.

Para las pequeñas empresas, por lo general es más fácil (y casi siempre más barato) hacer soluciones manuales cuando su software operativo no está a la altura. Pero las medianas empresas pueden perder una gran cantidad de dinero y frenar su crecimiento debido a las ineficiencias que surgen inevitablemente de tales soluciones alternativas. Y esos procesos manuales torturados pueden impedir que las empresas aprovechen las oportunidades de manera oportuna. Para esas empresas, la codificación personalizada es una opción viable. (Las grandes empresas con mucho dinero pueden crear equipos de desarrollo de software y, a menudo, cuentan con el talento necesario para hacerlo).

La mayoría de las empresas medianas tienen un "superusuario" que es bueno para ayudar a todos con las capacidades ya integradas en su software (como redactores de informes, tableros, etc.). Y la mayoría del software de planificación de recursos empresariales (ERP) moderno tiene capas que permiten la personalización, a menudo una capa en la que los revendedores de valor agregado (VAR) pueden realizar cambios y una capa de clientes para las personalizaciones de los clientes. Si una empresa mediana puede obtener lo que necesita de eso, fantástico. Pero, ¿y si no se puede?

Muchas empresas medianas se atascan tratando de decidir si comprar software nuevo o intentar escribir su propio código, incluso si eso solo significa conectar sistemas dispares. Otros intentan externalizar el problema a una empresa de software. Si bien la subcontratación de la creación de código puede ser parte de una solución, hacerlo con éxito requiere una gestión de proyectos rigurosa, una capacidad que no todas las medianas empresas tienen.

Mientras tanto, el reloj siempre corre. Las eficiencias que podrían lograrse con el software no se recuperan, lo que reduce los márgenes. Se pierden oportunidades de mercado frente a los competidores. ¿Cómo pueden los líderes de medianas empresas determinar cuándo tiene sentido crear su propio software?

Cuándo lanzar su propio código

Es ineficiente desarrollar programas personalizados para las funciones comerciales principales, como contabilidad, nómina, impuestos sobre las ventas, inventario y administración de relaciones con los clientes (CRM), y hay muchas opciones disponibles. Pero si no hay un software que haga lo que usted necesita que haga, es posible que no tenga más remedio que implementar el suyo propio, especialmente si hay una oportunidad de alto valor que aprovechar o una eficiencia significativa que ganar. (Crear su propio código solo vale la pena si hay una gran recompensa; sin un ROI fuerte, olvídese de eso).

Por ejemplo, en 2007, BF&S Manufacturing estaba cobrando fuerza como fabricante por contrato de componentes complejos y de bajo volumen, pero críticos, para verticales aeroespaciales, militares, médicos e industriales. Sus clientes querían supervisar el trabajo, pero BF&S tenía su sede en México y muchos de sus clientes no querían invertir el tiempo y el dinero para viajar y quedarse allí.

BF&S dependía de una estrecha relación con sus clientes, a menudo recurriendo a sus ingenieros para resolver problemas de producción. Pero la distancia y una frontera lo hacían cada vez más difícil. La pantalla compartida y las cámaras por sí solas no iban a ser suficientes para sus clientes, y BF&S temía perderlas frente a fabricantes más cercanos, incluso si esas empresas cobraban más. BF&S necesitaba poder transferir valiosos datos de producción de su sistema ERP central a un formato que sus clientes pudieran usar.

El director ejecutivo de BF&S, Carlos Fernández, miró a su alrededor pero no pudo encontrar una solución para comprar. En lugar de eso, dice: “Nos embarcamos en un programa de software que proporcionaría datos en tiempo real las 24 horas del día, los 7 días de la semana” sobre las construcciones de productos de la compañía. Comenzó con su "chico de la computadora", como lo llama Fernández, recién egresado de la universidad, construyendo una herramienta para rastrear las materias primas, el trabajo en proceso y los inventarios de productos terminados y brindar visibilidad interna y externa.

Se completó y se usó por primera vez en 2010. A los clientes les encantó. Fernández comenzó a hacer crecer el equipo de desarrollo de software en México, apoyando cuatro instalaciones en el estado de Sonora con una plantilla combinada de 500. Los clientes ahora podían ver videos de las estaciones de trabajo, el progreso de sus productos en cada paso, los inventarios de productos crudos y terminados de BF&S, quién estaba trabajando en su trabajo, y todas las historias y especificaciones del producto.

Esta codificación personalizada requería un profundo conocimiento tanto del negocio de la empresa como de las necesidades de sus clientes. Originalmente encabezado por Fernández, el equipo de ingenieros y líderes de operaciones ahora planifica y administra el soporte y el desarrollo continuos de la herramienta.

Hoy, aunque Fernández no afirma que el código construido en casa de su empresa es un gran diferenciador competitivo, cree que les da a sus clientes lo que quieren y lo que él no pudo proporcionar a través del software comercial: transparencia y una medida de control sobre la producción de sus productos.

El viaje y los costos

Desarrollar su propio código no es simple ni barato. Los ingenieros de software están muy bien pagados. En los Estados Unidos, eso significa salarios de seis cifras. Los costos de encontrar y contratar ingenieros a menudo involucran firmas de búsqueda, que cobran entre 15% y 30% del salario del primer año, y durante los últimos años, incluso ellas han tenido dificultades para encontrar buenos candidatos. Además de los costos de abastecimiento, debe entrevistar y evaluar a los candidatos en cuanto a habilidades técnicas, capacitar e incorporar nuevos empleados y proporcionar un entorno digital para el desarrollo y las pruebas.

Y luego debe administrar las tareas de desarrollo de código, asegurándose de que sean productivas. A medida que el departamento de desarrollo supera los cinco o seis ingenieros, necesitará un ejecutivo de DevOps para supervisarlo; si los programadores no están bien administrados, se pueden perder días y semanas mientras la productividad cae en picado.

Y no puede simplemente contratar desarrolladores y gerentes y esperar que suceda la magia. Los ingenieros hacen lo que el negocio les dice que hagan. Ellos prosperan en la claridad. Por lo tanto, necesitará dedicar tiempo a comprender las oportunidades y necesidades de su negocio para poder describir las características, funciones y opciones que desea. Esa hoja de ruta del software debe completarse antes de que sus ingenieros comiencen a codificar. Si no hace todo esto bien y a tiempo, tendrá un talento muy costoso sentado en sus manos, probablemente buscando otros lugares para trabajar.

Finalmente, cuando desarrolla código personalizado, necesita mantenerlo. El software se descompone todo el tiempo. Los piratas informáticos encuentran continuamente nuevos vectores de ataque. Aparecen nuevas necesidades y los usuarios exigen modificaciones. Incluso los lenguajes de programación envejecen, por lo que cada cinco a 10 años, es posible que sea necesario reescribir el software. Los costos siguen llegando.

Sin embargo, si bien la codificación personalizada es un desafío, puede ser un factor fundamental y bien vale la pena para algunas empresas que están innovando soluciones para sus clientes.

Corefact (un cliente de Mastering Midsized) es un proveedor de servicios de marketing de servicio completo para las industrias de bienes raíces e hipotecas. En 2005, a la empresa se le ocurrió una nueva idea. Si un agente inmobiliario pudiera enviar una postal a un cliente potencial con una URL única que llevaría al cliente a un sitio web con su propia casa en el centro, eso podría ser muy atractivo y un posible cambio de juego. Los clientes de Corefact, los agentes inmobiliarios, estaban entusiasmados, no solo por el atractivo potencial para sus clientes, sino también por todos los datos que este tipo de compromiso les proporcionaría.

Corefact couldn’t buy software to do this — it was new. Corefact’s founder and CEO Chris Burnley had always been a technologist. Prior to Corefact, he started several technology-driven companies. Thanks to this technological competency, the company found a way to print variable data — unique URLs — on postcards and then move them on to web servers that would wait for a homeowner to type in the URL, after which a new, unique website would be created instantly. By 2006, the software was launched with a single engineer.

Hoy, el equipo de ingeniería ha crecido a 10, ubicados en los EE. UU. y en el extranjero. Han creado un código personalizado que no solo está orientado al cliente, sino que también reúne de manera eficiente miles de pedidos diarios a través de la entrada de pedidos, gráficos y preimpresión, y automatiza el flujo eficiente de trabajo en las prensas y el acabado.

Burnley dice: “Nuestro concepto original nos puso en una rampa rápida de crecimiento, pero nuestra capacidad de innovar con la tecnología continúa impulsándonos. Por supuesto, la inversión en ingenieros es enorme y continua, pero la lista de oportunidades es larga”.

Pero no construyen cada pieza de software que usan. Cuando llegó el momento de actualizar su ERP, eligieron un producto estándar de Netsuite, al que están conectando sus sistemas de manejo de pedidos hechos por ellos mismos. De manera similar, recientemente abandonaron un CRM hecho a sí mismo a favor de Salesforce, manteniendo a su equipo de desarrollo enfocado en crear software que no pueden comprar.

Las tres competencias que necesita para rodar por su cuenta

Los ejemplos que he discutido requieren diferentes cantidades de las siguientes tres competencias, dependiendo de cuán complejos sean los requisitos de su código personalizado:

Traducir las necesidades del negocio en proyectos de software.

La identificación de las necesidades comerciales, y sus soluciones, es un proceso necesariamente iterativo, teniendo en cuenta las limitaciones del software existente, así como sus recursos y datos disponibles. Esto no es ni desarrollo de software ni gestión empresarial; es una forma de ingeniería donde una pierna se encuentra en el negocio y la otra en una comprensión profunda de cómo funcionan sus sistemas de software actuales.

Esta competencia podría estar a cargo de un ejecutivo en una empresa mediana más pequeña, o de un pequeño equipo a medida que crece la organización. Lo que entra es un problema o una oportunidad, lo que sale es una serie de pasos detallados para crear y mantener el código: exactamente qué datos se van a usar y qué lógica o procesos se deben usar para producir una solución. Sin todos estos pasos, intentar crear un código personalizado no tiene sentido.

Desarrollo de código.

Dependiendo de las circunstancias, una empresa mediana podría tener un programador o un departamento de ingeniería completo. Por ejemplo, en mi empresa anterior, Dave, un joven empleado de almacén que programaba como pasatiempo, subía de vez en cuando para pequeños proyectos de programación. Para mayores oportunidades, el desarrollo de código puede convertirse en una serie de equipos de ingeniería con diferentes habilidades y enfoques que trabajan en un departamento completo de DevOps, dirigido por un vicepresidente o director de tecnología.

Operaciones de software.

El lado operativo de la administración de aplicaciones personalizadas es costoso: debe mantener la salud del código personalizado y asegurarse de que sus procesos, personas y herramientas estén actualizados. Los elementos de las operaciones incluyen asistencia al usuario/servicios de ayuda, capacitación, gestión de riesgos de seguridad, corrección de errores, personalización adicional continua, tiempo de actividad y atributos de rendimiento, y más.

Aprovechar el software propio para llevar la innovación a su mercado o para crear operaciones más eficientes puede ser un fuerte motor de crecimiento. Pero la decisión de comprar o construir es crítica. Si no es posible comprar el software que necesita, crearlo puede tener sentido. Pero no se puede negar que es un camino difícil, y solo vale la pena si la ventaja es grande. Antes de construir, asegúrese de comprender los costos reales para tener éxito a largo plazo, y solo emprenda aquellos esfuerzos de escritura de códigos de los que está seguro que su empresa es capaz.