Llegamos a ustedes gracias a:



Columnas de opinión

Cuando se exceden los costos en un proyecto de nube

Por: David Taber, CEO de SalesLogistix

[09/03/2017] Recientemente conduje una encuesta informal en algunas de las compañías de integración de nube y encontré algo bastante preocupante. Aparte de los proyectos rápidos, más del 70% de los proyectos de consultoría de nube que involucran a nuevos clientes resultaron en un costo extra del 10% u orden de cambio. Mientras más grande el proyecto, es más probable que se excedan los costos.

Puede culpar a los tontos de los consultores, a las malas estimaciones o a los clientes locos, pero culpar no sirve de nada. Algo anda mal aquí, y está generando bastante acidez a los clientes y a los proveedores.

En un artículo previo sobre las tendencias que hacen que el mercado de nube sea traicionero, mencioné que una causa principal de cualquier costo en exceso de la nube son las expectativas establecidas de manera errónea: Cuando los clientes creen que el cumplimiento de sus requerimientos será más sencillo de lo que es, y que debería costar menos de lo que costará. Sin importar lo significativa que pueda ser esa observación, no es particularmente procesable. Así que tomemos el siguiente paso para entender las especificaciones principales, y qué pasos podemos tomar.

Los cuatro jinetes del exceso de costos

En la mayoría de los proyectos de nube, muchas áreas están contenidas bien, y es poco probable que generen costos sorpresa significativos. Si establecer una función es meramente una cuestión de configurar un sistema, no puede haber muchas horas de trabajo involucradas.

¡Deberíamos ser muy afortunados!

Aquí tenemos las áreas de proyectos donde vemos costos sorpresa regularmente:

1. Integración/migración de datos

Esta bestia de doble cabeza puede involucrar algunas sorpresas serias, puesto que es imposible detectar muchos de los problemas hasta que se encuentra en medio de un pantano. Los problemas de costos escalan tanto por la cantidad de datos como por el número de fuentes de datos.

Incluso si los datos se ven superficialmente limpios, podría haber problemas de formato, valores inapropiados, semánticas sobrecargadas y ambigüedades de objeto-modelo que contribuyen a una migración o integración problemática. Si se necesita una integración continua, no podría percatarse tempranamente de que el adaptador punto-a-punto que propuso originalmente necesita ser reemplazado con un sistema middleware completo.

Estrategia de solución: Realice un análisis costo-beneficio real de la cantidad de datos que van a migrar y el número de fuentes que serán integradas, y desarrolle un modelo de costos que refleje la realidad. Empiece con las tareas de migración/integración/validación en el inicio del proyecto para que las sorpresas lleguen temprano. Espere que la migración y la integración puedan representar la parte más grande de su proyecto.

2. Código personalizado

Los clientes con frecuencia estipulan "sin código, solo funcionalidad innovadora como parte de su definición de proyecto, y en el segundo día del proyecto se descubren requerimientos que no pueden ser satisfechos de ninguna otra forma. Desafortunadamente, demasiados consultores están satisfechos con el código, así que incitan a que el cliente se incline hacia la tierra del código personalizado. Y el ambiente rico de codificación de la plataforma Salesforce.com (SFDC) hace que sea tentador tanto para la interfaz de usuario como para la lógica del negocio.

Por supuesto, el problema serán los costos de productividad del desarrollador y el costo de mantenimiento del código. Puede esperar que el código personalizado sea una función cuyo orden de magnitud sea al menos más costoso que la de configurar la funcionalidad estándar.

Estrategia de solución: En la medida de lo posible, utilice funciones de sistemas estándar y productos plug-in accesibles para cumplir con los requerimientos. Haga flexibles a los requerimientos para que éstos encajen con lo que tiene a su disposición. Empuje la codificación fuera de la entrega inicial si le es posible, de esta manera los codificadores trabajarán en una plataforma estable. Para componentes que deben ser construidos, insista en agilizar los procesos y las reglas del negocio que puedan causar explosiones de combinaciones (por ejemplo, el modelo de seguridad, configuraciones de orden, redes de distribución/socio).

3. Reportes realmente buenos

Los motores de reportes SDFC originales logran un buen balance entre energía y facilidad de uso, pero otorgan un rendimiento con la calidad de una hoja de cálculo. Si realmente quiere reportes buenos y bonitos, no tardará en estamparse contra una pared.

El sistema de reportes Wave de SFDC es más poderoso y más bonito, pero impulsar su poder de verdad requiere de la escritura de código de consulta. Para cosas aún más elegantes -con formatos buenos, diseños de páginas múltiples, y generación de documentos automáticos de oficina- se requiere de añadidos externos.

Pero como noté en el artículo previo sobre trabajo de diseño en proyectos de CRM, si es que tiene que ser bonito, va a ser bastante costoso -tanto para su instalación inicial como para la evolución futura de acuerdo a sus necesidades.

