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

Orientación para las compañías medianas que hacen la decisión de “comprar-it vs. construirla”.
Quando sua empresa deve desenvolver seu próprio software?
Quando sua empresa deve desenvolver seu próprio software?
Resumen.

Aprovechar el software local para llevar la innovación a su mercado o crear operaciones más eficientes puede ser un fuerte impulsor del crecimiento. Pero la decisión de comprarlo frente a construirlo es fundamental. Si comprar el software que necesita simplemente no es posible, compilarlo puede tener sentido. Pero no se puede negar que es un camino difícil, y solo vale la pena si el lado positivo es grande. Antes de crear, asegúrese de entender los costos reales para tener éxito a largo plazo y solo emprenda esos esfuerzos de redacción de códigos que está seguro de que su empresa es capaz. El autor analiza dos empresas medianas que «implementaron su propio código» con éxito y presenta tres competencias requeridas para hacerlo.


Todas las empresas necesitan y utilizan software, y algunas son un importante impulsor del éxito empresarial. Pero a medida que las pequeñas empresas se conviertan 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 CEOs de medianas empresas a menudo se enfrentan a una difícil elección: actualizar a través de un proveedor o desarrollar (también conocido como «rodar») su propio código.

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

Para las pequeñas empresas, normalmente es más fácil (y casi siempre más barato) realizar soluciones manuales cuando su software operativo no está a la altura de la tarea. Pero las medianas empresas pueden perder una gran cantidad de dinero y frenar su crecimiento debido a las ineficiencias que inevitablemente surgen 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 grandes bolsillos pueden crear equipos de desarrollo de software y, a menudo, tienen el talento para hacerlo).

