Tercerización y Know-How

Ayer conversaba con amigos del ambiente IT de Ctes. y estabamos conversando cuando me dí cuenta que aprendí algo, tal vez lo recordé.

Tercerización
En un ambiente laboral IT como el de Corrientes, se tiende a tercerizar mucho, es una necesidad muchas veces. La tercerización típica necesariamente involucra a empresas, por el respaldo que tiene su situación jurídica (mucho más firme y "permeable" a reclamos contractuales que el proveedor monotributista individual).

Sin embargo, a veces es necesario tomar gente, hacer que formen parte de la organización.

¿Por qué? El motivo es el Know How.


Know-How
El Know How, el cómo se hace algo es lo que las empresas a las que se terceriza un trabajo no van a revelar en gral., ya que ello es parte fundamental de su ventaja competitiva: el cómo hacer más rápido algo, cuales son los puntos clave a verificar para que todo esté bien hecho y terminado correctamente, cuales son los requerimientos clave a satisfacer (que no siempre son obvios), etc. etc.

La pérdida del Know How por tercerización IT para una organización debe ser idealmente nula: lo que una tercerización va a lograr es realizar un trabajo temporal y de excepción (por su envergadura, por ser una tarea imprevista, por ej.), en tiempos aceptables y requeridos por la organización, no alcanzables EN EL TIEMPO REQUERIDO sin los recursos tercerizados; pero que sí serían alcanzables de disponer más tiempo (redundando, es un trabajo que sí lo podrían realizar los empleados internamente, si dispusieran de más tiempo).

Si en cambio al tercerizar un trabajo IT estamos perdiendo Know How clave de poseer para el éxito de IT dentro de la organización, ello implica un serio fallo organizativo.

Es vital y clave que el conocimiento necesario para llevar bien y cumplir los objetivos IT esté presente y activo dentro de la organización. Si ese conocimiento vital y clave existe solamente fuera de la organización (en una empresa tercerizada por ej.), ello es una cuestión muy seria, que debe ser resuelta lo antes posible.

El motivo es que si la organización en algun momento no tuviera suficiente dinero para pagar los servicios de la empresa tercerizadora, podría verse expuesta al riesgo y/o al hecho de no poder cumplir con los objetivos IT que necesita para poder funcionar.


El error típico
Es un error típico suponer que una empresa tercerizada va a brindar "accidentalmente" (por ej. haciendo que los empleados propios miren "por arriba del hombro" mientras están trabajando los implementadores), entrenamiento y capacitación al personal interno, o que el conocimiento compartido durante la implementación tercerizada va a ser el necesario para poder dejar de contratar a la empresa tercerizadora.

Suele incluso estar formalmente prohibido a los empleados de las empresas tercerizadoras el compartir información de know-how, con políticas claras respecto a qué información se puede o no compartir con los clientes.

Por supuesto y obviamente, cualquier información que implique "entrenamiento" o "capacitación" figura entre los primeros lugares de la lista de cosas a no compartir con los clientes.

A lo sumo, si dicho "entrenamiento" está disponible, será un servicio más, comprable por un costo, diferente y adicional a lo que se paga por realizar el trabajo.

Por ejemplo: al tercerizar un desarrollo en PHP, el trabajo pagado suele ser el programar el sistema en PHP. Si además, la tercerizadora debe enseñar a programar en PHP, ello tiene un costo adicional.

Además, el costo por hora de los entrenamientos y capacitación técnica, suele ser en gral. muy superior al costo de cualquier servicio IT. Ello es un motivo por demás importante para que las tercerizadoras pongan especial énfasis en capacitar "accidentalmente" a sus clientes.


La solución
La solución es identificar el know how necesario dentro de la organización y planificar para ir incorporándolo lo antes posible. Algunos caminos posibles son:

1) Training para los empleados actuales
2) Incorporar personal con los skills necesarios
3) Tomar personal nuevo, sin capacitación y entrenarlos.

1) Este ítem tiene un requerimiento base: hay que liberar horas de trabajo que los empleados van a utilizar para aprender lo enseñado en un training. De hecho, en IT, si un empleado adquiere un entrenamiento, lo necesario para se vuelva un experto en el tema - recordemos ello podría ser una necesidad organizacional - es que tome práctica habitual.