Estrategia de solución: Entienda y especifique con detalle cada variante -incluyendo formatos y ajustes específicos de usuario- de todos los reportes que necesitará antes de poner al sistema en oferta. Es mejor descubrir que realmente requiere más de 100 reportes, y no solo los 10 que había pensado. Si tiene un reporte en funcionamiento (por ejemplo, de Access o Crystal) que necesita que el sistema emule, proporciónele al proveedor un conjunto de muestras de datos de entrada y lo que sale del reporte, con anotaciones respecto a las condiciones de formato y excepciones.

4. Administración de proyecto & supervisión

¡Esto se trata de ustedes, líderes de proyectos y campeones ejecutivos! Las cosas que hacen contribuirán directamente al exceso en costos. Como discutí en el artículo sobre la administración de proyectos ágiles, la distancia y la demora son las enemigas de los proyectos eficientes y económicos.

Pero necesito añadir otros impedimentos que son aún más mortíferos: La indecisión y el descubrimiento (sin fin). El primero de estos obstáculos, la indecisión, es lo suficientemente mala debido a que causa demoras y una dirección errática, lo que conlleva directamente a trabajar de nuevo. Pero el segundo, cuyas marcas distintivas son descubrir que (1) los requerimientos realmente no fueron conocidos desde el inicio, (2) sus suposiciones respecto a cómo necesitaban funcionar las cosas estuvieron equivocadas, y (3) sus suposiciones respecto a cómo las funciones del nuevo sistema iban a funcionar estuvieron equivocadas, es la causa de que el alcance se frene. No puedo decirle cuántos proyectos grandes descubrieron más de la mitad de los requerimientos costosos después de que el descubrimiento formal se completó.

Estrategia de solución: Alargue la fase de descubrimiento, y cuando esté completa tenga un registro de salida para una función estricta y congelamiento de datos. Haga al equipo del proyecto lo más pequeño y cercano posible, y no contrate a más de una compañía consultora (para reducir conflictos). Trabaje para mejorar constantemente la confianza entre los miembros del equipo. Saque a las personas del equipo que se dediquen a buscar culpables. Mantenga a ejecutivos y contadores tan lejos del proyecto como le sea posible, y limite las reuniones de revisión grandes. Haga que la atención de todos se centre en el valor del negocio, y no en medidas abstractas o arbitrarias, tampoco en paneles de proyecto.

Por qué soy un fanático descarado de lo ágil

Actualmente me encuentro leyendo el libro "Estar Equivocado - Aventuras en el Margen del Error, después de haber terminado "Incorrecto! Por qué los expertos nos siguen fallando. Así que quizás esté un poco hastiado, pero sin duda me parece que el exceso de costos es el resultado de malas suposiciones, información fragmentaria, requerimientos incompletos y baja confianza.

Curiosamente, los excesos en los costos son mucho menos comunes para los proyectos de seguimiento, donde ambos lados han invertido el tiempo en desarrollar buenas suposiciones, un entendimiento sólido de los requisitos reales y una relación de confianza. Así que, para proyectos iniciales, nosotros -clientes y consultores- debemos detener la falsa certeza sobre nuestros proyectos.

La verdad es que realmente no lo sabemos, y no estamos dispuestos a gastar el tiempo y el dinero para ser lo suficientemente conocedores de todos los detalles menores de un nuevo proyecto. Nos apresuramos y conseguimos un presupuesto sin realmente conocer las implicaciones del proyecto. Y después descubrimos que existen demasiadas complicaciones en la trama después de que hemos alcanzado la mitad del camino en el proyecto. Para aquellos que esperan que las técnicas "híbridas ágiles vayan a resolver los problemas, no he podido ver mucha ayuda ahí.

En contraste, el enfoque ágil real admite que no sabemos, y simplemente abarca los entregables de manera dinámica para encajarlos dentro del presupuesto y el cronograma. El equipo descubre mientras avanza, da prioridades conforme avanza y se concentra en maximizar el valor del negocio en vez de centrarse en criterios arbitrarios (y posiblemente al azar). Cuando se aplica bien, el enfoque ágil hace que los encargados de supervisar el presupuesto estén felices (ellos pueden declarar "a tiempo, dentro del presupuesto) y consigue las cosas más importantes a los usuarios apenas concluye.

David Taber es el autor del libro de Prentice Hall, "Salesforce.com Secretos del Éxito, actualmente en su segunda edición, y es el CEO de SalesLogistix, una consultora certificada por Salesforce.com que se centra en la mejora de los procesos de negocios a través del uso de sistemas de CRM. Taber tiene más de 25 años de experiencia en tecnología de alto nivel, incluyendo 10 años en el rango de vicepresidente o posiciones más altas.