La mayoría de las empresas medianas tienen un «superusuario» que es bueno para ayudar a todos con las capacidades ya incorporadas en su software (como redactores de informes, paneles de control, 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 qué pasa si no puede?

Muchas empresas medianas se quedan atascados tratando de decidir si compran un nuevo software o intentan escribir su propio código, aunque eso solo signifique conectar sistemas dispares. Otros intentan subcontratar el problema a una empresa de software. Si bien la creación de código externalizado puede formar parte de una solución, hacerlo con éxito requiere una gestión de proyectos rigurosa, una capacidad que no tienen todas las medianas empresas.

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

Cuándo lanzar tu propio código

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

Por ejemplo, en 2007, Fabricación de BF&S estaba ganando fuerza como fabricante por contrato para componentes complejos, de bajo volumen, pero críticos, para las verticales aeroespaciales, militares, médicas 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 tiempo y dinero para viajar y quedarse allí.

BF&S dependía de una estrecha relación con sus clientes, y a menudo recurrían a sus ingenieros para resolver los problemas de producción. Pero la distancia y la frontera lo hacían aún más difícil. El uso compartido de pantalla y las cámaras por sí solas no iban a ser suficientes para sus clientes, y BF&S temía perderlas ante fabricantes más cercanos, incluso si esas empresas cobraban más. BF&S necesitaba poder portar datos de producción valiosos desde su sistema ERP principal a un formato que sus clientes pudieran usar.

El CEO de BF&S, Carlos Fernandez, miró a su alrededor pero no pudo encontrar una solución para comprar. En cambio, 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 compilaciones de productos de la compañía. Comenzó con su «chico de la computadora», como lo llama Fernández, recién salido de la universidad, construyendo una herramienta para rastrear las materias primas, el trabajo en progreso y los inventarios de productos terminados y proporcionar visibilidad interna y externamente.

Se completó y se utilizó 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 personas. 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 de los productos.

Esta codificación personalizada requería una comprensión profunda tanto del negocio de la empresa como de las necesidades de sus clientes. Originalmente dirigido por Fernández, el equipo de ingenieros y líderes de operaciones ahora planifica y administra el soporte continuo y el desarrollo de la herramienta.

Hoy, aunque Fernández no va a afirmar que el código construido en casa de su empresa sea un gran diferenciador competitivo, cree que da a sus clientes lo que quieren y lo que no podría proporcionar a través de un software estándar: transparencia y una medida de control sobre la producción de sus productos.

El viaje y los costos

Enrollar tu propio código no es sencillo ni barato. Los ingenieros de software reciben una remunerada En los Estados Unidos, eso significa salarios de seis cifras. Los costos de encontrar y contratar ingenieros a menudo implican empresas de búsqueda, que cobran del 15 al 30% del salario del primer año, y durante los últimos años, incluso han tenido dificultades para encontrar buenos candidatos. Además de los costos de abastecimiento, debe entrevistar y evaluar a los candidatos para obtener habilidades técnicas, capacitar e integrar a los nuevos empleados y proporcionar un entorno digital para el desarrollo y las pruebas.

Y luego tienes que gestionar las tareas de desarrollo de código para asegurarte de que sean productivas. Como el departamento de desarrollo supera a cinco o seis ingenieros, necesitará un ejecutivo de DevOps que lo supervise; si los programadores no reciben una administración insuficiente, se pueden perder días y semanas mientras la productividad se desploma.

Y no puedes simplemente contratar desarrolladores y gerentes y esperar que suceda la magia. Los ingenieros hacen lo que la empresa les dice que hagan. Se nutre de la claridad. Por lo tanto, tendrá que dedicar tiempo a conocer las oportunidades y necesidades de su negocio para poder describir las características, las funciones y las opciones que desea. Esa hoja de ruta de software debe completarse antes de que los ingenieros comiencen a codificar. Si no haces todo esto bien y a tiempo, y tendrás un talento muy caro en sus manos, probablemente buscando otros lugares para trabajar.

Por último, cuando desarrollas código personalizado, necesitas mantenerlo. El software se descompone todo el tiempo. Los hackers 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 crucial y 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 inmobiliaria e hipotecaria. En 2005, la empresa tuvo una nueva idea. Si un agente inmobiliario pudiera enviar una postal a un cliente potencial con una URL única que lo llevara 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 potencial atractivo para sus clientes, sino también por todos los datos que les proporcionaría este tipo de compromiso.

Corefact no podía comprar software para hacer esto, era nuevo. El fundador y CEO de Corefact, Chris Burnley, siempre había sido tecnólogo. Antes de trabajar en Corefact, fundó varias empresas impulsadas por la tecnología. Gracias a esta competencia tecnológica, la empresa encontró una manera de imprimir datos variables (URL únicas) en tarjetas postales y luego pasarlos a servidores web que esperaban a que un propietario escribiera la URL, después de lo cual se crearía un nuevo sitio web único al instante. En 2006, el software se lanzó con un solo ingeniero.

Hoy en día, el equipo de ingeniería ha crecido a 10, ubicado 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, los gráficos y la preimpresión, y automatiza el flujo eficiente de trabajo en las prensas y hasta el acabado.

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

Pero no crean todos los programas que utilizan. Cuando se trataba de actualizar su ERP, eligieron un producto estándar de Netsuite, en el que conectaron sus sistemas de gestión de pedidos hechos por sí mismos. Del mismo modo, recientemente lanzaron un CRM hecho a sí mismo en favor de Salesforce, lo que mantiene a su equipo de desarrollo centrado en crear software que no pueden comprar.

Las tres competencias que necesita para implementar las suyas propias

Los ejemplos que he analizado requieren cantidades diferentes de las siguientes tres competencias, según la complejidad de los requisitos de código personalizado:

Traducir las necesidades empresariales en proyectos de software.

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

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

Desarrollo de código.

Según las circunstancias, una empresa mediana podría tener un programador o un departamento de ingeniería completo. Por ejemplo, en mi empresa anterior, tuvimos a Dave, un joven empleado de almacén que codificaba como pasatiempo, subía las escaleras de vez en cuando para pequeños proyectos de codificació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 un director de tecnología.

Operaciones de software.

El aspecto de las operaciones de la administración de aplicaciones personalizadas es caro; debe mantener el estado del código personalizado y asegurarse de que sus procesos, personas y herramientas se mantengan actualizados. Los elementos de las operaciones incluyen asistencia al usuario/mesas de ayuda, capacitación, gestión de riesgos de seguridad, corrección de errores, personalización adicional continua, atributos de rendimiento y tiempo de actividad, y más.

Aprovechar el software local para llevar la innovación a su mercado o crear operaciones más eficientes puede ser un fuerte impulsor del crecimiento. Pero la decisión de comprarlo frente a construirlo es fundamental. Si comprar el software que necesita simplemente no es posible, compilarlo puede tener sentido. Pero no se puede negar que es un camino difícil, y solo vale la pena si el lado positivo es grande. Antes de crear, asegúrese de entender los costos reales para tener éxito a largo plazo y solo emprenda esos esfuerzos de redacción de códigos que está seguro de que su empresa es capaz.


Escrito por
Robert Sher



Related Posts
El complejo caso de la educación gerencial

El complejo caso de la educación gerencial

Cada año, aproximadamente 75,000 personas ganan MBAS de las escuelas de negocios en los Estados Unidos. Los programas de educación para la gestión también se han vuelto populares en Europa. En Japón, el desarrollo ejecutivo ha tenido lugar tradicionalmente dentro de la estructura corporativa, aunque el número de estudiantes japoneses que persiguen la educación de gestión de estilo occidental está en aumento. Sin embargo, cada vez más, ambos ejecutivos y académicos [...]
Leer más
3 cosas que te estás equivocando sobre el cambio organizacional

3 cosas que te estás equivocando sobre el cambio organizacional

A pesar del reconocimiento universal de la necesidad de cambiar y adaptarse con frecuencia, las empresas, en todo caso, han empeorado en ello. Algunos estudios sugieren que hasta el 75% de las iniciativas de cambio fracasan. El autor sugiere que corregir esta falla implicará voltear tres suposiciones profundamente sostenidas sobre lo que funciona en los negocios. Estos son: (1) voltear de seguir las mejores prácticas para compartir sus fallas; (2) voltear desde si no está roto no lo arregle para arreglarlo de todos modos; y (3) voltear desde el control de sus activos para compartir sus activos.

Leer más
Por qué menos es más en los equipos

Por qué menos es más en los equipos

¿Por qué es que el fútbol americano usa once jugadores, doce de fútbol canadiense y quince gaélico? ¿Por qué once en fútbol europeo? ¿Por qué el campo de béisbol nueve jugadores, el baloncesto cinco, el voleibol seis, el polo de agua siete y el cricket once? Sencillo como estas preguntas son, son engañosamente difíciles de responder. Pero cualesquiera que sean las razones históricas, el número de [...]
Leer más
Vender al consumidor reacio a la deuda

Vender al consumidor reacio a la deuda

Las compañías exitosas orientadas al consumidor en los próximos años serán aquellos que pueden averiguar cómo hacer que se realicen sin la vida anterior del Partido Económico: el pagador mensual. En su apogeo, este tipo de consumidor se preguntó a sí mismo si podía llegar a todo el costo de unas vacaciones o paisajismo o un [...]
Leer más
Proyectos de desarrollo: el motor de la renovación

Proyectos de desarrollo: el motor de la renovación

El esfuerzo del equipo digital en la década de 1980 para desarrollar unidades de disco de alta densidad es un ejemplo sobresaliente de cómo una empresa puede usar un proyecto de desarrollo para crear no solo un nuevo producto o proceso, sino también una experiencia competitiva. El compromiso, conocido como Proyecto RA90 DISCO DISCO-DRIVE, también demuestra una verdad crítica sobre los proyectos de desarrollo [...]
Leer más
Los economistas están demasiado seguros. Así que eres

Los economistas están demasiado seguros. Así que eres

¿Alguna vez ha pensado que los economistas tenían mucho más confianza en sus declaraciones sobre el mundo de lo que tenían derecho a ser? Bueno, ahora hay pruebas. Viene de Emre Soyer, que acaba de recibir su Ph.D en la economía y la toma de decisiones en la Universitat Pompeu Fabra en Barcelona, y su profesor Robin Hogarth, un psicólogo [...]
Leer más
Por qué los empleados no comparten conocimientos entre sí

Por qué los empleados no comparten conocimientos entre sí

Las empresas quieren que los empleados compartan lo que saben. La investigación ha encontrado que esto conduce a una mayor creatividad, más innovación y mejor rendimiento, para individuos, equipos y organizaciones. Sin embargo, a pesar de los intentos de las empresas de fomentar el intercambio de conocimientos (piense en esos espacios abiertos de oficinas), muchos empleados retienen lo que saben. Pueden hacerse el tonto, fingir no saber algo, prometer compartir algo pero nunca hacerlo, o decirle a la gente que no puede compartir cuando de hecho podrían hacerlo. Una nueva investigación descubre que la forma en que se diseñan los trabajos puede afectar si los empleados comparten u ocultan conocimientos a sus colegas. Los trabajos más complejos desde el punto de vista cognitivo, en los que las personas necesitan procesar grandes cantidades de información y resolver problemas complejos, tienden a promover un mayor intercambio de conocimientos, al igual que los empleos que ofrecen más autonomía. Al centrarse en estos aspectos del trabajo, los gerentes pueden animar a los empleados a compartir más y ocultar menos.

Leer más

Newsletter

Avanza tu carrera profesional, con el resumen semanal de las publicaciones, un libro de negocio resumido en 10 minutos y entrevistas con líderes de negocio