Es decir, si le vamos a brindar training sobre una nueva materia a un empleado, deberíamos destinarle horas de trabajo para que use ese entrenamiento, de lo contrario arriesgamos a que ese entrenamiento se pierda con el tiempo: si más tarde hace falta que el empleado use ese entrenamiento, aunque ya esté entrenado, igualmente es muy posible no que no este efectivamente capacitado para realizar el trabajo.

2) Este otro ítem también tiene un requerimiento base: compartir la información. Parte del acuerdo de buena fe entre empleado y empleador es que los requerimientos laborales van a ser satisfechos durante la permanencia en el puesto. Si desde el vamos el empleado sabe y entiende que compartir su know how es parte del trabajo (y es mejor aún si ello figura en la documentación laboral), idealmente tendremos solucionado el issue y el know how necesario gradualmente será incorporado en la organización.

Es un error habitual pensar que las tercerizaciones "por un tiempo" - días a semanas en gral. - permiten realizar una efectiva incorporación de know how (sin que se haya pagado por training), ya que por una cuestión lógica, si una empresa tercerizadora tiene que realizar un trabajo en un rango de tiempo pre-acordado, es imposible que disponga de tiempo libre para enseñar ni "transferir" conocimiento.

En el caso de un empleado, esos tiempos "libres" sí van a estar disponibles durante la dinámica laboral típica, y es allí donde al cabo de un tiempo - bastantes meses a años inclusive - el know how será incorporado a la organización.

Si los "tiempos libres" no están disponibles realmente, será también necesario reordenar la dinámica laboral para que se dé el espacio necesario para la provisión y adquisición de know-how en la organización (Ejemplos de que no haya "tiempos libres": son muy breves intervalos, están limitados a los tiempos fuera del horario de trabajo que el empleado quiera - o no - disponer para participar en actividades no obligatorias, etc.).


3) Este ítem suele ser elegido en gral. y tiene un requerimiento base primordial: los nuevos empleados a ser entrenados deben ser contratados y entrenados PREVIO a la necesidad de su participación en la tarea (y responsabilidad) en cual están por ser entrenados. Parece un chiste, pero no lo es, es típico que con el fin de bajar costos, o evitar "competencia" para los empleados actuales, se tome personal IT sin entrenamiento, para entrenarlo DURANTE la necesidad de su trabajo.

Eso generalmente sale mal, falla. La situación normal en la que falla es cuando hace falta que el empleado tenga un nivel de entrenamiento mayor al básico; es decir, hablando de las circunstancias típicas de IT:

En casi cualquier situación donde no se esté entrenando gente para una necesidad FUTURA, implica que si se tomar personal sin capacitación para entrenar DURANTE el trabajo, para trabajos de cierta complejidad técnica, ello va resultar mal. Ni hablar de si se requiere experiencia para la tarea (en casi cualquier trabajo donde aparezca la palabra "diseño" o "arquitectura", estamos hablando de que hace falta gente que tenga experiencia).

Conclusión
Por esos motivos muchas veces es mejor tomar personal con buen nivel de know how versus recurrir a la "salvación" temporal de "adquirir" una tremenda capacidad técnica adicional - ausente internamente en la organización - para solucionar hoy una necesidad que es permanente, y ello a costa de no tomar empleados permanentes, lo que el día de mañana puede implicar que el know-how no esté presente cuando sea necesario e indispensable.

La opción, con la salvedad antes mencionada, es el training, pagado y acordado con las tercerizadoras (que suelen tener el mejor expertise disponible en capacitaciones a alta velocidad por cierto).

Los responsables de sistemas tienen entre sus responsabilidades más importantes el identificar el know-how necesario hoy  y ausente y el know-how necesario a futuro para los planes IT en la organización; y tomar las medidas necesarias tendientes a adquirirlo ANTES de que sea necesario.

Afortunadamente, muchos responsables IT en Ctes. están en pleno trabajo llevando adelante esos planes de adquisición de Know-How, inclusive peleando con circunstancias organizacionales y/o económicas que les juegan en contra.