viernes, 2 de septiembre de 2011

El momento adecuado para actualizar un ERP

La mayoría de empresas (por no decir todas) le es un interrogante ver el momento indicado para actualizar una herramienta administrativa tecnológica. Las personas encargadas de este tipo de decisiones muchas veces no tienen los indicadores adecuados y generan cambios apresurados o tardíos en sus herramientas, por eso hay que estar atentos al crecimiento, desarrollo y necesidades del proceso productivo de la empresa.

Sin embargo en la práctica esto no sucede, las empresas no atienden adecuadamente sus propias necesidades, dado que priorizan otras necesidades operativas o del día a día. Si se va a realizar esta clase de proyecto es importante que la persona encargada haga una adecuada planificación y evaluación de las mejoras que el proveedor introdujo a su producto y así podrá hacer el análisis de conveniencia de la actualización.

Si hablamos de tiempos en un proyecto de actualización de un ERP, se debería evaluar el funcionamiento a cinco años como mínimo, dado que la inversión, decisión, esfuerzo, implementación y estabilización demanda no menos de un año.

Los ERP están preparados para adaptarse a los cambios de una organización y como herramienta que es tiene mejoras tanto técnicas como funcionales, mientras que las empresas evolucionan, aunque más lento, porque requieren mayor tiempo de producción y afrontar el nivel de exigencia de los clientes, por lo tanto podríamos decir no es lo mismo una actualización de un ERP, con una evolución de una empresa.

Una actualización de un ERP facilitara tareas como la cobranza, pagos, gestión del inventario, productividad de vendedores, etc etc, proveyendo las necesidades de la empresa, y así sobrellevar su evolución.

Saludos.

miércoles, 8 de junio de 2011

ERP Clase mundial vs ERP local

Vamos a empezar este artículo distinguiendo entre lo que es un ERP y lo que es un sistema administrativo tradicional, hago esta acotación ya que solo vamos a hablar sobre sistemas ERP y porque es bueno tener en claro esta diferencia.
Los sistemas administrativos tradicionales colaboran con la documentación administrativa y la gestión básica del negocio (información de los estados de cuenta de los clientes y proveedores, facilidad en la facturación, información contable necesaria para cumplir con los requisitos legales e impositivos). Normalmente estos sistemas son desarrollados por casas de software o programadores. Esto implica que van resolviendo de forma atomizada o parcializada los aspectos administrativos básicos en forma más o menos sistemática pero en lo general es no sistemática, en otras palabras no cuenta con tantas funcionalidades ya que normalmente está compuesta por programas o módulos de contabilidad y facturación.
Los sistemas ERP funcionan como un solo sistema integrador del flujo de información de distintas áreas dentro de una empresa que a través de módulos centraliza toda la información generada en cada una de ellas automáticamente para compartirla en tiempo real. Normalmente la base de este tipo de sistemas es la contabilidad, todas las transacciones (involucren o no cuestiones monetarias directas) se registran en la contabilidad y tienen a su vez impacto en el resto de las operaciones e indicadores.
Ahora teniendo claro la diferencia entre estos 2 tipos de sistemas, procederemos con el objetivo de este artículo.
Los sistemas ERP locales son software desarrollados en cada país en particular, por casas de software o desarrolladores individuales. Para el desarrollo de estos sistemas por lo general se utilizan:
  • Mecanismos propios: por la experiencia, conocimiento propio de procesos y funcionamiento de tipos de empresas del país y a la vez los aspectos legales e impositivos y culturales.
  • Sistemas más o menos estandarizados: viendo el funcionamiento de otros sistemas ERP.
Es muy difícil que estos tipos de sistemas abarquen más de un país o región.
Los sistemas ERP de clase mundial son software que se distribuyen virtualmente en todo el mundo, implicando que su base es absolutamente universal, queriendo decir que abarca aspectos propios del ser humano y sus empresas y se adapta a cada país o región mediante las famosas LOCALIZACIONES (adaptaciones de carácter local como idioma, aspectos legales e impositivos y culturales, etc.). Para el logro de este objetivo, necesariamente deben cumplir varios requisitos, como:
  • Calidad
  • Adaptabilidad
  • Confiabilidad
  • Escalabilidad
  • Globalidad
Normalmente estas soluciones cuentan con miles de instalaciones a lo largo de todo el mundo y requieren una compleja red de distribuidores y desarrolladores para dar soporte general y local.
Ejemplos: Microsoft Dynamics, Oracle, SAP, Sun MicroSystem, PeopleSoft, JDE, etc.
Ventajas de los sistemas ERP locales
  • Menores inversiones iniciales y menor TCO de corto plazo.
  • Negociación directa del fabricante.
  • Rápida adaptación a los aspectos locales.
Ventajas de los sistemas ERP de clase mundial.

  • Consistentes con aspectos referentes a la globalización.
  • Orientadas a las políticas de calidad (global).
  • Capacitaciones y certificaciones con reconocimiento y alcance mundial.
  • Tienen asociadas metodologías de implementación.
  • Mejor ROI Y TCO.
  • Resuelven funcionalidades más complejas y en forma más consistente.
  • Mayor perspectiva de estabilidad en el futuro.
  • Cuentan con las famosas “mejores prácticas” (a nivel mundial).
  • Mejor adaptación a los cambios tecnológicos globales.
  • Ideales para empresas que crecen horizontal y/o vertical (mayor complejidad, comunicaciones, nuevas sucursales, tecnología, etc.).
  • Mayor soporte (partner, vendedor nivel local, vendedor nivel mundial).
Saludos.

miércoles, 18 de mayo de 2011

Los consultores de empresas no van al infierno

Sabido es que los consultores, por lo que hacen y son, van siempre al cielo. Murió un consultor y se fue a las puertas del cielo. San Pedro buscó en su archivo pero, últimamente, andaba un poco desorganizado y no lo encontró en el montón de papeles, así que le dijo: “Lo lamento, no estás en las listas”
De modo que el consultor, obediente, se fue a la puerta del infierno dónde, rápidamente, le dieron albergue y alojamiento.
Poco tiempo pasó y el consultor se cansó de padecer las miserias del infierno, así que se puso a diseñar nada más y nada menos que un proyecto ¡Qué raro! :)
Elaboró un Plan Anual de Trabajo, organizó un comité de dirección y otro de ejecución, realizó una Encuesta de Expectativas para el año 2011, creó un grupo de documentación, escribió una metodología de trabajo y manos a la obra: comenzó a realizar mejoras.
Con el paso del tiempo, los habitantes del infierno, preocupados por obtener mejor calidad de vida, obtuvieron diferentes certificaciones:
  • Procesos de calidad de alimentos
  • Presentación de planes de negocios
  • Diseño de estructuras matriciales
  • Implementación de software empresarial
  • Optimización de costos
  • Gestoría de cobranzas
  • Y otras
Incluso, se comunicó con otros consultores que respondieron a la Encuesta de Expectativas para el año 2011 y publicó los resultados aquí. Y más aún, le está ayudando a buscar software empresarial para administrar mejor el infierno.
Un día Dios llamó al diablo por teléfono y con tono de sospecha le preguntó: '¿Cómo están las cosas allá en el infierno?'
El diablo le contestó “¡Estamos 10 puntos!”. Y agregó “tenemos personal certificado en proceso de calidad, en planes de negocios, como diseñadores de estructuras empresarias, como implementadores de software de negocios, como gestores de cobranzas y otras más. ¡Hasta hemos recuperado cuotas atrasadas!”
Por favor toma nota de mi dirección de email por si algo se te ofrece algo o si necesitas una asesoría. Puedes escribirme a: eldiablofeliz@infierno.com
Dios estaba sorprendido. Después de muchos años en los que el infierno fue la suprema desorganización y miseria, de pronto algo había cambiado.
Dios sospechó que un factor externo había influido en el cambio del infierno y entonces preguntó:
“Dime una cosa diablo, ¿Acaso tienen ustedes en consultor allí?”
El diablo no dudó un instante la respuesta y con tono de orgullo le respondió: Si. Y gracias a su trabajo, además sabemos qué piensan el resto de los consultores para el año 2011.
Y Dios dijo: “¡Es un monumental y garrafal error. Nunca debió haber llegado allí un consultor! Los consultores siempre van al Cielo. Está escrito de esa forma. Así que, diablo, me debes enviar a ese consultor inmediatamente.”
“¡Ni loco, ni ebrio, ni dormido! Me gusta tener un consultor en esta organización y me quedaré con él eternamente”, respondió el diablo.
Y Dios le contestó furioso “¡Envíame ese consultor al cielo o te demandaré!”
El diablo, comenzó a reírse y tras una fuerte carcajada, le replicó a Dios “¿Ah, si? ¿Y de dónde sacarás un abogado si todos están aquí, en el infierno?”

Saludos.

martes, 17 de mayo de 2011

5 errores que lo usuarios de un ERP no deben cometer

Una parte fundamental de una implementación exitosa de software es la adopción del usuario final, ya que si éstos no son capaces de conocerlo, el software será percibido como inutilizable, complejo y por ende una solución incorrecta debido que no podría devolver el retorno de la inversión esperado.
A continuación se mostrará 5 errores comunes que el usuario final deberia evitar al momento de planear la eduacion de este tipo de sofware:
  1. Error: Cuando no se comprende que es cuestión de educación y no de capacitaciónCapacitar consiste en explicar y demostrar la manera en la quese debe realizar una actividad. Educar es explicar las razones por las cuales las actividades se llevan a cabo y la importancia que tiene en los procesos de negocio.
    Ej.: el usuario que ingresa órdenes de compra necesita entender cómo el ingreso de una orden en forma incorrecta puede afectar negativamente al área de ventas, fabricación,cuentas a pagar y la insatisfacción del cliente,proveedor.
  2. Error: No saber combinar el aprendizaje formal con el informalEl formal consiste en adquirir conocimientos en un ambiente estructurado (aula). El informal consiste en adquirir conocimientos en un ambiente desestructurado (reusltados de un trabajo). Brindar educación formal es fácil, pero la educación informal podría consistir en elementos tales como la ayuda sensible al contexto o los cursos insertados dentro del software.
  3. Error: Utilizar solo un medio educativoSi nos basamos en el concepto de que las personas aprenden de modos diferentes, entonces se tendría que utilizar una combinación de medios de aprendizaje, como leer, ver y realizar para poder aumentar la retención del conocimiento.
    Ej.: clases tutoriales a través de la web, guías del usuario o los recursos relacionados con las preguntas grcuentes para las consultas en el lugar de trabajo.
  4. Error: No tener un plan de educación a largo plazoSe debe tener en claro que la educación es un ciclo continuo. Es decir la educación no acaba con la implementación y la puesta en marcha, se debe tener en cuenta una serie de factores como los nuevos empleados, los cambios organizacionales (procesos y recursos humanos) y las actualizaciones del sistema. Todo esto nos lleva a tener un plan de eduacación a largo plazo.
  5. Error: Considerar que la educación es un gastoLa educación no es un gasto, es una INVERSION. Los negocios inteligentes reconocen que para darse cuenta del valor que se vislumbra en una inversión relacionada con el software empresarial, los usuarios tienen que utilizar el software de forma competente y sostener dicha capacidad a lo largo del tiempo.
