Acompañamiento en la transformación digital
En resumen: Un cambio digital se refiere a la forma en que está organizado el trabajo, no a los programas que se instalan. El valor procede de comprender los procesos tal como ocurren realmente, del orden en que se abordan y de la atención prestada a las personas que tendrán que trabajar de otra manera: todo ello se decide antes de elegir una herramienta y a menudo reduce la necesidad de comprarla.
«Vamos a digitalizarnos» rara vez significa lo mismo en una empresa que en otra. Para una consiste en dejar de teclear la misma información en cuatro sitios; para otra, en saber por fin en qué punto están los expedientes en curso; para una tercera, en sustituir un programa que se ha vuelto impracticable sin reproducir sus defectos. Lo que estas situaciones tienen en común no es técnico: son procesos que se han ido acumulando con el tiempo, que nadie ha puesto por escrito y que cada cual sortea a su manera. Esta página describe qué abarca realmente un cambio digital, cómo se observa una organización antes de modificarla, cómo se desarrolla un acompañamiento, los errores que aparecen con más frecuencia y las situaciones en las que la respuesta honesta consiste en no emprender nada por ahora.
Qué es un cambio digital y por qué no es la compra de un programa
En resumen: La palabra abarca tres proyectos de envergadura muy distinta: sustituir un soporte físico por un archivo, reorganizar el encadenamiento de las etapas o hacer legible una información que no lo era. Ninguno de los tres se obtiene instalando un producto.
Cuando una empresa anuncia que va a digitalizarse, la frase designa casi siempre una intención de compra: un programa de gestión, una herramienta de seguimiento, un espacio compartido. Sin embargo, la compra es la parte más sencilla y la menos determinante. Una herramienta no hace nada por sí misma; hace posible una manera de trabajar que todavía hay que decidir, escribir y conseguir que se adopte. Es esa decisión, y no la licencia, la que produce el resultado. Eso explica una observación banal y a la vez instructiva: dos empresas equipadas con el mismo producto obtienen beneficios sin relación entre sí, porque una modificó su forma de trabajar y la otra se limitó a trasladar la antigua a una interfaz nueva.
Detrás de la misma palabra se esconden tres proyectos de envergadura creciente. El primero es la desmaterialización: el proceso sigue siendo idéntico y solo cambia el soporte. Un documento circula como archivo en vez de como hoja de papel, se vuelve consultable a distancia y deja de perderse. Es útil, se consigue rápido y no corrige nada de lo que ya cojeaba: un encadenamiento de etapas incoherente lo sigue siendo, simplemente circula más deprisa. El segundo proyecto es la reorganización del proceso en sí: una validación desaparece porque ya no protegía nada, dos etapas se fusionan, una información se registra una sola vez en su origen en lugar de copiarse después por todas partes. Aquí se tocan los papeles de cada cual y los hábitos, lo que explica que sea a la vez el proyecto más rentable y el más difícil.
El tercer proyecto afecta a lo que la organización sabe de sí misma: cuando las informaciones dejan de estar dispersas, preguntas que se quedaban sin respuesta pasan a ser tratables: cuántos expedientes esperan, en qué etapa se detienen, cuáles vuelven siempre a corrección. Ya no cambia la ejecución, cambian las decisiones.
Lo que se denomina gestión del cambio designa la materia real de este trabajo: hábitos adquiridos por personas que tuvieron buenas razones para adquirirlos, funciones que definen el lugar de cada cual, una responsabilidad implícita sobre la calidad de los datos que nadie ha formulado nunca y arbitrajes aplazados durante tanto tiempo que la organización se ha construido a su alrededor. El programa es la parte visible y la más fácil de encargar. Lo que decide el éxito ocurre en conversaciones sin pantalla: quién valida qué a partir de ahora, quién responde cuando aparece una excepción, qué se acepta dejar de hacer.
Queda por decir lo que el término no abarca. No es un proyecto informático encargado a un proveedor mientras la empresa continúa como antes: el conocimiento de los procesos pertenece a quienes los ejecutan y ninguna mirada externa lo sustituye, solo lo hace visible. Tampoco es un estado permanente que se alcance de una vez por todas; son proyectos sucesivos, cada uno con un principio y un final identificables. Y no es necesariamente una cuestión de herramientas nuevas: es frecuente que una organización disponga ya de funciones pagadas y jamás activadas, y que un trabajo de ordenación baste para volverlas útiles.
Cómo se observa una organización antes de modificarla
En resumen: Cartografiar un proceso consiste en escribir lo que ocurre realmente y no lo que dice el procedimiento. Las fricciones se reconocen después por señales constantes: información vuelta a teclear, expediente a la espera de una persona, excepción tratada de memoria, control repetido por desconfianza.
Un proceso es una sucesión de etapas que va de un acontecimiento desencadenante a un resultado: llega una solicitud, ocurre algo, un cliente recibe una respuesta o sale una factura. Cartografiarlo consiste en escribir esa sucesión tal como se desarrolla, con las personas que intervienen, los soportes que utilizan de verdad —una hoja de cálculo, un buzón de correo que hace las veces de cola de espera, un cuaderno—, los momentos de decisión y los momentos de espera. La dificultad está en la distancia entre el trabajo prescrito y el trabajo real: el procedimiento escrito, cuando existe, describe el caso nominal, mientras que el tiempo se consume en las excepciones. Por eso seguir un expediente real de principio a fin enseña más que una entrevista sobre el funcionamiento general, en la que cada cual describe de buena fe lo que el proceso debería ser.
Los puntos de fricción se agrupan en un número reducido de familias, y nombrarlos sirve para elegir el remedio adecuado. La reintroducción de datos aparece cuando la misma información se escribe en varios sitios por personas distintas: cuesta tiempo, pero sobre todo fabrica divergencias. La espera designa un expediente que no avanza por falta de una persona disponible, no por falta de trabajo. La búsqueda abarca el tiempo dedicado a encontrar una información en lugar de usarla. La corrección consiste en arreglar aguas abajo un error introducido aguas arriba. El control redundante, por último, es una verificación que existe porque no se confía en la anterior. Cada una exige una respuesta distinta: la reintroducción pide un punto de entrada único o un enlace entre herramientas, la espera una regla de delegación, la búsqueda un criterio de clasificación y de nomenclatura. Ninguna de esas tres respuestas es forzosamente una compra.
Llega después la cuestión de los datos compartidos. Una organización necesita, para cada tipo de información, un lugar que dé fe: la lista de clientes, la de tarifas vigentes, el estado de avance de un expediente. Cuando dos herramientas guardan cada una su versión de la misma lista, una de ellas es falsa y nadie sabe cuál; los equipos acaban fiándose de la que prefieren, lo que vuelve invisibles las discrepancias. Preguntarse cuál es el lugar que da fe, en qué formato se guarda la información y quién es responsable de actualizarla es un trabajo previo, sin el cual cualquier enlace técnico se limitará a propagar los errores más deprisa. Es también el momento de examinar la interoperabilidad: ¿deja la herramienta salir sus datos en un formato aprovechable?, ¿sabe conectarse con lo que ya está instalado?, ¿o impone una exportación manual que alguien tendrá que repetir indefinidamente?
La dimensión humana se trata con la misma seriedad que la técnica, y se trata mal solo con comunicación. Las reticencias rara vez son irracionales: una persona que ha construido arreglos eficaces alrededor de una herramienta mediocre defiende un sistema que funciona, y se le pide volver a ser principiante en una tarea que dominaba. Tres cosas logran más que cualquier anuncio. Hacer participar a los interesados en la descripción del proceso, porque corregirla los convierte en autores de lo que viene después. Decir explícitamente qué no cambia, sin lo cual cada cual imagina lo peor. Y responder con claridad a la pregunta sobre el tiempo liberado, que se plantea en silencio desde la primera reunión y que envenena el proyecto mientras siga sin respuesta.
Queda un criterio que siempre se lamenta no haber examinado antes: la reversibilidad. Toda decisión tiene un coste de salida, y más vale conocerlo antes de comprometerse que después. La dependencia se crea por tres vías principales: datos encerrados en un formato que solo el editor sabe leer, una configuración que existe únicamente en la cabeza de una persona y un proceso reconstruido en torno a las particularidades de un producto hasta el punto de no poder desprenderse de él. Las preguntas que hay que hacer antes de firmar son, por tanto, prosaicas y llegan mucho antes que las demostraciones: cómo se recuperan los datos y en qué forma, quién administra la herramienta en el día a día, qué ocurre con el proceso si la empresa decide cambiarla.
Cómo se desarrolla un acompañamiento
En resumen: Observar antes de proponer, jerarquizar en lugar de tratarlo todo, simplificar antes de equiparse, desplegar en un perímetro restringido y acompañar después a los equipos hasta que la antigua forma de trabajar se haya detenido de verdad.
La primera fase es una observación, no una propuesta. Se conversa con las personas que ejecutan el trabajo más que con quienes lo describen, se siguen expedientes reales, se recogen los soportes realmente utilizados, incluida la hoja de cálculo oficiosa que sostiene todo el edificio y de la que nadie habla en las reuniones. También se inventaría lo que ya está instalado y ya pagado, porque las funciones dormidas son frecuentes. Esta fase produce un documento: la descripción escrita de los procesos afectados, devuelta a los equipos para su corrección. Esa revisión no es un trámite: es donde afloran las excepciones olvidadas, y es también el primer momento en que las personas implicadas ven que el trabajo se hace con ellas.
Llega la jerarquización, que consiste sobre todo en renunciar. Una organización que decide tratarlo todo a la vez no trata nada: los equipos solo pueden absorber un número limitado de cambios simultáneos sin que baje la calidad. Los criterios de elección son la frecuencia de la etapa afectada, la molestia realmente sentida por quienes la sufren, las dependencias —algunas etapas deben corregirse antes que otras, que se apoyan en ellas—, la reversibilidad y el carácter observable del resultado. El irritante más ruidoso no siempre es el primero que hay que tratar: un primer proyecto modesto, visible y poco arriesgado crea el crédito necesario para abordar después los asuntos que afectan a los papeles de cada cual.
La simplificación precede al equipamiento, y ese orden no es negociable. Se suprimen las etapas que ya solo existían por costumbre, se fusionan los formularios que piden lo mismo, se escriben las reglas de validación que seguían implícitas, se decide un lugar único para cada tipo de información. El proceso así aligerado se convierte en el pliego de condiciones. Confrontado con las herramientas, permite plantear las preguntas correctas: ¿sabe este producto hacer lo que nosotros hacemos y a qué precio en contorsiones? Un programa siempre impone una forma de trabajar; la elección consiste en saber cuál de sus limitaciones se acepta a conciencia, en lugar de descubrirla después del despliegue. La respuesta menos espectacular —conservar la herramienta instalada y cambiar su uso— sigue siendo a menudo defendible.
El despliegue se hace sobre un perímetro real pero restringido: un equipo, un tipo de expediente, una etapa. Se define de antemano qué valdrá como confirmación, qué valdrá como alerta y en qué condición se da marcha atrás; decidirlo por adelantado evita tener que decidirlo bajo presión. A veces es necesario un periodo en el que convivan la antigua y la nueva forma de trabajar, siempre que sea querido y esté acotado por una condición de salida escrita, y no simplemente sufrido. Durante esa fase se documenta el proceso a medida que se estabiliza, y no después, cuando ya nadie recuerda las razones de una elección.
El acompañamiento de los equipos continúa tras el arranque, periodo en el que se juega lo esencial. La formación aborda los casos reales del oficio y no los menús del programa, empezando por las situaciones incómodas: qué se hace cuando el caso no encaja en ninguna casilla prevista, a quién hay que dirigirse, cómo se avisa de que algo no funciona. Una persona de referencia identificada vale más que una dirección anónima, y hay que volver a ver al equipo una vez pasada la novedad, porque es entonces cuando reaparecen los apaños. Un proyecto termina con tres condiciones: el nuevo procedimiento está escrito y accesible, el antiguo se ha retirado explícitamente y alguien queda designado para mantenerlo. Mientras las dos formas de trabajar convivan sin decisión, los datos se separan en silencio.
Las maneras de fracasar en un cambio digital
En resumen: Equiparse antes de haber comprendido el proceso, reducir la formación a una demostración el día del arranque, apilar programas que no se comunican, decidir sin quienes hacen el trabajo y no detener nunca el método anterior.
El primer error consiste en elegir la herramienta antes de haber descrito el proceso. Produce dos desenlaces, ambos costosos. O bien el trabajo se deforma para entrar en las hipótesis del programa, sin que nadie haya elegido esa reorganización: se impone por omisión y se descubre padeciéndola. O bien el producto se adapta a golpe de desarrollos específicos hasta reproducir fielmente el desorden anterior, a un coste superior y con una dependencia de propina. La señal más fiable de que se ha cometido este error aparece algún tiempo después del arranque: reaparecen hojas de cálculo paralelas. Significan que la herramienta no cubre un caso real y que el equipo ha reparado la carencia en silencio, sin decirlo, porque oficialmente el proyecto era un éxito.
El segundo consiste en reducir la formación a una demostración en el momento del arranque. Una demostración muestra las pantallas en el orden cómodo, ante personas que todavía no tienen ningún expediente urgente esperando. Lo que un equipo necesita es distinto: ver tratados sus propios casos, en particular los penosos, y saber qué hacer cuando la herramienta no sabe hacer algo. La otra variante del mismo problema consiste en formar a una persona de referencia para que ella forme a las demás. El conocimiento se concentra entonces en una sola cabeza; el día en que esa persona se ausenta o deja la empresa, el proceso se va con ella. Escribir el procedimiento y hacer que varias personas lo practiquen cuesta poco y evita exactamente eso.
El tercero es el apilamiento de herramientas que no se comunican. Cada necesidad encuentra su respuesta por separado, cada producto es bueno de forma aislada y nadie decide sobre el conjunto. Las personas se convierten entonces en la interfaz entre los programas: copian de una pantalla a otra, arbitran entre dos versiones contradictorias del mismo dato, saben cuál está al día porque se acuerdan. El coste de las suscripciones se ve en una factura; el coste de esa coordinación no se ve en ninguna parte y aumenta con cada añadido. Antes de introducir una herramienta más, conviene hacerse dos preguntas: ¿a qué sustituye y cómo se enlaza con lo que queda? Una herramienta que añade un sitio que consultar sin suprimir otro añade trabajo.
El cuarto tiene que ver con la manera en que se toma y se anuncia la decisión. Un cambio concebido lejos de quienes hacen el trabajo se apoya en una descripción falsa del proceso y se recibe como una sospecha de ineficacia, lo que basta para producir un rechazo cortés y duradero. Cuatro puntos merecen plantearse explícitamente antes del primer despliegue: el problema que se quiere resolver y en qué se sabrá que lo está, el perímetro afectado en esta etapa y el que todavía no lo está, la manera en que deben transmitirse las dificultades encontradas y a quién, y la persona que zanja cuando dos departamentos no se ponen de acuerdo. A ello se añade una elección de calendario demasiado descuidada: lanzar un cambio durante el periodo de mayor carga de la actividad garantiza que nadie tendrá la disponibilidad mental para aprenderlo, y convierte una dificultad normal en un fracaso atribuido a la herramienta.
El quinto es no detener nunca el método anterior y no haber anotado en ninguna parte el estado inicial. Mientras los dos sistemas convivan sin decisión, las informaciones se reparten entre ellos según las preferencias de cada cual y ninguno de los dos está completo; la organización acaba siendo menos fiable que antes de empezar. En cuanto al estado inicial, si no se ha descrito —cuántos sitios había que consultar para responder a una pregunta corriente, qué etapas obligaban a pedir de nuevo una información ya facilitada, de qué se quejaban los equipos espontáneamente—, la discusión sobre los resultados se reducirá a impresiones contradictorias. Estos dos olvidos se juntan en un tercero: el proyecto sin final definido, que se desliza hacia una configuración permanente que ya nadie se atreve a interrumpir.
Cuándo un acompañamiento en la transformación digital no es la respuesta adecuada
En resumen: Una organización en crisis debe estabilizarse primero; un equipo muy reducido gana a menudo más suprimiendo etapas que añadiendo una herramienta; y ninguna fluidez interna compensa una oferta que no encuentra comprador.
El primer caso es el de la organización en crisis. Una tesorería tensa, un conflicto interno sin resolver, un vencimiento normativo inminente, la marcha de la persona que sostenía sola una parte de la actividad: esas situaciones reclaman exactamente lo que un cambio consume, es decir, atención, disponibilidad y tolerancia a un deterioro temporal del rendimiento. Y todo cambio empeora las cosas antes de mejorarlas, porque los automatismos adquiridos dejan de servir durante el periodo de aprendizaje. Lanzar una transformación en ese momento equivale a pedir un esfuerzo suplementario a un equipo ya en números rojos. La secuencia honesta es la inversa: estabilizar primero, incluso con medidas toscas y provisionales, y transformar después, cuando la organización vuelva a disponer de margen.
El segundo caso es el del equipo muy reducido. Buena parte del valor de una herramienta de gestión reside en la coordinación: permite que personas que no hablan entre sí compartan un estado común. En un equipo donde todo el mundo sabe lo que hacen los demás, ese beneficio es escaso, mientras que los costes se mantienen íntegros: una suscripción, una administración que asegurar, una cosa más que mantener al día, un sitio más donde buscar. La ganancia está entonces en otra parte: suprimir etapas, reducir el número de sitios donde se escribe la información, dejar de producir un informe que nadie lee, unificar dos archivos en uno. Esos cambios no se venden bien, no lucen en una página de inicio y con frecuencia rinden más. El equipamiento resulta pertinente más tarde, cuando la plantilla crece o cuando hay que poder sustituir a alguien.
El tercer caso es aquel en que el problema no está en el proceso. Un cambio digital vuelve a una organización más eficaz en lo que ya hace; no dice nada sobre la pertinencia de lo que hace. Si el producto no encuentra su mercado, si el margen es estructuralmente insuficiente, si los clientes se van por una razón que tiene que ver con la oferta, mejorar la circulación interna de las informaciones solo acelera la marcha hacia el mismo muro. El diagnóstico debe, por tanto, distinguir una empresa frenada por sus procesos de una empresa con dificultades comerciales que atribuye a sus herramientas una causa que está en otro sitio. La confusión es frecuente y comprensible, porque el proceso es un objeto reparable, mientras que la otra pregunta resulta dolorosa.
El cuarto caso tiene que ver con la disponibilidad de la decisión. Un proyecto de esta naturaleza plantea arbitrajes que ningún proveedor puede zanjar en lugar de la empresa: quién valida a partir de ahora, qué excepción deja de tratarse, qué regla pasa a ser exigible. Si nadie tiene el mandato de decidir, o si quienes lo tienen no pueden reservar el tiempo necesario, el trabajo se detiene en la fase de diagnóstico y produce un documento que nadie aplicará. Lo mismo ocurre con los equipos saturados: la disponibilidad para aprender es un recurso igual que el presupuesto, y se reserva antes de empezar. Más vale aplazar que producir un informe más.
El quinto caso es una cuestión de momento. Un cambio se justifica por un desencadenante: un crecimiento que vuelve impracticable la coordinación informal, la marcha previsible de la persona que posee un saber no escrito, una obligación nueva, un volumen que ya no pasa. A falta de desencadenante, una organización que funciona puede decidir legítimamente seguir así, y eso no es ir con retraso. La pregunta útil no es, por tanto, si una empresa va adelantada o atrasada, sino si algo la molesta lo bastante como para justificar el esfuerzo. Cuando la respuesta es no, decirlo forma parte del trabajo, y emplazarse para cuando la situación haya cambiado vale más que un proyecto lanzado por no quedarse quieto.
Preguntas frecuentes
¿Un cambio digital implica forzosamente programas nuevos?
No, y a menudo ocurre lo contrario. Una parte importante de las mejoras procede de suprimir etapas que se habían vuelto inútiles, de decidir un lugar único para cada tipo de información o de activar funciones ya incluidas en una herramienta instalada y nunca utilizadas. El programa se vuelve necesario cuando el proceso simplificado supera lo que las herramientas existentes pueden sostener, no antes. Empezar por la compra equivale a responder a una pregunta que todavía no se ha formulado.
¿Por dónde empezar cuando parece que hay que rehacerlo todo?
Por una sola cosa, elegida por buenas razones. Primero se describe el proceso más frecuente, el que afecta a más expedientes, porque es ahí donde las fricciones se repiten. Después se elige un primer proyecto modesto, visible y reversible, del que se sabrá decir si ha funcionado. Tratarlo todo a la vez garantiza lo contrario del resultado buscado: la atención disponible se dispersa, ningún proyecto llega lo bastante lejos como para producir un efecto visible y la organización concluye que nada funciona. Un primer proyecto llevado hasta el final hace que el siguiente resulte mucho más fácil de aceptar.
¿Hace falta una persona de referencia interna y qué hace exactamente?
Sí, y su papel es más amplio de lo que parece. No es el especialista del programa, sino el punto de contacto del equipo: recoge los irritantes, distingue lo que procede de una falta de formación de lo que procede de un defecto de concepción y transmite los casos no previstos. Debe estar disponible, ser conocida por todos y estar reconocida por la dirección. En cambio, no debe ser la única que sabe: el conocimiento tiene que estar escrito y practicado por varias personas, pues de lo contrario su ausencia bloquea el proceso.
¿Qué hacer cuando una parte del equipo se opone?
Escuchar la objeción antes de responderla, porque suele ser acertada. Una oposición señala con frecuencia un caso real que el nuevo proceso no cubre, o una carga suplementaria que no se había visto. Funcionan tres palancas: hacer participar a los interesados en la descripción del proceso, decir explícitamente qué no cambia y mostrar un beneficio para la propia persona y no solo para la organización. Lo que no funciona es tratar el rechazo como un problema de comunicación que se arregle con una reunión más.
¿Qué ocurre con las hojas de cálculo y los archivos existentes?
Merecen un examen antes que un abandono. Una hoja de cálculo que sostiene una actividad contiene reglas del oficio que nunca se han escrito en otro sitio: es una fuente de documentación valiosa. La migración de los datos plantea después tres preguntas distintas: qué se traslada, qué se archiva sin trasladarse y qué se abandona porque ya no tiene uso. Trasladar íntegramente un historial dudoso importa los errores a la nueva herramienta y hace perder la confianza desde el primer uso.
¿Es preferible una herramienta única o varias especializadas?
Depende de la cantidad de información que deba circular entre las etapas. Una herramienta única simplifica la coherencia de los datos y la administración, a costa de funciones medianas en todo. Las herramientas especializadas hacen mejor cada una lo suyo, pero el coste se desplaza hacia los enlaces entre ellas y hacia las personas que los sostienen. El criterio de decisión es, por tanto, la interoperabilidad real y no la riqueza funcional: un producto excelente que no deja salir sus datos acaba condicionando al resto de la organización.
¿Cómo evitar quedar cautivo de un editor?
Tratando la salida como un criterio de elección y no como una hipótesis desagradable. Tres comprobaciones antes de comprometerse: si los datos pueden exportarse en un formato legible sin la herramienta, si la configuración está documentada en otro sitio que no sea la memoria de una persona y si el proceso sigue siendo comprensible con independencia del producto. También hay que comprobar quién administra la herramienta a diario: cuando esa competencia está totalmente externalizada, la dependencia recae sobre el proveedor tanto como sobre el programa.
¿En qué se nota que un cambio ha servido realmente?
En señales observables, elegidas y anotadas antes de empezar. Según los casos: el número de sitios que hay que consultar para responder a una pregunta corriente, el número de veces que se registra la misma información, la distancia entre la llegada de una solicitud y el momento en que alguien se hace cargo de ella, la capacidad de responder a un cliente sin consultar a un compañero, la facilidad con que una persona retoma un expediente empezado por otra. También se observa el uso real del nuevo proceso: la reaparición de archivos paralelos es la señal más fiable de que un caso no está cubierto.
¿Cómo se sabe que un proyecto ha terminado?
Un proyecto no termina cuando la herramienta está instalada, sino cuando se cumplen tres condiciones: el nuevo procedimiento está escrito y accesible, el antiguo se ha retirado explícitamente en lugar de dejarse en paralelo y hay una persona designada para mantener el conjunto. Sin ese punto de parada, el proyecto se prolonga en ajustes indefinidos y la organización se acostumbra a vivir en obras. Transformar una organización no es un estado continuo: es una sucesión de proyectos que empiezan y que terminan.
¿Se puede hacer este trabajo internamente, sin una mirada externa?
Sí, y muchas organizaciones lo hacen. La mirada externa aporta dos cosas difíciles de obtener desde dentro: plantea las preguntas ingenuas que ya nadie se atreve a hacer y no tiene intereses en los arbitrajes entre departamentos. En cambio, no posee el conocimiento del oficio, que sigue estando en quienes lo ejercen. Un acompañamiento que pretendiera decidir en lugar del equipo produciría una descripción teórica del trabajo, es decir, precisamente el documento que nadie aplica.