El mapa de proceso salió y los campos quedaron definidos. La pregunta siguiente es con qué herramienta se monta. Esta lección saca esa pregunta de la preferencia y la convierte en una puntuación de siete criterios; quien rellene la misma tabla puede llegar al mismo resultado.
En la segunda lección dibujó el mapa de proceso y en la tercera decidió qué campos recoger. Lo que tiene ahora es un trabajo medible. Esta lección trata de decidir con qué forma de montaje se hace ese trabajo.
La decisión de herramienta suele volverse una discusión de preferencias. En esta lección dejamos la discusión y ponemos en su lugar una puntuación con siete criterios. La puntuación saca la decisión de la opinión personal y la convierte en algo a lo que llega cualquiera que rellene la misma tabla.
Requisito previo: el mapa de proceso de la segunda lección. Sin mapa no se puede puntuar, porque la mayoría de los criterios se apoyan en lo que el mapa contiene.
Una automatización puede montarse de tres formas. Las tres pueden ser correctas; cuál lo es cambia con el trabajo. La distinción de abajo es el suelo sobre el que se apoyan los criterios siguientes.
Un sistema producido para hacer un trabajo concreto, que funciona tal como viene. El montaje es corto y el mantenimiento lo carga el proveedor. A cambio, el proceso se ajusta al producto y no el producto al proceso.
Una capa intermedia que permite montar flujos con bloques ya hechos. El proceso toma forma según sus propias reglas y no se escribe código. A cambio, según crecen los flujos el mantenimiento se acumula de su lado.
Un sistema escrito para el trabajo. Lo que el proceso es, eso se monta; el límite pertenece al trabajo y no a un producto. A cambio, es la forma con el montaje y el mantenimiento más pesados.
Las tres son alternativas entre sí tanto como capas unas de otras. En una empresa, la contabilidad puede ir en paquete cerrado, el flujo de solicitudes en no-code y el cruce de cartera en un desarrollo a medida.
La diferencia no es solo el tamaño de la carga sino su forma. En el paquete cerrado la carga es regular y previsible, y a cambio se espera que el proceso encaje en el producto. En no-code el montaje es ligero, pero según sube el número de flujos el mantenimiento se acumula en silencio. En el desarrollo a medida la carga se junta al principio y vuelve cada vez que se pide un cambio. Al decidir, tenga presente que las tres tienen un coste; lo que cambia es dónde cae y cuándo.
La decisión de herramienta viene después de escribir el proceso. En la primera lección apareció la frase la herramienta viene al final; esta lección es su equivalente aplicado. Una comparación de herramientas hecha sin mapa de proceso se convierte en comparar listas de funciones.
Comparar listas de funciones despista, porque cada producto enumera las funciones en las que es fuerte. Su medida debería ser lo que su trabajo pide, no lo que el producto hace. Y esa petición está escrita en el mapa.
Los tres primeros de los siete criterios miran al trabajo mismo. Dé a cada criterio bajo, medio o alto; también sirve una nota en un rango de 0-100 si lo prefiere.
¿Salió el mapa, llevan los pasos meses iguales? Un proceso asentado encaja con el paquete cerrado o con el desarrollo a medida. Si el proceso todavía cambia, no-code puede llevar el cambio barato.
¿Cuántas vías de excepción hay en el mapa? Pocas excepciones encajan con el paquete cerrado. Si son muchas, los casos que no caben en los moldes del producto se acumulan y vuelve el trabajo manual.
¿A cuántos sistemas toca el proceso? Un trabajo que se queda en un solo sistema puede correr en paquete cerrado. Si se van a conectar varios, destacan no-code o el desarrollo a medida.
Lea estos tres del mapa y no de memoria. Para el asentamiento, mire cuándo se actualizó el mapa por última vez. Para el número de excepciones, cuente cuántas vías de excepción se escribieron. Para la integración, liste los nombres de sistema que aparecen en los pasos. Como los tres se pueden contar, sus notas quedan cerradas a discusión.
Los dos criterios siguientes no miden el trabajo sino el lado que lo va a llevar. Cuando se saltan, lo que se monta es técnicamente correcto pero no vive en la empresa.
¿Quién va a cambiar el flujo? Si dentro hay alguien capaz de montar flujos, no-code es sostenible. Si no, cada cambio se pide fuera y los arreglos pequeños se acumulan.
¿Quién mantendrá después del montaje? En el paquete cerrado el mantenimiento está en el proveedor; en no-code y a medida, en usted. Una decisión tomada sin escribir el dueño del mantenimiento le sale al encuentro en el sexto mes.
Estos dos suelen moverse juntos. Si en el equipo nadie puede montar flujos, la carga de mantenimiento pasa fuera por sí sola; entonces el paquete cerrado, o un desarrollo a medida con contrato de mantenimiento, se vuelve la opción más realista.
Al puntuar la capacidad del equipo, mire el rol y no la persona. Si la capacidad se va con quien hoy monta el flujo, esa nota en realidad es baja. Del mismo modo, al puntuar la carga de mantenimiento, piense no solo en las primeras semanas tras el montaje sino en los momentos en que el proceso cambia: quién puede hacerlo y en cuánto tiempo cuando llega una petición de cambio es la medida real del mantenimiento.
Los dos últimos criterios son los que menos se preguntan al decidir y los que más caros salen después. Los dos piden leer un contrato, pero su pregunta es sencilla.
¿De quién es el dato, dónde reside, se puede sacar? El diccionario de campos de la tercera lección sirve aquí: pregunte campo por campo cuáles se pueden sacar.
¿Qué pasa si quiere dejar esta herramienta? En qué formato sale el dato, se pueden llevar los flujos, se detiene el trabajo durante el traslado. Una herramienta cuya respuesta se desconoce es una dependencia.
Preguntar por el coste de salida al decidir no es planear la marcha. Conocer la medida desde el principio abarata hoy una decisión futura.
Puntúe los siete criterios por separado para cada candidato. Por candidato no entendemos las tres formas sino sus equivalentes concretos: el nombre del producto que se está mirando, el nombre de la herramienta no-code que se está mirando, el presupuesto pedido para un desarrollo a medida.
Al puntuar, no pregunte si esta herramienta es buena sino si encaja con este trabajo en este criterio. La misma herramienta puede sacar alto en un trabajo y bajo en otro; la tabla mide el encaje y no la herramienta.
La columna de motivos es la parte más valiosa de la tabla. Cuando la decisión se discute más tarde, lo que se mira es el motivo y no la nota.
Una fila rellenada se ve así: criterio necesidad de integración, candidato paquete cerrado, nota baja, motivo se conecta al portal pero no tiene conexión con el sistema de cartera existente. Esa sola frase hace innecesario volver a preguntar lo mismo tres meses después. Una nota alta sin motivo suele ser una impresión y no una medición.
Cuando la tabla está rellena, suele salir uno de tres patrones. Los patrones son orientación y no regla fija; la decisión final sale del conjunto del trabajo.
El proceso está asentado, hay pocas excepciones, la necesidad de integración es baja, en el equipo nadie monta flujos y se quiere el mantenimiento fuera. La propiedad del dato pide aquí una pregunta aparte.
El proceso todavía cambia, se van a conectar algunos sistemas, en el equipo alguien puede montar flujos y el mantenimiento puede quedarse dentro. El coste de salida pide aquí una pregunta aparte.
Hay muchas excepciones, el proceso es propio de la empresa, la integración es profunda, la propiedad del dato es crítica. A cambio de la carga de mantenimiento, el límite lo marca el trabajo mismo.
Si la tabla muestra dos candidatos cercanos, la decisión no sale de los criterios sino de los pesos. Escriba qué criterio pesa más para usted; esa frase se vuelve el motivo de la decisión.
Las formas de montaje no se excluyen. Un orden habitual es este: los registros y la contabilidad están en paquete cerrado, los flujos propios de la empresa se montan en no-code, y solo la única pieza que no cabe en ningún molde se escribe a medida.
El precio del orden híbrido es la gestión de límites. Si no se escribe qué información se actualiza dónde, se rompe la regla de la única fuente correcta de la tercera lección y el dato empieza a separarse en dos sitios.
No hace falta pasar a un orden híbrido desde el principio. La mayoría de las empresas empieza con una sola forma y añade una segunda solo cuando aparece la pieza que no cabe en ningún molde. Ese orden permite asumir la carga de gestión de límites solo cuando de verdad hace falta.
La tabla de puntuación estrecha a los candidatos pero no decide sola. Montar una prueba pequeña con la lista estrechada convierte las suposiciones de la tabla en mediciones.
La prueba usa las mismas medidas del piloto de la primera lección: alcance estrecho, un disparador, salida visible, reversible a mano. La diferencia es que aquí el fin es probar la herramienta y no automatizar el trabajo.
El plan de salida es una nota corta escrita antes de montar la herramienta. Dentro hay tres cosas: en qué formato se puede sacar el dato, dónde reside el equivalente escrito de los flujos y cómo corre el trabajo durante un traslado.
Esta nota se escribe para ver la dependencia y no para marcharse. Un plan de salida que no se puede escribir puede ser una señal para volver a pensar la decisión misma.
No se corte al pedir el plan al proveedor. Un cliente que pregunta en la fase de decisión también se toma en serio del lado del proveedor, porque la pregunta muestra qué cláusula del contrato se ha leído. Una pregunta de salida que se esquiva ya dice algo sobre el criterio mismo.
En la primera lección la oficina inmobiliaria eligió el registro de solicitudes como piloto. En la segunda salió su mapa, en la tercera se definieron sus campos. Ahora miramos con qué herramienta se monta.
Candidatos: la oficina escribe tres candidatos. Un paquete cerrado hecho para el sector inmobiliario, una herramienta no-code general y un presupuesto de desarrollo a medida para añadir al sistema de cartera existente.
Proceso y excepciones: el mapa está asentado y los pasos llevan meses iguales. El número de excepciones es medio: la zona no coincide, una segunda solicitud, el asesor de vacaciones. Las tres están escritas.
Integración: el proceso toca tres sistemas: el portal, el sistema de cartera y la mensajería. El paquete cerrado lee el portal pero no se conecta con el sistema de cartera existente.
Equipo y mantenimiento: en la oficina hay un asesor capaz de montar flujos que hace él mismo los cambios sencillos. Se prefiere que el mantenimiento quede dentro.
Dato y salida: en el paquete cerrado los datos de cartera residen en el sistema del proveedor y la forma de sacarlos es limitada. En la herramienta no-code los registros se quedan en la propia hoja de la oficina y los flujos se pueden sacar por escrito.
Lectura: el paquete cerrado queda bajo en integración, propiedad del dato y salida. El desarrollo a medida pesa en la carga de mantenimiento. No-code sale medio en tres criterios y alto en cuatro.
Prueba: la oficina monta con la herramienta no-code solo el paso del acuse de recibo y prueba la excepción de zona que no coincide. La excepción se puede montar, el sistema de cartera se conecta y el asesor puede cambiar el flujo él mismo.
Decisión y plan de salida: se elige no-code. En el plan de salida se escribe esto: los registros están en la hoja de la oficina, la definición escrita de los flujos vive en el mapa de proceso y, si hiciera falta un traslado, el registro de solicitudes puede llevarse a mano durante una semana.
El rendimiento de esta lección viene de rellenar la tabla para su propia tarea piloto. Puede descargar la tabla de comparación de herramientas al pie de la página y usarla.
La tabla rellenada es la entrada de la quinta lección: montará la primera automatización con la herramienta elegida.
Descargar la tabla de comparación de herramientas (xlsx) · siete criterios, tres candidatos y columnas de motivos, junto con las secciones de montaje de prueba y plan de salida.
Cada producto enumera las funciones en las que es fuerte. La comparación se hace según lo que pide su mapa y no según lo que hace el producto.
Una demo enseña el flujo normal y no las excepciones. Lo que decide no es el flujo normal sino que las excepciones del mapa se puedan montar.
Elegir no-code cuando dentro nadie puede montar flujos hace que cada cambio pequeño dependa de fuera, y los arreglos se acumulan.
Cuando la pregunta de dónde reside el dato se hace tras el montaje, cambiar la respuesta sale caro. La pregunta va en el momento de decidir.
Una herramienta con salida desconocida es una dependencia. Si la pregunta no se hace, la dependencia solo se ve cuando hace falta marcharse.
Cuando una herramienta va bien y todo el trabajo se muda a ella, los procesos que no encajan se fuerzan. Un orden híbrido suele producir menos resistencia.
Antes de tomar la decisión de herramienta, conviene poder decir sí a todos los puntos de abajo.
Los términos que aparecen en las conversaciones sobre herramientas. Hablar la misma lengua que el proveedor acorta la comparación.
En esta lección decidió con qué herramienta se monta y escribió el motivo de la decisión. La lección siguiente trata de montar la primera automatización con esa herramienta: las cinco partes presentadas en la primera lección se vuelven práctica allí.
Si quiere seguir con las lecciones publicadas, el séptimo módulo cuenta dónde mirar cuando un flujo montado no corre como se esperaba.
La ficha de montaje, montar las cinco partes en orden y salir a producción por una puerta estrecha.
El diccionario de campos. La base del criterio de propiedad del dato.
La sección de formación completa y los módulos añadidos después.
Si quiere que puntuemos juntos sus candidatos, escríbanos y rellenamos la tabla con usted.
Solicitar Presupuesto por WhatsApp