Siempre es un riesgo no eduacar a los usuario de manera apropiada al momento de implementar un sistema ERP, ya que esto puede ocasionar a largo plazo pérdida de productividad o la sensación de que no estamos aprovechando nuestro sistema.

Saludos.

martes, 1 de febrero de 2011

Los 4 factores de éxito en un proyecto de TI - 3. Metodología 4. Recursos

  1. Metodología: Teniendo variables de presupuesto, tiempo y tecnología, es la hora de decidir que metodología de trabajo tendremos que usar, esto debido que debemos tener una forma de afrontar el proyecto adecuada para poder cumplir con las expectativas funcionales y de negocio esperadas.
    Hay que definir brevemente metodología, entendemos que son las reglas, políticas, técnicas y procedimientos para el seguimiento del desarrollo de un proyecto. Es importante mencionar algunos tipos de metodologías las tradicionales, ágiles y propietarias (No vamos a meternos más en este tema, ya que es muy extenso).
    Habiendo definido la metodología nos enfrentamos a la dependencia de los primeros 2 factores (negociación y tecnología) de la siguiente manera.
    La negociación de tiempo y presupuesto nos puede indicar el camino a seguir en la selección de la metodología. Es importante identificar qué tipo de metodología se va a utilizar. Si quisiéramos adoptar una metodología tradicional (RUP por ejemplo) es necesario tener el tiempo y presupuesto adecuado, es decir, estas implican un costo mayor en horas hombre en documentar, analizar y definir todos los pasos de dicha metodología, este tipo es recomendable en proyectos donde los equipos de trabajo son grandes y los consultores cuentan con diversos perfiles y niveles de conocimiento. Si quisiéramos adoptar una metodología ágil y/o propietaria (siempre y cuando estén orientadas al resultado y no al plan) (XP por ejemplo), estaríamos hablando de proyectos donde el presupuesto y tiempo son pequeños (o muy castigados en la negociación) en relación al alcance funcional del proyecto.
    Aunque la metodología no tiene una dependencia con la tecnología seleccionada, es necesario aclarar que ciertas tecnologías se adaptan mejor a ciertas metodologías de desarrollo, por decir los lenguaje orientados a objetos son más fácilmente modularizables y reciclables que la programación estructurada.
    Un punto importante por definir en este factor de éxito, es si la metodología es orientada al resultado o al plan. Se dice que las metodologías ágiles son orientadas al resultado, es decir, a software funcional, y no a actividades o tareas en cierto tiempo, para esto se necesita una administración de proyecto flexible, para lo cual entendemos que nuestro plan de trabajo original puede sufrir cambios positivos o negativos buscando siempre el resultado funcional. En el caso de metodologías orientadas al plan, son conocidas las metodologías tradicionales como RUP, donde existen tareas por desarrollar durante todas las etapas del proyecto, pero muchas de ellas no entregan funcionalidad del software, solo los requerimientos de control y documentación definidos por la metodología, estas regularmente no son tan flexibles por estructura, para lo cual se tienen que hacer renegociaciones intermedias si se detecta o requiere funcionalidad nueva no solicitada en fases anteriores.

    Recomendación
    La selección de la metodología de trabajo es un factor importante en la búsqueda de un proyecto de éxito, para lo cual la selección de la metodología debería ser de la siguiente manera.
    Debido a que tenemos dependencia directa o indirecta de los 2 factores iníciales que son la negociación y la tecnología, lo recomendable es seleccionar nuestra metodología de trabajo en base a lo siguiente:
    • Si el proyecto requiere un equipo de trabajo grande debido a las etapas y dimensiones del proyecto, el uso de una metodología tradicional es lo más recomendable, eso sí, el costo y tiempo deben ser proporcionales, en otro caso, nuestro proyecto antes de empezar será un proyecto con pocas probabilidades de éxito.
    • Si nuestro proyecto puede ser desarrollado con equipos pequeños de trabajo, lo recomendable es el uso de metodologías ágiles, ya que dichas metodologías están orientadas al resultado y no a las actividades (plan), pero para que nuestro proyecto tenga certidumbre de éxito requiere que además tenga una administración flexible, es decir el costo es menor a una metodología tradicional, pero el tiempo puede ser variable debido a la búsqueda del resultado final y no en base a una fecha de terminación donde no se considere lo inestimado.
  2. Recursos: El último factor son los recursos que estarán involucrados en el proyecto, es decir, las personas y sus respectivos perfiles de conocimientos y experiencia en el tipo de proyecto, metodología de trabajo y tecnología.
    La asignación de recursos a nuestro proyecto se puede dar de diferentes maneras, iniciamos por la dependencia con cada factor previamente visto.
    En la negociación se define las 2 variables principales de nuestro proyecto, que son el tiempo y el costo, esto determinara la cantidad de recursos que podremos disponer para nuestro proyecto, y más importante aún será el perfil y experiencia que se pueda costear con el presupuesto asignado. En estos casos la fórmula es sencilla, salvo que sea una estrategia comercial del proveedor (por ejemplo: ganar un cliente, abrir mercado, etc.):
    “el nivel y la cantidad de recursos asignados a nuestro proyecto será directamente proporcional al presupuesto de nuestro proyecto, independientemente del tiempo que tengamos para dicho proyecto”.Como vimos en los artículos previos, la selección de la tecnología + el presupuesto del proyecto, influirán positiva o negativamente en el perfil y experiencia de los recursos asignados, es decir, hay ciertas tecnologías donde la oferta y la demanda de dicho perfil técnico determinaran los costos de los recursos. Si la tecnología es de cierto nicho o muy especializada, esto generará una dependencia durante mucho tiempo de nuestro proveedor seleccionado, que posteriormente si acaso la tarifa inicial fue económica, ya existiendo la dependencia el proveedor podrá renegociar tarifas nuevas en etapas posteriores del proyecto.
    En la metodología seleccionada y su relación con los recursos es como sigue, para ciertas metodologías se requiere cierta cantidad y perfiles especiales de los recursos involucrados, es decir se determinan responsabilidades y roles especiales tanto como para administrar, controlar y desarrollar, para lo cual en muchos casos es difícil que un recurso pueda cubrir varias funciones, por lo tanto ciertas metodologías requieren diferentes perfiles de recursos durante las diferentes etapas del proyecto, por decir un ejemplo, Project Manager, Software Architect, Data Architect, DBA, Developer Senior, Developer Junior, Project Leader, Tester entre otros.
    RecomendaciónLa selección de los recursos deberá ser en función a los factores de negociación, tecnología y metodologías, es decir, los perfiles y experiencia de los recursos, deberán ser los adecuados a nuestras variables del proyecto, si por alguna razón los recursos no dominan la tecnología, ó no tenemos los recursos suficientes para cubrir el plan de trabajo en tiempo, ó asignamos juniors o practicantes (de manera arbitraria) para reducir costos, nuestro proyecto estará muy limitado en sus posibilidades de éxito. Un caso común es que algunas empresas prefieren tener una mayor cantidad de recursos juniors ó practicantes que reduzcan costos y por cantidad de recursos puedan tener el proyecto a tiempo, lamentablemente estos casos son difícilmente ejemplos de éxito, es posible que el proyecto se termine, pero la calidad dejará mucho que desear y en muchos casos el re-trabajo costará más que hacerlo bien a la primera, donde aplica el conocido refrán “lo barato, sale caro”.
