NEOinsight: Planificando un proyecto de movilidad
1/ ¿MI EMPRESA NECESITA APLICACIONES MÓVILES?
Al mismo tiempo encontramos muchas organizaciones que consideran que no hay una necesidad real o que pueden seguir trabajando perfectamente como lo hacen en la actualidad. Los argumentos que utilizan pueden parecer igual de válidos: lo considero una moda, actualmente van bien las cosas o no veo necesario aplicar cambios, confío en el buen hacer de mis empleados, etc.
Como casi siempre, ninguno de los extremos es válido. Ni todas las empresas necesitan una aplicación móvil, ni es prudente ignorar la realidad de la rápida penetración de esta tecnología sin evaluar las ventajas que puede aportar a nuestro negocio.
Una empresa que quiera incorporarse al mundo de la movilidad debe, primero, responderse a una pregunta muy sencilla: ¿Qué quiero conseguir con una aplicación móvil?
Desde un punto de vista general, podemos agrupar las respuestas a la cuestión anterior en tres categorías:
· Los que quieren aplicar movilidad a algún proceso de negocio para optimizarlo, mejorarlo y ampliar la capacidad de control.
· Los que quieren aplicar movilidad en su relación con el cliente final para mantenerle informado sobre las operaciones que le afectan.
· Los que ven una aplicación móvil como un sitio más donde contar a sus potenciales clientes quiénes son, qué hacen o por qué deberían contratar/comprar sus servicios/productos.
En nuestra opinión las empresas cuya respuesta se sitúa en el tercer apartado no deben abordar el desarrollo de una aplicación móvil. De hecho, hacerlo puede ser contraproducente, ya que los usuarios considerarán que “es una aplicación que no vale para nada”. Para conocer una empresa, saber qué hace o cuáles son las ventajas de trabajar con ella está su página web y ésta debe estar adaptada para su visualización en tablets y teléfonos.
En este documento nos centraremos en los dos primeros casos: aquellas situaciones en las que se desea aplicar movilidad a los procesos de la empresa para transformarlos, y aquellas en que se desea ofrecer un valor añadido al cliente aportándole información actualizada sobre las operaciones y procesos que le afectan.
Nuestro objetivo es facilitar una guía práctica en la que se recojan los distintos pasos y decisiones que debería dar una empresa para planificar la implantación de un sistema de movilidad minimizando los riesgos y acotando el proyecto a un coste y plazo determinados.
Iremos desgranando las diferentes fases de planificación por las que, en base a nuestra experiencia, debería pasar cualquier proyecto, incidiendo en las posibilidades que existen en cada caso, y analizando sus ventajas y desventajas.
Si ejecutamos los pasos indicados de forma cuidadosa, estaremos preparados para buscar una plataforma o un proveedor de movilidad e iniciar nuestro proyecto con ciertas garantías de éxito.
Tras este documento, planeamos publicar otros dos, el primero como guía de los pasos a tener en cuenta en la búsqueda de proveedor y durante el desarrollo del proyecto, y el segundo para analizar lo que hay que tener en cuenta durante la fase de implantación y una vez que ya tenemos el proyecto funcionando.
¿QUÉ NECESITO MOVILIZAR?
Antes de tomar la decisión de iniciar un proyecto de movilidad debemos preguntarnos qué procesos de nuestra organización son susceptibles de transformarse a través de la movilidad y, sobre estos, qué cuestiones son las más relevantes.
De entre todas las actividades que tienen lugar en una empresa, las principales candidatas para aplicar movilidad son aquellas que se desarrollan total o parcialmente fuera de la oficina (“en campo”).
Dotar de una aplicación móvil a un dependiente de una tienda parece que, a priori, tendrá un impacto bajo en su actividad (que fundamentalmente se basa en la atención al cliente y la gestión de la caja)1. Algo parecido ocurre con las tareas administrativas o contables: parece que una App no va a mejorar como hacen su trabajo.
Sin embargo, si pensamos en un repartidor, un técnico de mantenimiento o un comercial, podemos intuir que dotarles de una aplicación móvil que les indique dónde deben ir, qué tienen que hacer, o permitirles reportar su actividad directamente en el teléfono (evitando el papel), realmente puede tener valor para su trabajo.
Además, debemos distinguir entre aquellas actividades que son completamente internas y aquellas que tienen relación con el cliente.
Un supervisor que visita distintos puntos de trabajo para analizar y reportar la actividad en ellos, o un técnico que mantiene distintos activos propios de la empresa, son buenos ejemplos de actividades internas que se desarrollan en campo. Sin embargo, si pensamos en la actividad de un técnico que repara activos para un tercero, vemos que aparece un nuevo actor relevante: el cliente final al que se le presta el servicio.
En este caso podríamos pensar simplemente en dotar al técnico de una aplicación para indicarle dónde debe ir y qué tiene que hacer, para que nos informe del estado de la orden de trabajo (si ha finalizado, si le falta material, si debe volver otro día…). En este caso seguiríamos hablando de una aplicación interna.
Ahora bien, ¿y si permitimos que el cliente forme parte del proceso? Por ejemplo, le permitimos que nos notifique la incidencia desde una App (pudiendo enviarnos datos del electrodoméstico como su marca, modelo, año, fotos, etc.), o le mantenemos informado respecto al técnico que va a atenderle (incluso con una foto para demostrar una atención más personal) y por dónde va, para que no tenga que estar esperando, o le permitimos responder una encuesta al final de la incidencia, o… En este caso habremos dado un paso más. Habremos transformado digitalmente nuestro proceso posicionando al cliente en el centro del mismo.
Por último, debemos tener en cuenta que movilizar un proceso es mucho más que desarrollar una aplicación móvil. Para que una App funcione debe contar con una serie de sistemas dentro de la empresa que permitan su funcionamiento:
· Facilitándole los datos necesarios para trabajar (en nuestro ejemplo del técnico de reparación dándole las órdenes de trabajo).
· Ofreciendo herramientas a los administrativos y supervisores de la empresa para que gestionen la operativa de forma eficiente (en nuestro ejemplo: facilidades para repartir los trabajos entre los técnicos de forma eficiente, avisos en caso de retraso, visualización del estado de cada servicio, etc.).
· Permitiendo que la información generada pase a los sistemas de la compañía para automatizar otros procesos (en nuestro ejemplo cuando el técnico en campo “cerrase” la orden de trabajo podría desencadenarse automáticamente la facturación).
Esto quiere decir que no sólo debemos preocuparnos por el desarrollo de la App, sino también de los diferentes sistemas y componentes de software que le tendrán que dar cobertura.
1/ Este ejemplo, que se ha incorporado por claridad, probablemente no sea demasiado bueno ya que, gracias a su bajo coste, sí que es habitual ver a dependientes (sobre todo en grandes cadenas) usar un teléfono para algunas tareas como el control de inventarios en la tienda o el envío de informes.
UNA APLICACIÓN MÓVIL PARA USO INTERNO
Como decíamos antes, para interesarnos en el desarrollo de una App para nuestra empresa lo primero que debemos analizar es, si contamos con personal que realiza su trabajo fuera de la oficina (o realizamos actividades fuera de la oficina, aunque las realicen terceros subcontratados).
Sobre estos empleados y sus actividades, debemos preguntarnos:
1. ¿Sabemos, en un momento determinado, dónde está o qué está haciendo cada uno de ellos?
2. ¿Cuándo nos enteramos del resultado de su trabajo?
3. ¿Cómo les comunicamos cambios de planes o nuevas órdenes de trabajo?
4. ¿Sabemos si están haciendo cada tarea de la forma más eficiente posible?
5. ¿Sabemos si se están cumpliendo todas las tareas en tiempo y forma?
Comparemos ahora la respuesta con aquellas actividades que se desarrollan en la oficina. Está claro que las actividades desplazadas presentan un margen de mejora importante porque, en muchos casos, están fuera del sistema de información.
Ese es, precisamente, el principal objetivo que perseguimos con la movilización de un proceso de negocio interno: dotarnos de un sistema que dé soporte a la actividad de campo (igual que en el departamento de Contabilidad tienen su propia aplicación, operaciones la suya, producción la suya, etc.).
El carácter intrínsecamente privado de un sistema de movilidad interno nos debe permitir una gran agilidad en la implantación del mismo, dado que los usuarios seremos nosotros y nuestra gente, podemos permitirnos movilizar la actividad parcialmente y empezar a trabajar cuanto antes. No hace falta desarrollar el proyecto en su totalidad, con cada una de sus particularidades, sino hacer funcionales los casos más relevantes.
En la movilidad, como en el resto de los sistemas, se suele cumplir el principio de Pareto2: el 80% de la actividad se refleja en el sistema con un 20% del esfuerzo. El 80% del esfuerzo restante se suele utilizar para incorporar “particularidades” que den cobertura al otro 20% de la complejidad. Ahora bien, la movilidad suele contar con una ventaja importante: normalmente se parte de un escenario donde no se está usando ninguna tecnología en el proceso (o sólo el papel) por lo que la cobertura de un pequeño porcentaje de los casos reales de actividad ya supone un ahorro.
Aquí radica la principal diferencia entre un proyecto interno y uno externo: en que no es necesario esperar a tenerlo todo reflejado en el sistema, ni es necesario pasar procesos de pruebas complejos o pensar la usabilidad al más mínimo detalle. Al fin y al cabo, los usuarios son nuestros empleados y serán más compresivos ante funcionalidades incompletas. Utilizarán un universo “acotado” de terminales3 y podremos formarles.
2/ https://es.wikipedia.org/wiki/Diagrama_de_Pareto
3/ Uno de los aspectos que más complican la calidad de un sistema móvil es la enorme cantidad de marcas y modelos de teléfonos móviles, así como de versiones de SSOO, que existen en el mercado. Asegurar que una aplicación funcionará en cualquier teléfono, de cualquier año, o con cualquier SSOO es una tarea que requiere de decenas de horas de pruebas. En una aplicación interna nuestro universo de técnicos seguramente tendrá tres o cuatro modelos, siendo mucho menos costoso garantizar su funcionamiento en ellos (siendo técnicos de campo, y teniendo en cuenta el coste de los terminales, lo más probable es que incluso pueda evitarse hacer la App en iOS para Apple).
UNA APLICACIÓN MÓVIL PARA MIS CLIENTES
Una forma de dar valor a nuestro negocio es mejorar la imagen que el cliente tiene de nosotros, incluyéndolo como parte activa de los procesos, y mejorando la comunicación con él. Esto se logra con una aplicación móvil para los clientes. Que sirve, entre otras funciones para:
· Mantenerlos informados del estado de su servicio, en tiempo real y de forma exacta (por ejemplo, decirle: “llegará mañana a las 10:30 h.” frente a: “llegará mañana”, permite reducir sus ventanas de espera y el cliente lo percibe como un mejor servicio).
· Hacerlos sentirse importantes y parte del proceso del que son objeto, permitiéndoles:
– Comunicar su interés.
– Gestionar incidencias.
– Valorar nuestros servicios.
· En definitiva, poniéndoles en el centro de nuestros procesos de negocio.
En este caso, los retos a los que se enfrenta la aplicación móvil son mucho mayores que los descritos en el apartado anterior.
En primer lugar, es importante dar una cobertura funcional completa del proceso, que no deje a clientes o actividades fuera de la aplicación. Estas carencias serán percibidas por nuestros clientes, que no tendrán piedad a lo hora de valorarnos negativamente.
Un cliente final no es permeable a errores, y no podemos formarle en el uso de la aplicación, ni dejarle fuera del uso de la misma por alguna particularidad. El esfuerzo realizado, o la buena voluntad para darle un nuevo canal de comunicación, les importan poco a nuestros clientes. Si la App no cubre sus expectativas, obtendremos una valoración en consecuencia.
Por todo ello, en las aplicaciones móviles externas hay que prestar mucha más atención a los criterios de calidad. Deben funcionar rápido y bien, ser fáciles de usar, con un diseño estudiado y universalidad (debe invertirse mucho más tiempo en pruebas).
Es por ello que son proyectos que requieren de más tiempo y dinero que los internos. Ahora bien, su capacidad de transformación e impacto en la actividad puede ser muchísimo mayor.
Aunque ya se ha comentado anteriormente, no está de más recordar que la movilización de un proceso externo puede (y de hecho debe) iniciarse como la movilización de un proceso interno. Esto permitirá que, llegado el momento, el cliente acceda a un escenario en que sus prestadores de servicio están acostumbrados a trabajar en movilidad, lo que aumentará la calidad y reducirá los márgenes de error.
DIFERENCIAS ENTRE UNA APLICACIÓN PARA EMPLEADOS Y UNA APLICACIÓN PARA CLIENTES
El desarrollo de una aplicación externa, frente a una interna, tiene enfoques diferentes, de modo que antes de plantearse seguir adelante es importante interiorizar algunos conceptos (especialmente si ya tenemos experiencia con aplicaciones o software del otro tipo):
· Cuando se piensa en una aplicación externa la estética y el diseño son fundamentales. Hay que transmitir una imagen y sensación de calidad en todas las funciones.
· En una aplicación interna podemos darnos el lujo de formar a los usuarios y abordar un proceso de gestión del cambio en el que, con el debido acompañamiento, los empleados de la empresa se involucren en el proyecto.
En una aplicación externa debemos contar con que ningún cliente se va a leer un manual o realizar esfuerzo alguno para aprender a usar nuestra aplicación, por lo que es fundamental maximizar la sencillez y la usabilidad.
· En una aplicación externa el número de funcionalidades debe ser acotado para que el cliente no se pierda en lo accesorio. Además, estas funciones deben cubrir toda la casuística y estar hechas “a prueba de bomba” (un fallo no sólo puede significar la pérdida de un cliente, sino una crítica pública que afecte a nuestra reputación).
En una aplicación para uso interno lo importante es que se consigan los aumentos en eficiencia proyectados y, por tanto, se puede ser más permeable en cuanto a la cobertura funcional.
· A la hora de definir los si es una aplicación para el cliente, debemos pensar primero en sus necesidades y luego, en las de la empresa. Muchas empresas caen en el error de presentar aplicaciones para que “el cliente haga algo” que puede redundar en una eficiencia para ellos, pero sin pensar en si al cliente le interesa hacer ese algo (por ejemplo, plantear una APP para que un cliente haga una encuesta de servicio).
Por el contrario, ofrecer una función que quizá no nos importe, o aporte eficiencia, pero resulte de interés para el cliente puede convertirnos en un imprescindible.
Por ejemplo, si somos una empresa de seguros de coches, el cliente que espera una grúa agradecerá sobremanera poder ver la ubicación de la que viene a recogerle o su hora estimada de llegada. Si en vez de eso le pedimos rellenar encuestas sobre sus necesidades de aseguramiento o calidad del servicio nuestra aplicación no durará mucho en su teléfono.
Por último, debemos pensar (no nos cansaremos de repetirlo) que ambos modelos, interno y externo, son compatibles. De hecho, muchas aplicaciones externas empiezan como internas y, una vez madurado el proceso, empiezan a ofrecer servicio al cliente.
UN PASO MÁS. NUEVOS MODELOS DE NEGOCIO GRACIAS A LA MOVILIDAD
El móvil lleva años liderando la transformación digital de las empresas4, pero esta transformación no se limita a mejorar el servicio del cliente o la eficiencia de nuestros procesos internos. También nos ofrece un mundo de nuevas oportunidades de negocio, y nuevos modelos operativos, que pueden transformar, de forma disruptiva, la realidad de nuestro negocio.
El ejemplo más importante en este modelo de servicio es el de las plataformas de transporte UBER, CABIFY o GRAB. En su modelo de negocio se suponía que la clave de su servicio era la de permitir a coches particulares realizar servicios de transporte público de viajeros como si de un Taxi se tratase.
En realidad, estas aplicaciones han “arrasado” en el mercado por la experiencia del usuario (al que le importa poco que el coche que le recoge sea blanco, negro o azul). Las claves de estas aplicaciones están en que:
· Utilizan la tecnología para fijar el precio antes de pedir el servicio. Si el cliente está seguro de cuánto va a pagar se siente mucho más confortable que ante la incertidumbre del taxi.
· Permiten pedir el transporte desde el teléfono, de forma directa. Rápido y fácil, sin llamar a nadie, sin estar a la espera.
· Se garantiza un nivel de servicio de limpieza, puntualidad, educación, etc. (a través de encuestas se va cribando a los conductores que no cumplan unos estándares mínimos).
· Le ofrecen al cliente total seguridad: sabe quién es el conductor y la matrícula del coche que va a buscarle, sabe que es una persona honrada, y sabe que va a pagarle desde la aplicación de forma rápida y cómoda (no saco dinero, no saco tarjeta… evito riesgos).
Esas cuatro claves han sido suficientes para transformar un sector, que también se va adaptando, presentando aplicaciones con las mismas funciones que las indicadas (MyTaxi por ejemplo).
Por su parte, las aplicaciones internas pueden producir eficiencias, en algunos procesos de tal magnitud que terminen desplazando a la competencia.
En todo caso estos procesos de disrupción en los que se desplaza a la competencia y se “arrasa” el mercado requieren tiempo y un modelo tecnológico maduro que puede desarrollarse paso a paso. Empezar por movilizar un proceso interno no sólo tiene impacto en el coste de ese proceso, sino que empieza a transformarse la forma en la que nos enfrentamos a los problemas.
2/ PRIMEROS PASOS PARA IMPLANTAR UN PROYECTO DE MOVILIDAD
Incorporar movilidad a los procesos de una organización no difiere mucho de la implantación de cualquier otro sistema. Muchas de las reglas y criterios que se aplican en cualquier proceso de implantación de cualquier software son perfectamente válidos en el desarrollo de una App.
Como decíamos en el capítulo anterior, nuestro objetivo es elaborar una guía práctica para las empresas que desean implantar un sistema de movilidad en su empresa, pero, antes de empezar, hay una serie de consideraciones previas importantes a tener en cuenta:
1. Nuestro tamaño: Si somos una empresa pequeña, o pretendemos movilizar un proceso en el que trabaja poca gente, debemos recurrir, total o parcialmente, a productos comerciales que nos permitan aprovecharnos de la tecnología sin incurrir en costes desorbitados.
2. La naturaleza de la actividad a movilizar y, sobre todo, el papel que queremos que juegue el cliente final en ella. En otras palabras, si vamos a desarrollar un sistema interno o externo.
3. Si existe alguna estrategia natural de definición de fases. Como norma general, la complejidad es poco amiga de los sistemas. Cuanto más complejo es un proceso a movilizar (o más excepciones presenta), más posibilidades hay de que el proyecto se complique o, incluso, no salga bien. Siempre es una buena idea partir el proyecto en fases o subproyectos más pequeños que nos permitan gestionar la complejidad sin riesgo (especialmente si a las aplicaciones van a acceder clientes finales)5.
4. Un sistema móvil no es sólo la App, sino que, como decíamos antes, tiene un montón de componentes software, herramientas, funciones y elementos que no son móviles. Se trata de piezas de software albergadas en un servidor centralizado que también hay que desarrollar, implantar y mantener.
5. No reinventar la rueda. Como norma general, y salvo que sepamos muy bien lo que estamos haciendo, nuestra recomendación es la de evitar el desarrollo específico para nosotros o la elaboración de proyectos “llave en mano”.
El desarrollo de software es una actividad compleja que tiende a subestimarse tanto en plazo como en coste. Por lo tanto, si existe un producto comercial que cubra total o parcialmente nuestras necesidades, recomendamos su uso. Lo normal es que consigamos un sistema con algún desajuste funcional, pero mucho más económico y de mayor calidad que lo que podamos desarrollar en exclusiva.
En caso de carencias en el producto comercial es una buena idea completarlas, de forma específica, en nuestro proyecto, pero reduciendo estas tareas de desarrollo a cuestiones específicas y concretas.
Por último, creemos que, antes de empezar, es importante reflexionar sobre los objetivos que perseguimos. La movilidad es una buena alternativa para ahorrar costes, generar eficiencia o transformar los negocios, pero estas propuestas de valor deben aplicarse a nuestro negocio y nosotros debemos, de una forma fría y objetiva, determinar cuáles de ellas tienen sentido en nuestro caso.
Tener claros estos objetivos nos permitirá, en los primeros pasos, determinar la viabilidad del proyecto y, sobre todo, evitar lanzarlo si es irrealizable, o no tiene posibilidad de satisfacer nuestra necesidad (con la correspondiente pérdida de esfuerzo, dinero y reputación que ello conlleva).
Además, estos objetivos deben ser cuantificables para determinar si merece la pena seguir adelante con el proyecto una vez implantado o concluidas las primeras fases. Aunque parezca mentira, son incontables los casos en los que se implanta un sistema que no cumple las expectativas para las que fue desarrollado y, en lugar de cancelarlo, se empieza a gastar muchísimo más dinero del previsto en mejoras, ampliaciones y cambios funcionales que, normalmente, no resuelven el problema de fondo.
5/ En general se recomienda usar una aproximación MVP o Producto Mínimo Viable. Esto quiere decir que debemos definir el producto que menos funcionales posibles que tenga sentido implantar. A partir de ese producto inicial iremos evolucionando los sistemas, mientras están en uso, según nuestros objetivos finales.
ANÁLISIS DE REQUISITOS. LA IMPORTANCIA DE PENSAR ANTES DE ACTUAR
Uno de los mayores riesgos asociados a la implantación de un sistema es el no tener claro qué es lo que queremos. Tendemos a confundir la tecnología con un fin en sí mismo, cuando realmente es un medio que nos ayudará a conseguir un objetivo.
Pensar que un negocio, actividad o proceso mejorará por el mero hecho de aplicarle tecnología es absurdo. Peor aún, pensar que una actividad desorganizada en la que no existe procedimiento o proceso alguno se ordenará por el hecho de soportarla en un sistema es engañarnos a nosotros mismos.
Por ello, antes de empezar la implantación de cualquier sistema, antes incluso de buscar un proveedor que lo desarrolle, debemos invertir tiempo y esfuerzo en hacer un análisis detallado de nuestras necesidades.
Un análisis detallado no es un conjunto de ideas en un papel o una somera descripción de lo que queremos hacer. Un análisis detallado empieza con una descripción profunda de cómo trabajamos ahora (incluyendo todas las realidades del negocio, las excepciones, las tareas, los flujos operativos, los flujos de información, etc.) y termina con una descripción profunda de cómo querríamos trabajar una vez implantado el sistema.
Este análisis no tiene un sentido técnico sino funcional, operativo y práctico. Su objetivo no es decidir cómo se resolverá técnicamente nuestra necesidad, sino, identificarla.
Una metodología muy útil para realizar el análisis previo de un sistema (lo que se conoce como la identificación de requisitos) es la conocida como AS-IS/TO-BE. En ella se aborda la definición de requisitos de un sistema partiendo de un análisis de nuestros procesos de trabajo actuales (AS-IS), para incorporar luego una nueva definición de cómo será el proceso una vez terminada la implantación del sistema (TO-BE).
¿QUÉ TENEMOS? ANALIZA TU SITUACIÓN
Analizar cuál es nuestra situación actual con relación a una actividad, proceso o negocio es fundamental antes de decidirnos a aplicar tecnología o transformarlo. Este análisis sentará las bases de lo que debemos hacer para llegar al objetivo de cambio y, al mismo tiempo, nos permitirá identificar si las tareas a digitalizar están procedimentadas o no.
Si llegamos a la conclusión que nuestro proceso de trabajo no sigue ningún procedimiento seguramente sea una buena idea parar el proyecto y, antes, ordenar el cómo hacemos las cosas. Si no, nos encontraremos con algunos riesgos insalvables que encarecerán e incluso harán fracasar el proyecto (resistencia al cambio por los usuarios, necesidad de reflejar tantas excepciones como usuarios tengo, exceso de formación, etc.).
Es habitual que, llegados a este punto, muchas empresas decidan “crear” el proceso junto al sistema. El resultado en la mayoría de los casos es que la primera definición del procedimiento no es exacta o es incompleta. Si eso nos ocurre teniendo un sistema que lo soporta, implicará que cualquier cambio en el proceso supondrá también cambiar el sistema (multiplicando el coste).
De forma general para realizar un “AS-IS” completo hay que tener en cuenta las siguientes cuestiones:
· Debemos ser capaces de identificar en un diagrama todas las fases y actividades vinculadas al proceso o negocio que estamos describiendo.
Suelen utilizarse diagramas muy similares al incluido a continuación:
Lo importante en este caso no es dominar el lenguaje de los diagramas, sino ser capaces de describir cómo ocurre el proceso de negocio en el tiempo con todas sus particularidades (todas implica TODAS, hasta la más mínima excepción o el caso más extraño).
· También debemos describir qué personas están vinculadas a cada actividad. Es decir, quién hace qué dentro del proceso.
· Otro aspecto fundamental es incorporar los documentos asociados al proceso, especificando sus campos y reglas de completado. Las órdenes de trabajo, los partes de actividad, resúmenes, informes…. Nuevamente es importante que estén todos los detalles y condiciones particulares.
· Por último, no está de más referirnos a las leyes, normas y reglamentos relacionados con el proceso o a otros aspectos que condicionen la actividad por algún motivo (sociales, psicológicos, de imagen, etc.).
Finalmente, es una buena idea hacer un análisis DAFO de nuestro proceso (una vez descrito), identificando sus debilidades, fortalezas, amenazas y oportunidades.
¿QUÉ QUEREMOS? PIENSA EN LO QUE REALMENTE QUIERES ALCANZAR
Una vez que tenemos claro dónde estamos debemos empezar a pensar a dónde vamos. Se trata de utilizar las mismas herramientas y forma de trabajo indicadas en el ASIS pero para describir cómo querríamos trabajar en el futuro. Es decir, cómo queremos cambiar nuestra forma de trabajar.
Se trata de definir el nuevo modelo de negocio o de trabajo de forma independiente al sistema o las tecnologías particulares a utilizar. Se trata de ver cómo queremos mejorar sin restringirnos a las limitaciones de un software, una tecnología, el personal vinculado al proceso, las costumbres adquiridas, etc.
Para elaborar este modelo To-BE podemos trabajar con alguno de los siguientes enfoques (o con todos ellos a la vez).
1. El primero de ellos es utilizar las mejores prácticas existentes en la industria. Básicamente fijarnos en cómo trabaja nuestra competencia o cómo dicen los analistas que debería trabajarse en nuestro sector.
2. La segunda es analizar la opinión de todas las personas vinculadas al proceso. Es curioso ver cómo muchas veces se busca el consejo del experto “fuera” cuando “dentro” tenemos un montón de profesionales que conocen el negocio en profundidad y que, casi siempre, tienen grandísimas ideas y sugerencias.
3. Por último, es bueno escuchar a terceras partes vinculadas al proceso, especialmente si son clientes o proveedores.
Con todas estas ideas tendremos más que suficiente para plantear un nuevo proceso o forma de trabajo, en el que debemos identificar, para terminar con el análisis, las diferencias entre el AS-IS y el TO-BE (lo que se conoce como el GAP). Estas diferencias marcarán, por un lado, los elementos a resolver a través de la tecnología y, por otro, los cambios organizativos que debemos realizar para adaptarnos al nuevo proceso.
¿YA SABEMOS LO QUE QUEREMOS? ¿QUÉ OPCIONES TENEMOS?
Llegados a este punto, y recapitulando lo que hemos visto hasta ahora, deberíamos tener claro qué actividades o procesos de nuestra organización son objeto de movilización. También deberíamos saber, de éstos, cuáles son internos, cuáles externos, y cuáles tienen potencial para llegar a ser externos, pero deben empezar como internos.
Además, hemos analizado alguno de esos procesos o actividades con detalle especificando qué tenemos, qué queremos tener y qué cambios debemos aplicar en la organización para llegar al objetivo.
Por lo tanto, es el momento de evaluar si merece o no la pena seguir adelante. Es decir, si la inversión que vamos a realizar tiene un potencial de retorno lo suficientemente grande como para que sea interesante implantar un sistema de movilidad.
Para realizar esta evaluación debemos, en primer lugar, cuantificar el potencial que presenta la mejora del proceso en dos ámbitos:
1. Su capacidad de hacernos más eficientes. Es decir, de hacer más con menos.
2. Su capacidad de posicionarnos mejor en el mercado y, por lo tanto, de incrementar el volumen de ingresos.
En general el potencial de ahorro de la tecnología móvil está en torno al 10% del coste de un trabajador mientras que el posicionamiento tiene una dependencia muy alta con el tipo de actividad, sector y grado tecnológico de la empresa (aunque no es raro alcanzar cifras que oscilen entre el 5% y el 15%).
En todo caso, cada uno debe adaptar las cifras a su propia realidad identificando numéricamente, y con exactitud, los objetivos que persigue. Es importante ser realista y no buscar objetivos imposibles que puedan paralizar un proyecto que sí ofrezca ventajas.
No podemos dejar de repetir la importancia de hacer una cuantificación explícita y numérica. Puede que en algún caso sea complicado o que en otros debamos hacer suposiciones (recomendamos ponernos siempre en escenarios conservadores), pero sin una cifra potencial difícilmente podremos analizar los resultados del proyecto tras las primeras fases y, sobre todo, si es interesante seguir invirtiendo en él.
Tras esto debemos analizar cuánto nos va a costar el proyecto, y aquí es donde realmente empiezan a complicarse las cosas porque existen múltiples opciones que condicionarán el futuro de nuestro proyecto.
En general estas decisiones tienen ventajas, desventajas y, sobre todo, costes diferentes por lo que es importante analizarlas todas y dejarse aconsejar para no fallar.
1. Para comenzar, hay que decidir si vamos a abordar el desarrollo de un proyecto íntegro y específico para nosotros o si utilizaremos una aplicación comercial que cubra nuestras necesidades.
La primera opción se adaptará mejor a nuestras necesidades, pero será más cara y difícil de poner en marcha. Como norma general debemos elegir, si existe, una solución comercial que se adapte a nuestras propias necesidades.
Aunque tengamos que cambiar un poco nuestro “TO-BE”, siempre que la desviación no sea crítica, las ventajas de usar una solución comercial superan con creces al desarrollo de una solución a medida.
Incluso si existe alguna desviación importante debemos estudiar si ésta puede resolverse con algún desarrollo particular que nos permita utilizar el producto comercial.
Debemos tener en cuenta que, si nuestra organización no tiene un área propia de IT o no estamos acostumbrados a gestionar proyectos de software, correremos un riesgo importante lanzándonos al desarrollo de un proyecto propio. Tampoco tendrá sentido económico si en el proceso a movilizar hay menos de 50 personas desplazadas (siendo recomendable que sean 100 o más).
Se puede encontrar una guía bastante detallada de los costes y beneficios de un proyecto de movilidad según la opción elegida en el estudio “El ahorro de costes derivado de aplicar la tecnología móvil al trabajo de campo” publicado por NEO managing mobility en https://www.workandtrack.mobi/ahorro-costes-movil.
2. En caso de elegir desarrollar un proyecto íntegro y propio para nuestra organización debemos elegir con qué metodología queremos trabajar:
· Ciclo de Desarrollo en Cascada: Si estamos seguros de poder definir al detalle todas las funciones, campos y flujos de datos de las aplicaciones a desarrollar, lo más recomendable es seguir una metodología de desarrollo en cascada, donde se realice una definición funcional técnica, se realice el desarrollo, se pase por una fase de pruebas y se implante el sistema.
Que un desarrollo sea en cascada no supone que no puedan existir distintas fases de análisis, desarrollo, pruebas e implantación, pudiéndose abarcar un conjunto de funcionalidades diferente en cada fase, y por tanto derivar a fases futuras aquellas funcionalidades que no podamos definir claramente al inicio.
Esta metodología cuenta con muchas ventajas: nos permite acotar completamente los costes de cada fase antes de acometerla, se consigue el objetivo final más rápido y con menos coste, y nos obliga a pensar antes de actuar, aumentando la consistencia del sistema final. Ahora bien, cuenta con un problema básico: debemos tener claro al 100×100 cómo es la aplicación que necesitamos antes de empezar su desarrollo. Si no lo definimos bien, o nos equivocamos, los costes de los cambios son exponenciales.
· Desarrollo Ágil: Se trata de organizar el desarrollo en bloques de tiempo (normalmente de dos semanas) donde trabajan en conjunto los desarrolladores y los responsables del proyecto para ir construyendo una solución que realmente se ajuste a las necesidades.
La idea se basa en tener un producto mínimo viable en el menor tiempo posible y, desde ahí (una vez puesto en marcha), ir ampliándolo o cambiándolo en sprints (esos bloques de dos o tres semanas), tras cada uno de los cuales tendremos un producto mejorado en producción.
Si hemos seguido las indicaciones de este documento, ya deberíamos tener claros varios aspectos clave:
