En la primera parte de la serie, hablamos de cómo podemos llegar a desarrollar una dependencia poco saludable de nuestro proveedor y, sobre todo, de los problemas que esto puede acarrear para nuestra empresa.
Hoy veremos qué podemos hacer para evitar esa dependencia.
1. Mantener la propiedad de los conocimientos técnicos sobre los procesos y los sistemas, así como de los planes para su desarrollo
Si decides que no quieres preocuparte por la informática y le das instrucciones generales a tu proveedor de servicios informáticos, vas por el mejor camino hacia la dependencia. Lo que quizá te sorprenda es que este enfoque suele causar problemas al propio proveedor, ya que, al cabo de un tiempo, los requisitos del cliente empiezan a solaparse y a enredarse, y cumplir con los nuevos requisitos se convierte en un gran problema para el proveedor.
Para una empresa que quiera seguir siendo competitiva, es importante considerar las tecnologías de la información como una herramienta para respaldar, mejorar y evaluar sus procesos. No es difícil averiguar cómo hacerlo, ya que hoy en día contamos con suficientes metodologías y normas que nos permiten mantener una visión general de los procesos y llevar a cabo una planificación eficaz:
- Arquitectura empresarial: una forma de describir los objetivos de una organización; las formas en que se alcanzan dichos objetivos a través de los procesos de negocio; y cómo la tecnología puede respaldar estos procesos. Para obtener más información, consulte el artículo «No se quede estancado» debido a una arquitectura empresarial deficiente. Los dos enfoques más conocidos de la arquitectura empresarial se pueden encontrar en los sitios web de The Open Group y Zachmann.
- Descripción de procesos: las normas más conocidas y utilizadas son las elaboradas por el Open Management Group (www.omg.org). La descripción de los procesos según la especificación BPMN (Business Process Model and Notation) permite a la dirección de la empresa leer y documentar fácilmente los procesos que tienen lugar en su empresa.
- Documentación para el usuario: no tiene por qué ser un documento redactado por el proveedor y guardado en un cajón para que se llene de polvo. Una buena idea es grabar vídeos que muestren a los usuarios cómo utilizar la aplicación en su trabajo diario; de este modo, se simplifica la asistencia técnica y la formación de los nuevos usuarios. Los vídeos suelen durar solo unos minutos y describen todo lo que hay que saber para utilizar el sistema de forma eficaz. Por ejemplo, echa un vistazo a la guía para utilizar Yammer en un proyecto de investigación; o a la guía sobre cómo hacer un pedido en una tienda online.
Todas las normas y metodologías van acompañadas de una documentación exhaustiva y de materiales de estudio que describen cada ámbito con detalle. Según mi experiencia, merece la pena contratar a un especialista que seleccione los aspectos de la metodología que sean adecuados para una empresa concreta.
Si plasmas tus conocimientos técnicos de forma sistematizada, no solo dispondrás de una herramienta para debatir temas que conduzcan a la mejora de la empresa, sino que también tendrás la certeza de que encontrarás puntos en común con la gran mayoría de tus proveedores actuales y potenciales.
Si quieres cambiar algo en tus procesos y en el flujo de información, empieza por introducir cambios en la organización del trabajo, ya sea a nivel de modelo o mediante un proyecto piloto: comprueba si el cambio aportará los beneficios que esperas. A continuación, calcula los beneficios del cambio y los costes de su implementación. Si todo está como debe estar, empieza a modificar los sistemas; y si no, puedes detener la acción sin ningún problema. Cuando se confía esto por completo a un proveedor externo, pocas personas tienen el valor de detener un proyecto en el que ya se han invertido recursos.
2. Los datos deben ser tuyos en todo momento
Los datos están almacenados en las instalaciones de nuestro proveedor; ahora hemos tenido un desencuentro con ellos y nos han dicho que los datos son suyos... Por desgracia, esta situación no es tan inusual como podría pensarse. No ocurre a menudo con los proveedores de servicios en la nube y de alojamiento web, como suele pensarse, sino que suele darse más a menudo con los sistemas desarrollados a medida, en los que los datos se almacenan dentro de una «caja negra» totalmente controlada por el proveedor.
Esta es una forma tradicional de mantener al cliente bajo el control del proveedor. Por lo general, el problema puede resolverse de dos maneras: controlando directamente los datos o garantizando una forma fiable de obtenerlos en un formato utilizable.
Por ejemplo: un servicio para gestionar los contactos de correo electrónico que obtenemos al registrarnos en la página web de nuestro proveedor. La primera estrategia consiste en asegurarnos de que los datos se repliquen en nuestros propios sistemas; y la segunda, en descargar periódicamente la información almacenada en los sistemas del proveedor y guardarla en los nuestros «por si acaso».
Incluso en nuestro propio sistema, donde el almacenamiento de datos está bien documentado, la metodología para exportar datos a una tabla estándar, una base de datos o un archivo XML puede facilitar enormemente la integración de un nuevo sistema. Es importante establecer procedimientos para la extracción de datos, verificar que la exportación funcione y que el formato esté bien documentado, ya que el momento crítico en el que necesitamos recuperar los datos es precisamente el peor momento para descubrir que la exportación no funciona o que los datos perfectamente exportados están codificados en un formato con el que no podemos trabajar.
Es necesario verificar los requisitos anteriores al aceptar cualquier nueva funcionalidad o modificación de los sistemas por parte del proveedor.
3. Conservar los derechos de propiedad intelectual sobre las aplicaciones
La propiedad de las aplicaciones consiste en la propiedad del código fuente o del diseño de la aplicación. Si no tenemos control sobre el código fuente, corremos el riesgo de que, cuando queramos cambiar de proveedor, descubramos que el proveedor actual es propietario de una parte fundamental del código y no esté dispuesto a cederla de forma gratuita. Podemos evitarlo definiendo claramente la propiedad en el contrato, indicando que el código desarrollado como resultado de los cambios solicitados es de nuestra propiedad exclusiva, o que dichos cambios se crean bajo una licencia que nos permite utilizarlos y distribuirlos de forma gratuita.
Aunque hayamos garantizado la propiedad mediante contrato, esto no significa que el proveedor con el que estamos a punto de rescindir el contrato nos vaya a conceder acceso al código. Por este motivo, es muy recomendable que el sistema de control de código fuente, la wiki y otros documentos se almacenen con un tercero, y que se obligue al socio a guardar los datos en un lugar y en un momento concretos, de modo que podamos acceder a las versiones actuales.
4. Integración de sistemas en lugar de ampliación de funcionalidades
Las API (interfaces de programación de aplicaciones) de los servicios web son hoy en día una característica habitual en muchas aplicaciones comerciales y de código abierto. Esto significa que todas las características o funciones a disposición de los usuarios de las aplicaciones también pueden utilizarse entre diferentes sistemas y aplicaciones.
Al utilizar protocolos y estándares para definir esta interfaz, estos servicios constituyen un medio de comunicación y una plataforma unificados; así, una aplicación escrita en un lenguaje o en un sistema operativo es accesible para sistemas programados de forma completamente diferente. Los datos se transfieren en un formato común, como XML o JSON, y los códigos fuente de ambos sistemas siguen siendo totalmente independientes.
Hoy en día, cualquier usuario puede hacerse una idea de cómo funciona la integración de sistemas. Al fin y al cabo, todos utilizamos servicios de aplicaciones web que están integrados entre sí; por ejemplo, Google Calendar con Google Contacts y Gmail. Si decidimos empezar a utilizar un calendario diferente en lugar del actual, solo tenemos que conectarlo a los datos existentes. Este método de cambiar de sistema no es posible si tenemos nuestro propio sistema, que compramos originalmente solo para la contabilidad y al que, poco a poco, el proveedor fue añadiendo un módulo de CRM, un módulo de servicios, etc.
La misma lógica se aplica a la integración con los sistemas que ofrecen como servicio los proveedores de servicios en la nube (SaaS, Software as a Service). El uso de servicios web separa las aplicaciones individuales entre sí, lo que hace que todo el sistema sea más flexible y transparente. Por el contrario, los enlaces fijos entre los distintos módulos facilitan que el proveedor aumente nuestra dependencia de él, incrementan la complejidad del código y hacen que la flexibilidad del sistema se vea limitada por su parte menos flexible.
5. Intenta reducir al mínimo las modificaciones del sistema estándar
Intenta implementar el sistema requerido con el mínimo de modificaciones respecto a la implementación estándar. Por lo general, no serás el primer cliente del proveedor. Intenta aprovechar al máximo la experiencia que el proveedor ha adquirido con otros clientes durante la implementación. Probablemente te sorprenderá lo mucho más eficientes que pueden resultar algunos procesos, o que ciertos datos que antes pasábamos por alto se conviertan en nuestra ventaja competitiva.
Si necesitamos introducir cambios importantes en la funcionalidad de la aplicación, esto podría complicar considerablemente la transición a nuevas versiones en el futuro; además, cualquier transición supondrá un reto en lo que respecta al desarrollo y la implementación.
6. Recurre a varios proveedores
Intenta gestionar tú mismo todo el proceso de diseño, desarrollo, implementación y funcionamiento del sistema, y no lo dejes en manos del proveedor. Es recomendable separar a los analistas de negocio de los desarrolladores, por ejemplo. También es recomendable que el sistema sea probado por personal de pruebas ajeno al equipo de desarrollo. Así se trabajará con mayor eficiencia y las posibilidades de obtener un producto sin fallos serán mucho mayores. Si otra parte se encarga del funcionamiento (por ejemplo, un proveedor de servicios en la nube), asegúrate de que presionará a los desarrolladores para que entreguen un producto que minimice los problemas de funcionamiento del sistema.
7. Especificar en el contrato el procedimiento de rescisión, incluidas las sanciones aplicables al proveedor
¿Cómo se especifica en el contrato la rescisión de la colaboración? ¿Con un preaviso de tres meses, tras el cual se deja de pagar y el proveedor deja de prestar asistencia? Eso es totalmente insuficiente.
Es necesario especificar qué documentación y con qué nivel de detalle debe facilitarle el proveedor —o directamente al nuevo proveedor— durante el plazo de preaviso. Si ha obtenido los derechos de propiedad intelectual sobre el diseño, el código fuente y otras partes de la documentación mencionada en el punto 3, mucho mejor. Al formalizar un contrato con un proveedor, es recomendable consultar con las empresas que quedaron en segundo y tercer lugar qué necesitarán en caso de que tengan que hacerse cargo del desarrollo y el mantenimiento en lugar del adjudicatario.
8. Informar a los proveedores de los planes de desarrollo futuros
Trabaja en establecer una colaboración a largo plazo con tus proveedores. Si comentas con ellos regularmente tus planes de desarrollo y cuestiones estratégicas —y no solo los cambios actuales en la funcionalidad—, es posible que el proveedor te presente propuestas que permitan crear una arquitectura de sistema estable, eficiente y costo, no solo para tus necesidades actuales, sino también para las futuras. Para aclarar tus requisitos, puedes utilizar, por ejemplo, el método MuSCoW, que divide los requisitos en las siguientes categorías:
- Imprescindible – imprescindible
- Debería haber – debería haber
- Podría haberlo – estaría bien tenerlo
- No lo tendré esta vez – no hace falta tenerlo en este momento
9. Recaba ideas y opiniones de otras partes
No te quedes estancado; sigue las tendencias; busca los mejores enfoques y prácticas; y mantente al tanto de todo. Contrata a una empresa para obtener una tercera opinión: evaluarán tus decisiones tanto desde una perspectiva técnica como estratégica. No tiene por qué ser caro. Y ese asesoramiento merece la pena, ya que te ayudará a evitar errores. Por mi experiencia, conozco un caso en el que un proveedor obligó a un cliente a invertir varios millones de coronas en resolver un problema que él mismo había causado; y un consultor descubrió que la inversión no resolvería el problema en absoluto porque este radicaba en otra parte.
Un consultor puede ayudarte a definir tu estrategia, generar demanda, evaluar opciones y analizar las cosas desde un punto de vista inesperado. También puede ayudarte a auditar a tus proveedores y garantizar el mejor resultado posible para ti. Un consultor debe tener siempre presente que deseas mantener tu independencia respecto a un proveedor concreto y que reconoces el valor de tus conocimientos técnicos como ventaja competitiva.
La elección adecuada de los proveedores es una cuestión de gestión de riesgos
Creo que, tras leer este artículo, tendrás una idea más clara de cómo convertir a tus proveedores en socios de tu éxito y no convertirte en su vasallo. Para evitar situaciones desagradables, es necesario llevar a cabo una gestión del riesgo coherente y elegir soluciones que concilien las necesidades actuales con la flexibilidad futura. Si sigues los principios mencionados, te asegurarás de elegir correctamente a tus proveedores y los nuevos sistemas.