Resumen General:

  1. NegociaciónEn este factor se determina las 2 variables principales de nuestro proyecto, el tiempo y el costo.
  2. TecnologíaEn este factor se determina sobre que plataforma tecnológica se desarrollará nuestro proyecto.
  3. MetodologíaLa selección de la metodología de desarrollo adecuada depende del tiempo, costo y tecnología seleccionada.
  4. RecursosEs importante medir el nivel del proyecto teniendo como base los anteriores factores para así poder asignar los recursos con las capacidades necesarias para afrontarlo.


domingo, 23 de enero de 2011

Los 4 factores de éxito en un proyecto de TI - 1. Negociación 2. Tecnología

  1. Negociación: El factor negociación es la parte base de un proyecto, desde aquí se podrá identificar rápidamente si tu proyecto tiene los argumentos para ser exitoso, o está en riesgo el alcance y las expectativas de ambas partes. Esta etapa la dividiremos en 2 partes:
  • Negociación interna (cliente)
  • Negociación externa (proveedor)
  • a) Negociación Interna: Este tipo de negociación suele ser la que define las directrices de todo lo    involucrado en el proyecto, donde se determina los 2 puntos claves de todo el proyecto, la duración pretendida y el presupuesto asignado. Regularmente esta negociación se da por un intermediario interno de TI con el usuario final que regularmente no conoce de TI. Para la duración, es posible que este abierta a negociación o que el usuario final espere un plan de trabajo del proveedor, pero el primer punto en contra del éxito de tu proyecto es el caso más común, el proyecto debe estar tal fecha, no importa cuando empieces, ni si están los requerimientos mínimos para empezar a la brevedad dicho proyecto.
    Para el presupuesto, este puede ser aprobado de la manera tradicional, consigue al menos 3 propuestas económicas y la que nos convenza en costo beneficio esa será la indicada,  lamentablemente el caso más común es seleccionar la propuesta más económica (no  necesariamente   la mejor propuesta en alcance o beneficios) y tomarla de base para negociar con los otros proveedores que pudieran tener una mejor propuesta integral, esto puede terminar en 2  escenarios, una guerra de precios entre los proveedores si el proyecto vale la pena, o que seleccionen la propuesta más económica, con las implicaciones que veremos en los otros factores de éxito. 
  • b) Negociación Externa: Esta negociación se da entre el intermediario con el usuario final y el proveedor (pudiendo ser una consultora o el propio departamento de TI de la empresa).
    Esta etapa es donde el proveedor analiza los requerimientos del proyecto y hace una estimación de costo y tiempo, por diferentes factores es posible que los mismos requerimientos difieran en precio y costo entre varios proveedores del servicio, es aquí donde las limitantes si es que hay de tiempo y presupuesto para el proyecto toman la mayor importancia.
    En un escenario sano, el decidir por la mejor propuesta en costo-beneficio-tiempo suele ser la más acertada, lamentablemente el caso más común, es que tomen la propuesta del proveedor que dijo 4 semanas cuando todos los demás al menos dijeron 8 y el costo sea en esa proporción o peor aún, con tarifas mucho más bajas.
    Al finalizar esta etapa, ya puede influir de manera positiva o negativa en los otros factores.
Recomendación
Para esta etapa es importante analizar detalladamente el costo-beneficio del proyecto, ponderarlo en valor de negocio y tomar la decisión en base a ello, si el proyecto está limitado por el tiempo desde antes de  empezar, está en riesgo el éxito del proyecto, así como un presupuesto limitado y no en valor del negocio será otro riesgo adicional. Si el proyecto no aporta un valor tangible y medible es necesario reconsiderar si debería de desarrollarse.
  1.  Tecnología:Este factor es el siguiente en la secuencia del camino al éxito de un proyecto de TI, haciéndonos una pregunta clave: ¿Qué tecnología hay que usar?.
    En primera instancia la selección de la tecnología puede ser por los siguientes factores:
  • a) Costo (definido en la negociación interna): El costo cuando es una limitante, puede hacer que la tecnología seleccionada dependa de ello, por lo cual puede ser una tecnología Open Source o una tecnología de renombre (donde las 2 son consideradas excelentes opciones, solo que hay que considerar el impacto en los otros factores).
  • b) Infraestructura o políticas de la empresa: La infraestructura o políticas de la empresa definen que tecnologías deberían usarse, muchas veces independientemente del tipo de proyecto.
  • c) Propuesta del proveedor seleccionado: El proveedor seleccionado puede hacer una recomendación de tecnología que va en función a su propuesta económica, esto en determinados momentos podrá marcar una pauta importante en si no es una tecnología “estándar” podrá generar dependencia por mucho tiempo con dicho proveedor.
Recomendación
La selección de la tecnología es el siguiente factor en importancia, ya que todo el esfuerzo de desarrollo se   hará sobre cierta plataforma tecnológica, para lo cual se debe considerar lo siguiente: si no es altamente  justificable no seleccionar una tecnología de cierto nicho de mercado, es decir, existen infinidad de tecnologías, pero según tu ubicación geográfica o cultura tecnológica de tu país es posible que sea difícil encontrar recursos de ciertos tipos de tecnología, para lo cual podrás generar una dependencia total con tu proveedor, además que si llegaras a encontrar apoyo en ese mismo nicho será mucho más caro que una tecnología “estándar”.
Aunque no es una regla escrita, si es claro que en las localidades y a nivel país, se adoptan afinidades con  ciertas tecnologías para lo cual es fácil conseguir apoyo para algunas, y para otras es necesario traer   consultores de otras localidades o países con los costos que eso requiere.
Por decir un ejemplo, en Perú, encontrar apoyo para aplicaciones .Net de Microsoft es mucho más fácil y
económico que encontrar el mismo apoyo para tecnologías como JAVA, lo cual resulta que un consultor  con conocimiento en JAVA sea más difícil de conseguir y obviamente más caro, esto no indica que una tecnología sea mejor que otra.

Saludos.

miércoles, 19 de enero de 2011

Los 4 factores de éxito en un proyecto de TI

Para empezar debemos tener en claro que se entiende por éxito en un proyecto de TI, así podremos estar alineados y entender mejor el documento.
El éxito en un proyecto de TI es fundamentalmente tener un proyecto a tiempo, con los cotos esperados por ambas partes (cliente/proveedor), satisfacer al cliente cumpliendo los objetivos, alcances, funcionalidad, servicio, por parte del proveedor que tenga la remuneración económica esperada, recomendaciones, oportunidades, prestigio, experiencia, etc. 
Habiendo definido lo que nos gustaría tener en un proyecto exitoso, ahora procederemos a definir qué es lo que se va a requerir para asegurar o tener un grado importante de certeza que sobreviviremos a todos los retos que implica un proyecto de TI.
Para muchas empresas (clientes/proveedores) definen el éxito de un proyecto en una buena administración del mismo, para esto podríamos mencionar el Project Management, que es sí es una guía o modelo que te ayuda a planear, organizar, dirigir y controlar, esto te puede ayudar a que tu proyecto tenga el fin esperado… pero no si les ha pasado que al transcurrir el proyecto te das cuenta que se está retrasando, Ahhh!!! Pero eso sí, todo bien controlado y notificado, cuando pasa esto, los costos se incrementan, comienzan las fricciones entre cliente-proveedor, que si alguna de las partes no cede, el proyecto terminará con un final inesperado, teniendo usuarios finales molestos, insatisfechos y/o teniendo que pagar un presupuesto que no se tenía contemplado para tratar de cumplir con las necesidades. Bien si te suena familiar el caso presentado, entonces debemos pones pautas, puntos en sí lo llamaremos factores, que debemos considerar antes de empezar un proyecto de TI, dando una mayor probabilidad que el proyecto será todo un éxito.
Vamos a mencionar a continuación 4 factores, donde podremos decir que son secuenciales y en la medida que avancemos mostraremos la dependencia de las acciones y decisiones de cada nivel con su respectivo nivel previo. Debemos mencionar que si alguno de los factores no cubre las bases esperadas, los factores siguientes (de abajo hacia arriba) tendrán que superar las expectativas que compensen las deficiencias de los anteriores, de lo contrario nuestro proyecto puede estar condenado al fracaso inclusive desde antes de iniciar el mismo.

En las siguientes entradas hablaremos a detalle sobre los 4 factores mencionados.
Saludos.

martes, 18 de enero de 2011

La fábula del pastor y el Líder de Proyectos


Paseaba un día un líder de proyectos por el campo tras años de estar pegado al monitor. Iba pensando en lo extraordinario del paisaje, la paz que se respiraba y lo lejos que estaba ahora de la reunión de “kick off”, cuando vió un pastor de ovejas con un pequeño rebaño. No más de cincuenta recursos eran los que el pastor gestionaba.
En ese preciso instante el modesto pastor vio al líder y tomó un trago de su botella de mezcal. El pastor levantó la cabeza, miró a nuestro líder de proyecto y le ofreció un trago. El líder tomó la botella, le dió un trago que le supo bastante fuerte y se sentó junto al pastor. Y ya se sabe, un buen mezcal puede tener efectos alucinógenos. Sobre todo si no se ha probado en años… y no sale del supermercado más próximo.
Así que embriagado por el sabor, el líder de proyecto no pudo evitar decir: “señor pastor, lo suyo sí que es vida”. El pastor le miró, sin decir nada. “Todo el día dedicado a usted mismo, con sus fieles recursos que nunca se oponen a su voluntad, que saben lo que deben hacer sin que nadie se los diga, que no están todo el día exigiendo y pensando en irse a su hora a casa. Lo que daría yo por estar en su situación…” continuó el jefe.
El pastor le miró y con la simpleza que sólo da la verdadera sabiduría dijo: “no sabe usted de lo que habla, amigo”. Y tiró un largo trago de la botella. El jefe de proyecto no se iba a amedrentar, así que repuso: “Usted si que no sabe nada de lo duro que es mi trabajo, seguro que yo cuidaría mejor de sus ovejas, que usted de mi equipo de desarrolladores”. El pastor le miró fijamente y dijo “hecho, escriba aquí la dirección de su empresa y avise que voy”.
Le tendió la botella al líder de proyectos, en un gesto que decía claramente que si bebía, el trato estaba cerrado. Y claro, el líder bebió mientras pensaba, “que diablos, aquí el que tiene las certificaciones soy yo”.
El pastor silbó a su perro y le dijo, “dentro de una semana vuelvo, mientras, obedece al jefe.”…
Le dió el petate y marchó a conocer a su nuevo rebaño. El líder de proyecto pensó: “bueno se trata de gestionar recursos ¿no? Llevo haciendo eso años. Seguro que las ovejas saben hacer mejor su trabajo que los desarrolladores. Tengo claro el objetivo, que den lana, y sólo necesito crear un plan y exigir su cumplimento”. Con un buen plan y mano férrea, seguro que lograba cumplir sus objetivos.
El líder respiró tranquilo cuando recordó que llevaba su PDA y que tenía Project y Excel versión súper mini. Todo estaba solucionado. Dedicó esa noche a trazar un plan. Todo estaba bajo control, él tenía “el plan”, 50 recursos de tipo oveja, a 50 kilos de lana por recurso, 2,500 kilos de lana. Un proyecto rentable sin duda…
Al día siguiente reunió al rebaño. “Tengo un plan que nos va a llevar a completar el proyecto de manera exitosa. Ya me he comprometido con el alcalde y comerciante de lana a entregarle 2500 kilos de la mejor lana en el plazo de dos meses. El alcalde me ha mostrado su plena confianza en que conmigo al frente, gestor de recursos experto, el proyecto va a ser todo un éxito.” Las ovejas no entendían nada. Ellas sabían que el alcalde solía preocuparse más por la leche que por la lana, pero quizás las cosas habían cambiado, que sabían ellas, meros recursos productores de ¿lana? ¿leche?... Las ovejas, no habían nunca producido tanta lana en tan poco tiempo, pero con un buen gestor al mando quizás se obrase el milagro.
Pasaron veinte días, y el líder de proyecto reunió de nuevo a las ovejas. “Queridas ovejas, vamos retrasados respecto mi plan. No dudo que harán lo necesario para asegurar la producción al ritmo necesario. Ya he hablado con el alcalde y le he dicho que no se preocupe, que incrementaremos nuestro esfuerzo bovino y recuperaremos el tiempo perdido”. Las ovejas no entendían nada y llegaron a la conclusión de que el líder no era un animal muy listo. Al fin y al cabo no sabían cómo hacer crecer la lana más rápido… y parecía que él tampoco.
Otros veinte días después, el líder de proyecto reunió de nuevo al rebaño. “Malditas ovejas. Les pedí un esfuerzo y no han hecho nada. Yo hice el plan y ustedes están haciendo que fracase. Si no se aplican, se van a ir a la *@#& calle. Y ya saben, la crisis que hay… puedo encontrar cincuenta como ustedes’. La ovejas, una vez más, no entendieron nada. Ya le habían dicho al jefe de proyecto que no las metiera en el corral por las noches, y que cambiarlas de prado no era bueno para su lana. Habían pensado que tal vez si se movían por el campo, como hacían con el pastor, la producción de lana mejoraría. También sugerían que el jefe las ordeñase, sabían que el alcalde siempre quería leche... “Estas ovejas, siempre quejándose de tonterías, ya sabía que no eran muy diferentes a los desarrolladores. Que sigan el plan y dejen de quejarse y pensar, para eso estoy yo. ¡No hay manera de hacer que trabajen!” había pensado el jefe de proyecto.
Veinte días después, el alcalde llegó y preguntó al jefe por su lana… el jefe sólo tenía 1,000 kilos, la ovejas resultaron no ser tan expertas como ponía en su curriculum, inaceptable… que podría haber hecho él… “No pasa nada jefe”, dijo el alcalde, “tendremos mucha leche entonces”. El jefe se puso rojo y dijo ¿leche? si en el contrato no decía nada de leche… El alcalde dijo, “No me importa lo que diga el contrato, lo de la leche se da por hecho, vaya fracaso del proyecto, no vas a ver un *@#& peso…”.
En eso llegó el pastor… seguro que él también se había equivocado… “¿Qué tal pastor? ¿Duro el trabajo?” dijo sarcástico. El pastor contestó, con su simpleza natural: “Todo ha ido sobre ruedas. Al fin y al cabo los desarrolladores son como ovejas, ¿no? Seguro que a ti también te ha ido bien. Los desarrolladores incluso me han regalado un GPS para que marque dónde comen mejor mis ovejas… ¡y dónde hay setas! Creo que me han tomado cariño”.
El líder no salía de su asombro. Los recursos eran agradecidos y todo. ¡Cuéntame que has hecho! dijo al pastor.
“Ha sido fácil, los desarrolladores son mucho más comunicativos que las ovejas y cuesta menos reunirlos. Además, pensé, no pueden ser muy diferentes que las ovejas, son individualistas y gregarios a la vez. Seguro que si cuido de ellos como hago con mis ovejas, obtendré los resultados esperados y a eso me he dedicado estas semanas”.
“Me pidieron que les consiguiese un servidor de 64 bits para no se qué pruebas de rendimiento y de compatibilidad. Yo no tenía ni idea de qué era eso, pero parecía importante para ellos, así que lo conseguí. ¿No busco los mejores pastos para mi ovejas? No es tan diferente…” El jefe de proyecto estaba atónito, ¿desde cuándo se logra algo de los recursos atendiendo a sus caprichos?…
“Un día, los desarrolladores dijeron que no lograban que el rendimiento fuese el adecuado, lo mejor era preguntar a un experto, dijeron. Así que eso hice, busqué un experto que les ayudara y les formara. ¿No llevo a mis ovejas al veterinario cuando tienen problemas?”. Ahora sí que el líder de proyecto no se lo podía creer, ¡formar a los recursos es caro! Y luego se van a la competencia en cuanto saben.
“Otro día los desarrolladores me contaron que no lograban avanzar. Eso me preocupó. ¿Se supone que los desarrolladores deben avanzar en la funcionalidad, es su lana y su leche, no? El problema es que los de ventas estaban continuamente exigiendo pequeñas modificaciones, visitas a clientes, que atendieran llamadas; parece que los lobos acechan, pensé yo. Así que puse un poco de orden y dejé claro que a mi rebaño no se le molesta”.
El pastor concluyo: “la verdad es que no he hecho mucho ¿no?. Los desarrolladores son como las ovejas, si dejas que hagan su trabajo y pones las condiciones para que lo hagan, al final puedes recoger los resultados”.
En eso despertó el líder de proyecto y pensó: “caramba, cómo pega el mezcal del pastor, vaya siesta y vaya sueño más raro”, mientras veía al pastor perderse por el horizonte con su rebaño.
Ya lo dijeron DeMarco y Lister en Peopleware; “el trabajo del gestor de proyectos no es hacer que la gente trabaje, sino construir el entorno en el que trabajar sea posible”.

Pequeñas empresas y Sistemas ERP - La Selección

Teniendo presente que en las 2 fases anteriores se describieron los procesos de investigación y evaluación, dándonos como resultado una idea clara sobre el tipo de sistema que va a satisfacer las necesidades de la organización y los proveedores que ofrecen dicha solución, ahora en esta tercera fase describiremos la selección del sistema que mejor satisface sus necesidades específicas.
Los principales pasos a realizar en la fase de selección son las actividades relacionadas con la creación de escenarios guías, basados en los requisitos empresariales más importantes:
  • Utilizar una petición de información (RFP) (incluyendo información de costo)
  • Invitar a los proveedores a visitar su empresa
  • Programar demostraciones y pruebas con los proveedores
  • Evaluar las estrategias de implementación de los proveedores
  • Realizar un análisis sobre el costo total de propiedad (TCO)
  • Identificar la solución idónea
  • Desarrollar un informe de auditoría para el proceso de selección
  • Obtener la aprobación de los ejecutivos
  • Notificar a los proveedores perdedores y al ganador
  • Realizar verificaciones sobre las referencias
  • Negociar el contrato
De los pasos mostrados anteriormente, vamos a ver 3 que se deben tratar con mucho cuidado para la selección:
  1. Demostraciones de los productos por los proveedores: El aspecto más importante durante las demostraciones de los proveedores es tomar control del proceso. Para lograrlo, deberá crear una guía con los procesos que usted quiere ver y así el proveedor podrá mostrarle paso a paso como maneja el sistema sus principales requisitos. Ello le dará control sobre la demostración y el proveedor tendrá que demostrar como cubre el sistema las funcionalidades que son más importantes para usted. Dependiendo de la complejidad de su empresa, prepárese para invertir una porción de tiempo significativa en las presentaciones de los proveedores.                                                                    Por supuesto, la guía para las demostraciones deberá incluir los procesos más importantes. Pregunte por detalles del sistema, solo cuando la funcionalidad que se está presentando es esencial para su empresa. La demostración es igualmente una oportunidad para evaluar los aspectos cualitativos de cada producto, como la facilidad de uso. Por otro lado, no olvide calificar el producto –idealmente en cada funcionalidad demostrada- de forma tal que usted podrá comparar los resultados al fin del proceso. Veamos un ejemplo de una guía típica para ver las funcionalidades de la entrada de órdenes: Demuestre por favor lo siguiente:
  1. Una vez concluida esta parte, recuerde que la demostración solo cubre las funcionalidades, de allí que debe tener en cuenta los factores técnicos para la solución, como por ejemplo los sistemas operacionales, soporte de la base de datos, modelo de entrega (instalado, por demanda, software como servicio, integración con otros sistemas (como los de contabilidad, relaciones con los clientes, etc.), administración de múltiples localidades, seguridad, gestión de los dispositivos de la interfaz y las herramientas de la aplicación (los programas que permiten administrar o desarrollar el software).
  2. Lista de finalistas: Antes de la revisión de las demostraciones de los productos usted probablemente tenía una lista de 10 o más proveedores quienes afirmaban que sus productos podían realizar la mayoría de las tareas necesarias para su compañía. Si se ha realizado apropiadamente, las demostraciones y los criterios técnicos mencionados con anterioridad deberán reducir la lista a no más de tres o cinco proveedores.                                                                                                       Existen otros factores que pueden acortar su lista aún más, y algunos de ellos están relacionados con la capacidad de entrega del proveedor:
  • Implementación: el producto puede ser muy bueno, pero si su implementación toma un año y usted los necesita funcionando en seis meses, el proveedor será descalificado. Además, si usted no está satisfecho con la metodología de implementación del proveedor o si las referencias son malas, deberá pensarlo más detenidamente antes de decidir trabajar con esa empresa.
  • Capacitación y apoyo post-implementación: si su empresa está ubicada en América del Norte y el proveedor solo tiene oficinas en Europa y Asia, puede ser difícil que este responda a sus peticiones y que no le preste buenos servicios de capacitación y soporte.
  • Precios competitivos: este aspecto puede tener una gran influencia en la selección de los proveedores finalistas. El mejor sistema en el mundo no será suficiente como para justificar un precio exorbitante, pero usted debe ser cuidadoso cuando el precio que ofrece un proveedor es demasiado bajo y debe estar seguro de comprender cuánto va usted a pagar una vez el proceso haya concluido.
  • Servicio de asesoría: la gestión de cambio, el desarrollo de los procesos empresariales, la auditoria post-implementación, pueden ser realizados por el proveedor o un tercero que tiene sociedad con el proveedor. Dependiendo que la cantidad de asesoría que necesita su empresa, este puede ser un factor importante cuando se está eligiendo entre varios proveedores que ofrecen funcionalidades similares.
  1. 3. El ganador: Después de haber incluido todos los tipos de criterios (funcionales, técnicos financieros, etc.), usted debe hallar un proveedor que pueda no solo ofrecerle la mejor solución de software para sus necesidades, pero que además pueda realizar la implementación a tiempo, que pueda arreglar los problemas del sistema, responder preguntas con prontitud y que además le pueda ayudar a redefinir sus procesos empresariales.                                                                                  Si al final del proceso aún tiene dudas entre varios productos, deberá revisar algunos de los pasos que realizó u observar más detalles sobre lo que es realmente importante y que no ha sido satisfactoriamente estudiado (ejemplo: usted necesita importar datos de otro sistema cada semana, usted realiza respaldos cada 12 horas, sus socios necesitan acceso a un portal de intercambio de información con su empresa, etc.). Pero aun cuando usted piensa que ha encontrado la mejor solución, hay algunas cosas que debe realizar para asegurarse:
  • Instale una versión demo del producto que los empleados puedan usar antes de que la nueva versión entre en funcionamiento, evitando poner en funcionamiento el nuevo sistema cuando aún se está utilizando el viejo.
  • Recoja los comentarios de los usuarios sobre los elementos que le faltan al sistema y los aspectos que pueden ser mejorados en el nuevo sistema e infórmelo al proveedor.
  • Mantenga un cronograma de los pasos necesarios en la implementación y tome acciones correctivas cuando no se realicen a tiempo aspectos importantes.
  • Asegure que todos los datos necesarios para funcionar apropiadamente son importados antes de pensar en poner en funcionamiento el sistema -en ocasiones, es mejor retrasar la puesta en marcha del sistema en lugar de arreglar problemas más tarde.
Conclusión
No hay sistemas buenos o malos, pero solo uno de ellos serán ideales para usted. Esta es la razón por la cual todas las fases descritas en esta serie de artículos son sumamente importantes para su investigación, evaluación y selección de la mejor solución para las necesidades de su empresa.
Con frecuencia, la selección de una solución ERP es un compromiso, pero usted debe asegurarse de no comprometer las funcionalidades o características de la solución que pueden generar un gran impacto sobre su empresa en el futuro y llevarle a perder dinero si la inversión en el sistema no genera los resultados esperados.
Y por último, recuerde que estas tres fases del proceso solo le darán buenos resultados cuando se utilizan en conjunto. Si alguna de ellas es tratada con ligereza, puede afectar el proceso y su resultado final (por ejemplo, el sistema seleccionado) puede no ser lo que usted buscaba.

Saludos.