Guía de Soluciones

El Costo de los Proyectos de TI que Fallan

noreply@blogger.com (applicar) — Sun, 19 Sep 2010 19:00:00 +0000

A nivel mundial se presenta un alto porcentaje de falla en los proyectos de TI. Este fenómeno viene siendo estudiado por investigadores de diversos campos del conocimiento, prácticamente desde el momento en que las empresas empezaron a hacer uso de estas herramientas tecnológicas.

Dado que cada vez más, las TI se convierten en elementos primordiales para el buen desempeño de las organizaciones en el mundo, es importante conocer el costo de lo que representa en los países la falla o fracaso de los proyectos de TI.

Realizando búsquedas sobre la cuantificación de la falla en los proyectos de TI, encontré un post interesante en el blog de Michael Krigsman quien a su vez hace referencia a la entrada original publicada por Roger Sessions.

Robert Sessions, de forma empírica trata de establecer un cálculo rápido del costo de los proyectos de TI fallidos basándose en el PIB (Producto Interno Bruto) o PBI (Producto Bruto Interno). Las asunciones que hace Sessions para su cálculo y el resultado al que llega es el siguiente:

According to the World Technology and Services Alliance, countries spend, on average, 6.4% of the Gross Domestic Product (GDP) on Information Communications Technology, with 43% of this spent on hardware, software, and services. This means that, on average, 6.4 X .43 = 2.75 % of GDP is spent on hardware, software, and services. I will lump hardware, software, and services together under the banner of IT.
According to the 2009 U.S. Budget, 66% of all Federal IT dollars are invested in projects that are “at risk”. I assume this number is representative of the rest of the world.
A large number of these will eventually fail. I assume the failure rate of an “at risk” project is between 50% and 80%. For this analysis, I’ll take the average: 65%.
Every project failure incurs both direct costs (the cost of the IT investment itself) and indirect costs (the lost “opportunity” costs).
I assume that the ratio of indirect to direct costs is between 5:1 and 10:1. For this analysis, I’ll take the average: 7.5:1.
To find the predicted cost of annual IT failure, we then multiply these numbers together: .0275 (fraction of GDP on IT) X .66 (fraction of IT at risk) X .65 (failure rate of at risk) X 7.5 (indirect costs) = .089.
To predict the cost of IT failure on any country, multiply its GDP by .089.

Basado en lo anterior Sessions indica que el costo de los proyecto de TI en el mundo equivale a 6.2 trillones de dólares por año.

Por su parte Michael Krigsman indica que estos cálculos dependen ampliamente de las asunciones que hizo Sessions para determinar el factor que permite predecir el costo de la falla en los proyectos de TI. De acuerdo con Krigsman, las variables clave del cálculo que propone Sessions son:

Definición de falla
Índices de falla
La variación de estos índices por país

De acuerdo con el PMI, un proyecto se considera fallido si no satisface los requerimientos del cliente (alcance), excede el presupuesto y el tiempo programado y no cumple con los estándares de calidad requeridos.

El caso de los índices de falla no puede ser tomado como uniforme para todos los países del mundo ya que, aquellos países en vías de desarrollo presentarán índices de falla mayores que los países más desarrollados.

El 66% del presupuesto que usa Estados Unidos para sus proyectos en riesgo no puede ser usado como una cifra promedio para el cálculo global, ya que los países han adoptado y seguirán adoptando estrategias diferentes para sortear sus problemas. Es más, existen países que no destinan o destinan un porcentaje muy bajo de presupuesto para proyectos en riesgo.

En mi opinión, la estimación de Sessions es un buen estimado para tener una idea de lo que cuesta se ineficiente pero también es un indicador de que a pesar de los esfuerzos realizados por los investigadores, consultores, desarrolladores e implementadores de TI. El problema de cómo la organizaciones hacen uso de esta tecnología aún no está agotado y requiere de mayor estudio.

Este post también se puede encontrar en >>> http://ramirez-arias.blogspot.com/2009/10/el-costo-de-los-proyectos-de-ti-que.html

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

Los ERPs y la Tecnología

noreply@blogger.com (applicar) — Sun, 15 Aug 2010 17:11:00 +0000

Por: Mónica Leiva

Comienzo el artículo con una pregunta: ¿Están capacitadas las PYMES para asimilar las ventajas que puede tener una organización, cuando su Sistema de Gestión Empresarial (ERP; Enterprise Resource Planning) va de la mano con la tecnología?

Cuando en nuestra empresa decidimos construir un ERP (ERP; Enterprise Resource Planning), lo hicimos ponderando varias variables que correspondían a necesidades insatisfechas de otros sistemas actuales en el mercado; pero le quisimos dar especial énfasis en la tecnología ¿Por que? Porque “estamos convencidos que una empresa para mejorar la actual condicion competitiva, debe necesariamente estar acompañada de sistemas que crezcan acorde al desarrollo tecnológico”.

Entonces, cuando una empresa ofrece un producto debe hacerlo dando una visión superior a la necesidad actual del cliente, que puede ser quizás, centralizar la operatoria de sus depósitos distribuidos en varios puntos de venta. Es importante hacerle ver al cliente que, gracias a la tecnología, él puede consultar su stock desde cualquier lugar donde se encuentre, y puede no necesitar su PC conectada a la red. Que puede ir a un ciber y hasta puede ver los informes relevantes desde su teléfono celular. Que puede acortar los tiempos de carga de inventario ingresando la información a colectores de datos que luego se sincronizarán con la información del ERP.

Además, es necesario resaltar el valor de la información operativa, pero también es útil poder procesar esa información y transformala en datos ‘inteligentes’ para tomar decisiones. De esta manera, hasta sus vendedores podrán tomar los pedidos de sus clientes en forma on-line y siempre tendrán presente el stock comprometido.

Por último, la mayoría de los sistemas actuales se adaptan perfectamente a dichos cambios a medida que el usuario lo vaya necesitando, porque la ‘tecnología’ está presente desde su creación.

Sin embargo, al cliente, la mayoría de las veces, le parece descabellado o inaplicable a su negocio. Lo que sucede en estos casos es que esta "fórmula 1" que le ofrece el mercado actual de ERP es sumamente superior a lo que él necesita actualmente, y, finalmente, puede conseguir otro producto a muy bajo costo que le solucionará sus falencias actuales.

Y acá se produce la paradoja de que estamos contruyendo sistemas basados en las últimas tecnologías y los destinatarios de nuestros ERP no están maduros para afrontar los cambios que, en mi opinión, ya los están viviendo.

Todos sabemos que la tecnología se mueve a pasos agigantados y que necesariamente nuestros ERPs se deben ir adecuando a los nuevos procesos. Es por ello que las empresas debemos invertir en investigación y desarrollo.

La gran pregunta es: ¿De quién es la responsabilidad de esta inmadurez sobre tecnologías de la información? ¿Del cliente o de nuestra forma de comunicar y capacitar a las pasadas y nuevas generaciones? ¿Como alinear la estrategia de Tecnologías de Información (IT) con los objetivos de negocio del cliente?

Dejo abierto el debate para hablar sobre este tema en un próximo artículo...

Mónica Leiva es Project Leader en TEI S.A.

El artículo fue facilitado por Evaluando ERP, que es partner de información de APPLICAR.

Taller de Preparación para el Exámen de Certificación PMP

noreply@blogger.com (applicar) — Tue, 10 Aug 2010 01:30:00 +0000

Están todos invitados a este taller que estamos organizando. Aquellas personas que sean seguidores de la Guía de Soluciones se les hará un descuento del 20% sobre el costo del taller. Iniciamos este sábado 14 de Agosto, la fecha límite para inscribirse es el Miercoles 11 de Agosto. Para revisar mayores detalles pueden revisar el enlace adjunto AQUI. Esperamos contar con su participación.

Clasificación de Proyectos (4)

noreply@blogger.com (applicar) — Mon, 09 Aug 2010 01:22:00 +0000

Por: Jesús Ramírez

En esta entrega se explican los cuatro niveles de niveles de la dimensión de incertidumbre tecnológica en los proyectos. Estos niveles dependen del contenido del proyecto y son:

Tecnología Establecida.

Estos proyectos se fundamentan en tecnología bien establecida a la cual todos los involucrados tienen el mismo nivel de acceso.

Tecnología Mayormente Establecida.

También conocidos como proyectos de mediana tecnología, estos proyectos son similares a los anteriores pero involucran alguna nueva tecnología.

Tecnología Avanzada.

También conocidos como proyectos de alta tecnología, son aquellos proyectos en los que los componentes que lo integran son empleados en conjunto por primera vez sin embargo las tecnologías individuales ya existen.

Tecnología Altamente Avanzada.

También conocidos como de súper alta tecnología porque requieren de un desarrollo exploratorio previo y requieren de la incorporación de tecnología que se encuentra en desarrollo. Los proyectos de Investigación y Desarrollo caen en esta clasificación.

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

Cómo Convertir Leads en Contactos

noreply@blogger.com (applicar) — Sun, 27 Jun 2010 16:30:00 +0000

Share|

Por: Andrea Manna

Es común que una empresa adquiera un software CRM (Customer Relationship Management) para reemplazar sus apuntes manuales de seguimiento de contactos. Estos apuntes manuales pueden ser tanto cuadernos o agendas personales, carpetas o archivos en computadora con información de seguimiento, planillas Excel, etc. Cuando toda esta información los desborda, entonces se piensa en alguna solución para volcar toda esta información.

Normalmente se envía un correo a un posible contacto y esa información queda guardada en alguna bandeja del Outlook prolijamente clasificada. Luego enviamos algún presupuesto y guardamos el archivo Word o Pdf de una manera igualmente prolija, en alguna otra carpeta. Si el lead o prospecto nos llama por teléfono, anotamos en alguna carpeta o cuaderno su llamado. Tal vez tengamos una planilla de cálculo para registrar estos eventos.
Pasan los días y seguramente queremos saber qué pasó con este posible contacto. Encontrar la información es sencillamente caótica, se pierde mucho tiempo o tal vez ni siquiera se encuentre; O peor: nos olvidamos de este prospecto y por lo tanto, cuando nos acordamos se decidió por otro proveedor, y ya no será cliente nuestro…

En este punto, la empresa decide que no puede perder más oportunidades: precisa urgente de un CRM(Customer Relationship Management).

Hay que tener en cuenta algo importante: Hemos perdido un cliente antes de que sea cliente. Es decir, cuando era un lead, prospecto o posible contacto.

Se debe tener en cuenta si el software a adquirir nos brinda esta posibilidad, como maneja la información de un posible contacto, como trabaja con su historial y que sucede cuando el prospecto se convierte en cliente. Se pueden ver algunos tips a tener en cuenta en el blog
Algunos tips a tener en cuenta:

Si la empresa intenta reclutar nuevos clientes, posiblemente realice una lista, probablemente en Excel de los candidatos. Es importante que el software CRM a adquirir tenga la facilidad de importar leads o prospectos mediante planillas Excel.
Seguramente la empresa tendrá un contacto fluido con este prospecto, enviándole información, correos, o realizando llamadas telefónicas. Es imprescindible llevar un historial automatizado donde cada vez que lleve a cabo una de las acciones descriptas, se genere un historial de llamadas, correos, newsletters, etc., de fácil acceso.
Si se quiere enviar newsletters o información vía mails a un grupo de mails, es fundamental que el software permita agrupar leads para realizar esta tarea.
Permitir estadísticas sobre el seguimiento de leads en particular.
Permitir el intercambio de información entre usuarios del sistema, es decir, que diferentes usuarios puedan realizar el seguimiento de este prospecto, para no dejar que se dilate el entusiasmo inicial y crezca la posibilidad de perderlo.
Por supuesto: Si el prospecto se convierte en un contacto, en el software debería poderse realizar esta acción, sin perder la información previa pero sabiendo que ahora es un contacto y no un prospecto.

En síntesis, al momento de pensar en un software CRM, hay que tener en cuenta que tan importante es el seguimiento de prospectos dentro de la empresa y consultar al proveedor cuales son las facilidades que nos proporciona el software para lograr más fácilmente nuestro objetivo de atraer nuevos contactos.

Andrea Manna es Chief Software Architect en Upersoft.

El artículo fue facilitado por Evaluando CRM, que es partner de información de APPLICAR.

Dime cuál es tu cuna y te diré que ERP necesitas

noreply@blogger.com (applicar) — Sun, 30 May 2010 22:40:00 +0000

Por: Carolina Bandoli

Una vez determinada la necesidad de seleccionar un ERP, la empresa debe considerar cuál es la “especialización” o “fortaleza” que debe presentar el sistema para resolver su problema. Esto es importantísimo ya que cada ERP tiene una especialización en determinado sector que normalmente deriva del origen que ha tenido en su nacimiento.

La mayoría de los ERP nacieron o tuvieron un origen en las áreas financieras de las empresas, esencialmente por la necesidad primaria de éstas de tener un sistema contable y controlar así los pagos, la tesorería y los movimientos de dinero en general.

En segundo lugar están aquellos que nacieron de empresas que tienen grandes organizaciones de venta, donde el corazón del ERP estaba orientado a manejar íntegramente la cadena logística y de comercialización.

Los menos, son aquellos ERP cuyo corazón o eje de diseño, fue concebido en las áreas de producción de las empresas, cuya principal “preocupación” es la de resolver la operatoria industrial y de ellos vamos a hablar.

Es claro que si bien cada uno de estos sistemas tiene su core de origen en un área diversa, todos ellos incluyen en sus contenidos, módulos de todas las áreas, sin embargo, el origen de cada uno hace que conserven una fortaleza particular que los hace diferentes y especiales.

Entonces, en la selección de un ERP, las empresas tendrán que analizar, cual es el área funcional que más recursos necesita, que más problemas tiene o que más dificultades encuentra para operar diariamente.

Hablando específicamente de los ERP que se especializan en empresas industriales, podemos tener diferentes esquemas de funcionamiento. En el universo de empresas de producción existen múltiples tipos de producción que podemos resumir, según se ve en el diagrama adjunto en: discreta, continua y combinada que se conjugan además con; producción en serie, sobre pedido y productos especiales.

Algunos sistemas que manejan funciones de producción solo están preparados para realizar programación de la producción discreta, que es el modelo más sencillo de resolver. Muchos menos sistemas ERP están preparados para resolver la planificación de producción de de líneas de fabricación discreta, o sea por cantidad y pieza.

En caso de ERP’S más avanzados, resuelven todas las modalidades descriptas y cualquier combinación de ellas y en particular la fabricación por única vez, que muy pocos sistemas soportan, como puede ser el caso de construcciones hechas a medida, como puentes grúas, instalaciones para procesado de líquidos, producción de cervezas, producción de solventes, nafta, etc.

En el espectro de soluciones disponibles en el mercado argentino, hay muy pocos sistemas que tengan una programación de la producción y un control de la producción suficientemente amplio y flexible como para abarcar todos los tipos aquí presentados. Por eso al momento de seleccionar uno, es clave elegir uno cuya principal fortaleza operativa sea el área “core” de su compañía.
Como conclusión podríamos decir “dime cual es el corazón de tu negocio y te diré que sistema ERP te conviene”.

Carolina Bandoli es Directora de Hipernet S.A.

El artículo fue facilitado por Evaluando ERP, que es partner de información de APPLICAR.

Implementación de un ERP ¿Por qué puede fallar?

noreply@blogger.com (applicar) — Mon, 26 Apr 2010 13:36:00 +0000

Share|

Por: División de Consultoría de Evaluando ERP

La implementación de un sistema de gestión empresarial (Enterprise Resource Planning-ERP) puede ser 100% exitosa desde el punto de vista técnico, pero al mismo tiempo ser percibida como un fracaso. ¿Por qué?

Implementar un ERP es esencialmente un tema de cambios en el negocio. No una decisión de cambiar programas o sistemas para decirle al equipo de trabajo “Tenemos un nuevo sistema, úsenlo”.

Los cambios en el negocio son cambios que tocan a las personas y a la cultura. En cierto sentido ambos están relacionados. La gente, que cambia, opera a nivel individual o en un grupo de trabajo, es decir su influencia es a nivel micro, mientras que el cambio cultural se refiere a cómo un departamento o una organización completa “hacen las cosas” y tiene un impacto a nivel macro.

Para tener éxito con una implementación, hay que saber qué es lo que se quiere cambiar del negocio y por qué.

Pero la pregunta más importante es si realmente existe la voluntad para comprometerse seriamente en cambiar y alcanzar los objetivos que se persiguen.

En la ecuación del cambio “el cómo hacerlo” no siempre queda relegado a un simple programa de cambio. Dado que un ERP puede afectar a muchas partes de la organización, no se trata de implementar una solución que se baja de un estante y listo y es apta para todo tipo de empresas.

Un proyecto de cambio organizacional debe ser iniciado como soporte al ERP. Con el ERP focalizado en alterar los procesos, se produce un efecto de “arenas movedizas”, donde nadie está seguro de lo que está pisando. La proposición de cambios en el negocio debe estar claramente definida e, idealmente, apoyada por investigación y experiencia.

¿Qué diferencia hay entre la cultura organizacional actual y la que se requiere para alcanzar las metas previstas con la iniciativa del ERP?

Si la diferencia (GAP) no se puede superar, el proyecto ERP está expuesto a muchos riesgos.

Si bien hay un conjunto de mejores prácticas aceptadas para cada industria, las que teóricamente deberían ayudar a una empresa a alcanzar lo que desea culturalmente, la originalidad de cada iniciativa de ERP significa que el programa de cambios abarcará diferentes aspectos particulares.

Sin embargo, el programa será capaz de adecuar la demanda de esa originalidad si se puede contar con el management correcto.

Los problemas aparecen cuando el equipo gerencial no se da cuenta que:

La implementación del ERP equivale a cambios en el negocio.
No se compromete con el cambio.
No tiene objetivos de negocios claros.

Los responsables de la iniciativa ERP deben asegurarse que estas cuestiones claves puedan manejarse y direccionarse si se pretende una implementación exitosa.

Acerca del autor:

División de Consultoría de Evaluando ERP, es partner de información de APPLICAR.

Herramientas para Describir Procesos

noreply@blogger.com (applicar) — Sun, 18 Apr 2010 13:09:00 +0000

Share|

Por: Martín Kornitz

Se realizó un sondeo en el grupo de Mejora de Procesos en LinkedIn. La pregunta formulada fue la siguiente:

¿Qué herramienta recomiendas para describir procesos?
Según tu experiencia, que herramienta recomendarías para describir procesos de forma simple y ágil, generando flujo gramas, PEPSC (Proveedores, Entradas, Procesos, Salidas y Clientes), anexos, etc. ¿Cuáles son los aspectos que más valoras y las desventajas que identificas en la herramienta?

En un período de tres meses se recibieron comentarios de diversos profesionales en el ramo y se obtuvieron los siguientes resultados. Cabe mencionar que sólo se muestran las diez herramientas más votadas. El documento completo se puede revisar AQUI.

Votos: 11

Gratuito: NO

Comentarios:

Muy flexible.
Con sus atributos facilitan el diseño de procesos lo que las hace unas herramientas muy flexibles.
Es una herramienta potente graficamente, flexible y se puede vincular fácilmente a todo tipo de aplicaciones.
Es muy versátil. sin embargo, requiere tener un buen grado de detalle sobre la lógica del proceso.
A parte de ser versatil y de poseer gran cantidad de bibliotecas es relativamente facil adaptarse a él.

Se recomienda usar: Visio + Task Map

Votos: 8

Gratuito: SI

Comentarios:

Hace fácil diagramar, ejecutar y mejorar los procesos de negocio. Sin importar si es una pequeña compañía o una gran organización. Ademas tiene documentación, foros de soporte gratuitos y cursos gratis.
Con la nueva versión se puede compartir diagramas subiéndolos a la Web, algo muy practico para trabajar en equipo y/o exhibirlo a clientes.
Es una herramienta muy intuitiva y fácil de utilizar (además de la descarga gratuita y la publicación web ya comentada).
Es completamente BPMN compliance. Comparado con Visio (que utilizábamos anteriormente), paradógicamente presenta la ventaja de no ser tan versátil, esto debido a que cuando se trabaja en equipos más o menos grandes, resulta muy importante la estandarización y con Visio es casi imposible.
La suite completa, permite ir un poco más allá del modelado y avanzar con la automatización de algunos procesos (aunque sea a nivel de prototipo).
Me pareció muy completo e intuitivo. Lo he probado en forma básica hasta la automatización de procesos y funcionando en red.
La función de automatización de procesos integrado es un plus muy bueno e intuitivo
La versión de prueba descargable te permite hasta 100 usuarios.

Votos: 6

Gratuito: En versión monousuario

Comentarios:

Aplicación sencilla pero con amplias funcionalidades para elaborar flujogramas y describir procesos incluyendo proveedores, entradas, salidas, clientes, etc.
Combina la parte gráfica con muchos atributos que permiten documentar muy bien cada paso del proceso y permite la integración con los roles, sistemas, documentos, etc.
Se puede publicar todo en una Web de procesos para que todos los miembros de la organización puedan navegar por los procesos.
Lo importante es saber si necesitas sólo diagramar procesos o hacer una "Arquitectura Empresarial", en la que tengas que asociar al proceso, los documentos, E/S, controles, indicadores, sistemas, roles, etc. Si lo que necesitas es dotar de toda esta información a un proceso, yo te recomendaria Adonis. Tiene un modulo de simulación de costos y exporta a HTML y Word.
Es una buena opción ya que presenta capacidad para modelar toda la arquitectura empresarial, capacidad de simulación y análisis de escenarios. Así mismo, ofrece la capacidad de generar entregables doc/html, capacidad de exportar formatos como xpdl o bpel. Todo ello combinado con una gran facilidad de uso.
Yo pienso que para modelar esta bien Adonis. En mi opinión lo malo de todas las herramientas para modelar es el mantenimiento, lo mejor que he visto en este sentido puede ser Adonis.
Se recomienda Adonis para clasificacion de Procedimientos y Procesos.

Votos: 4

Gratuito: SI

Comentarios:

Combina la parte gráfica con muchos atributos que permiten documentar cada paso y permite la integración con los roles, documentos, etc.

Votos: 4

Gratuito: NO

Comentarios:

Potente herramienta para el modelado de procesos.
Es totalmente compatible con SAP.
Actualmente, estoy utilizando ARIS Business Architec, esta herramienta permite realizar cadenas de valor y explotar los procesos en niveles de detalle e interactuar entre los distintos procesos que tenga una compañía (P.e.: rrhh y finanzas, dependiendo el caso), también se pueden establecer indicadores de gestión y por último publicar en versión web de consulta para todos los usuarios.
El mantenimiento se realiza con un simple movimiento de gráficos. Y para aquellas empresas que tienen SAP, todas las modificaciones que se realicen en el sistema, ARIS las interpreta automáticamente y alli la propuesta para la modificación automática del proceso.

Votos: 3

Gratuito: NO

Comentarios:

Es muy practico y tambien se puede publicar en Web para la participacion on-line de todos los usuarios.
Los procesos se modelan a través de diagramas de actividad (UML) y permite armar templates para generar documentación automática a partir de la herramienta (formato rtf ).
Sencilla de usar, completa, y económica.
Es una herramienta que se usa en las empresas de software para modelar sistemas, asi que si la empresa la tiene incorporada no necesitan comprar otra, y si no, es una buena opción a la hora de pensar en adquirir un producto para el modelado de software (para esto tiene muchas ventajas más).
También permite una integración con CVS, también conocido como Concurrent Versioning System, es una aplicación informática que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren. CVS se ha hecho popular en el mundo del software libre. Sus desarrolladores difunden el sistema bajo la licencia GPL.
Es pagada, pero tiene un fuerte poderío en su facilidad para el modelado y la documentación.
Permite obtener un proceso por niveles totalmente navegable y como resultado adicional exportar la descripción como documentación de tipo: Web (navegable): lo que te permite publicarlo. RTF: a modo de documento para establecer procedimientos.

Pizarra y Rotulador

Votos: 3

Gratuito: SI

Comentarios:

La mejor herramienta que he usado: Pizarra y rotulador.
La "aplicación" arranca de forma instantánea, con sólo quitar la capucha al rotulador. La "actualización" consiste en comprar un rotulador nuevo cuando se acaba la tinta. La velocidad de actualización de la pizarra es de 10 a 15 segundos, dependiendo de lo grande que sea. El único inconveniente es que no maneja "multidocumentos", aunque en algunos sitios he tenido pizarras correderas de tres y cuatro hojas.
A pesar de sus limitaciones, es una herramienta excelente para la colaboración en grupo. Es lo que hace falta al diseñar procesos. Al menos yo, cuando tengo que hacerlo, convoco una reunión de calidad y nos ponemos todos a dibujar sobre la pizarra hasta que nos ponemos de acuerdo. Luego lo pasamos a limpio.

Votos: 2

Gratuito: NO

Comentarios:

Especifico para procesos una herramienta que corre sobre Visio que me sirvió mucho para modelar procesos industriales orientados a mejoras en Software.

Votos: 2

Gratuito: NO

Comentarios:

Mi equipo y yo trabajamos hace más de 5 años con Corporate Modeler en entronos complejos (multi empresa, multi idioma, multi locación, multi negocio, múltiples niveles de despliegue, etc.) y ha resultado satisfactoria, fundamentalmente por ser amigable, por su flexibilidad y porque prácticamente no requiere participación de personal de sistemas.

Acerca del autor:

Martín Kornitz (mart...@hotmail.com) es Responsable de Control de Gestión en Molino Cañuelas SACIFIA. Ha sido Quality Control Leader en Siemens IT Solutions and Services S.A. Se ha desempeñado como Senior Test Analyst en Cubika.

7 claves para lograr el éxito de una implementación tecnológica

noreply@blogger.com (applicar) — Sun, 28 Mar 2010 14:33:00 +0000

Por: Damián Szulman

Como consultores, muchas veces ingresamos a la empresa para implementar un proyecto y vemos una cantidad de factores que van surgiendo, en la tarea cotidiana, que conspiran contra un buen resultado. Algunos ejemplos de lo que debe hacerse y lo que debe evitarse.

1. El compromiso de la Dirección en todas las etapas del proyecto

Habitualmente, la Dirección participa en la definición general del modelo a seguir, y en elección del proveedor, pero luego “deposita” el trabajo en el consultor. Y muchas veces, la implementación del proyecto se ve entorpecida cuando, al ir bajando en el organigrama, surgen temas puntuales para los que no hay indicaciones claras sobre cómo avanzar. O, por el contrario, se avanza en un sentido que no es el deseado por la Dirección, que se entera tarde de la decisión tomada.

Por eso, es necesario que los más altos niveles de la empresa se involucren más profundamente, y no sólo para señalar cuál es el camino que desean recorrer ante cada encrucijada sino, además, para lograr agilidad en la toma de decisiones; motivar y comprometer al equipo de trabajo; señalar la dirección del proyecto y la empresa y cumplir su rol de “agente de cambio”.

2. El armado del equipo de proyecto

Para avanzar lo más rápidamente posible, por parte de la empresa deben participar los “mejores” y no “los que no tienen otra cosa para hacer”.

Este es un aspecto fundamental. Entendemos que “los mejores” son realmente necesarios en las tareas que están llevando a cabo, pero justamente por eso, son ellos – y no algún asistente que recién comienza – quienes deben trabajar codo a codo con los consultores, explicando cómo se realizan los procesos, y señalando las particularidades y los posibles conflictos de cada sección y tarea, etc.

Por el mismo motivo, deben participar aquellos que puedan tomar decisiones por sí mismos de una manera apropiada, o tener el suficiente criterio para discernir cuando deben elevar la toma de la decisión.

También es importante que participen quienes tienen espíritu crítico y voluntad de cambio, de modo que puedan señalar cuáles son las mejoras necesarias en los procedimientos.

3. La comunicación

El proyecto debe ser debidamente comunicado a toda la empresa, para despejar dudas y temores, y confirmar de qué manera afectará a las tareas de todo el personal.

Es importante que haya información frecuente. Lo ideal es que se produzcan informes de avance operativo semanales, de integración de procesos en forma quincenal, y de Dirección en forma mensual.

Es útil implementar estrategias de comunicación visual de las etapas del proyecto, y comunicar desde el área de RRHH en cuanto a lo que se espera de cada persona que forma parte del equipo de proyecto.

4. La capacitación y entrenamiento

En primer lugar, se debe entrenar al equipo de proyecto en la funcionalidad del sistema pero, además, la capacitación debe impartirse lo antes posible a los usuarios finales en la funcionalidad que ocuparán, en forma práctica y teórica (es decir, con material impreso). En la medida en que el personal esté informado de la marcha del proyecto y de los cambios en la forma de realizar sus tareas, se sentirá más seguro.

5. La clarificación del alcance

La Dirección debe establecer claramente el alcance del proyecto y transmitirlo a toda la empresa. Para ello, en primer lugar debe quedar claro cuáles son los procesos que NO están incluidos en el alcance del proyecto, y cómo quedarán integrados (interfases). Es importante informar a cada sector del personal de qué manera se verá afectado.

6. “Análisis Paralisis”

Hay una etapa en la cual se debe evitar el excesivo análisis de cada definición, porque esto lleva a la parálisis y a NO tomar ninguna decisión. Para esto, lo mejor es presentar los problemas de la forma más simple y resumida posible, de forma que todos los involucrados entiendan la decisión que se está tomando y determinar previamente cuál será el tiempo máximo para tomar decisiones. En general, la etapa de análisis y recopilación de información sobre los procesos no debe llevar más del 30 por ciento del tiempo total que va a llevar la implementación. Si es necesario, más adelante se podrán hacer algunos ajustes.

7. La “Limpieza de Datos”

En general, se determina que un viernes se concluirá el trabajo con una modalidad y el lunes siguiente se comenzará a aplicar el nuevo sistema. Por este motivo, el traspaso de la información debe hacerse en ese fin de semana.

La etapa de migración de datos desde los sistemas anteriores es una tarea ardua y de máximo detalle, que requiere de tiempo y definiciones acertadas: hay información contable, de producción, de logística, que hasta el último minuto va variando.

Es cierto que hay un cúmulo de datos que no son “de último momento” y que se pueden comenzar a migrar antes (por ejemplo, información histórica sobre distintos sectores). Sin embargo, aún en estos casos surgen modificaciones o cuestiones de último momento, por lo que debe nombrarse a un responsable de los datos de cada área, que asegure que la información se encuentre disponible en tiempo y forma cuando el avance del proyecto así lo requiera.

Observando estos 7 puntos, la empresa estará correctamente encaminada para lograr una implementación exitosa.

Damián Szulman es Director de Crystalis Consulting.

El artículo fue facilitado por Evaluando ERP, que es partner de información de APPLICAR.

Mitos sobre la Dirección de una Pequeña Empresa

noreply@blogger.com (applicar) — Sun, 21 Mar 2010 16:03:00 +0000

Por: Miriam Marcus, Maureen Farrell y Melanie Lindner

Este artículo ha sido modificado de su versión original

Pese a lo que dicen los libros de texto, una gran idea y un sólido plan de negocios a menudo no son suficientes.

Le preguntamos a un grupo de emprendedores sobre los supuestos que más frecuentemente están fuera de lugar con respecto al espíritu empresarial.

Mito: Los empresarios son visionarios dispuestos a asumir riesgos

Verdad. A pesar de lo que los medios de comunicación tratan de hacernos creer, no es necesario ser un héroe que asume riesgos a capa y espada para poner en marcha y dirigir su propio negocio. "Estas historias sirven para hacer glamoroso el espíritu de empresa y hacerlo parecer un arte exclusivo que está relegado a algunas personas que exhiben una variedad de características específicas", dice Len Schlesinger, presidente de Babson College, Babson Park, Massachusetts "Los empresarios son muy buenos para evitar el riesgo en lugar de tomarlo".

Mito: La idea es más importante que los detalles.

Verdad: Lo último en nuevas tecnologías y modelos de negocio es atractivo, pero no un requisito. "Una idea bien estructurada y bien ejecutada, es mejor que una idea excelente mal ejecutada", dice Gerald Shreiber, fundador y director ejecutivo de J & J Snack Foods.

Mito: Guarde celosamente su idea, no sea que alguien se la pueda robar.

Verdad: Es posible que usted esté desarrollando una idea, pero seguramente no tiene todas las respuestas (si ni siquiera ha formulado las preguntas correctas). "Mientras que usted no quiere poner su plan de negocio completo en Internet, los empresarios que hacen su tarea consultan a un relativamente grande, pero selecto, número de personas con el fin de intercambiar opiniones", dice Reid Hoffman, fundador y director ejecutivo de LinkedIn.

Mito: Su plan de negocios debe ser sólido como una roca desde el comienzo.

Verdad: La construcción de una empresa es un proceso iterativo, dice Hoffman, y los empresarios deben estar dispuestos a adaptarse - a los cambios en la demanda del cliente o en el entorno competitivo. "No es como el ajedrez, donde se tiene una estrategia pre-formulada, determinista y donde se debe realizar todos los movimientos correctos en la secuencia exacta", comenta. Debe haber un plan principal con el cual se debe iniciar, el cual debe ser flexible y estar en constante actualización. Hoffman dice: "Ningún plan de batalla sobrevive el impacto con el enemigo".

Mito: La pasión te llevará a tus metas.

Verdad: La pasión puede aliviar el dolor de 15 horas de trabajo al día, puede galvanizar a los empleados y ganar a los clientes. En algunos casos, incluso puede cautivar a los inversores acaudalados. Pero no es una bala de plata. El empresario más eficaz aprende a modular sus emociones”, dice Rich Gelfond, director ejecutivo de IMAX.

Mito: Usted puede fijar su propio horario.

Verdad: "Pensé que sería el jefe y que me sentaría con los pies sobre el escritorio", dice Mike Zaya, director ejecutivo de PrintRunner, una empresa en internet de impresión y venta de cartuchos de tinta. “La realidad es un poco diferente, en algún tiempo tuve que pasar durmiendo sólo dos horas en la oficina”. "Uno termina siendo el portero de la empresa, y el portero tiene que sacrificar su cuerpo", añade Zaya. "Uno tiene que ser el primero en entrar y el último en salir de la oficina".

Mito: Existe la gloria en este trabajo.

Verdad: Pese a todas las recompensas que se obtienen, el espíritu empresarial también puede sentirse como un trabajo ingrato. "Nadie me dice que lo hice bien, soy yo el que siempre se lo dice a todos los demás", comenta Amir Korangy, titular de Real Deal, una compañía de publicidad en bienes raices de Nueva York. Korangy dice que los empresarios necesitan la motivación interna y tranquilidad, ya que rara vez viene de afuera. "Después de unos años, uno quiere que alguien le diga que está haciendo un buen trabajo", añade. "Pero la única manera de decirte que estás haciendo un buen trabajo es ver el aumento en los ingresos."

El artículo original se puede encontrar en:

De la Penumbra del ERP al Auge

noreply@blogger.com (applicar) — Thu, 04 Mar 2010 15:14:00 +0000

Por: División de Consultoría de Evaluando ERP

Todas las empresas deberían aprender a manejar riesgos. Una de las dificultades es que existe la tendencia a considerar que tomar acciones es más peligroso que mantener el “status quo”. Por eso, en las actuales circunstancias de cambios se escucha que la inacción es, con frecuencia, la opción de menor riesgo. Sin embargo “continuar con el curso actual” puede ser la receta para fallar.

Las implementaciones son un perfecto ejemplo. Cuando se selecciona el software ERP correcto y la implantación es manejada inteligentemente, un sistema de gestión empresarial reducirá los riesgos en lugar de aumentarlos. El peligro más grande en los días actuales es continuar manejando el negocio de manera usual y dejar que la competencia gane ventajas considerables que provienen de la implantación de ciertos productos ERP.

La era de la penumbra para el software ERP

No se entiende mucho el escepticismo que reina a veces alrededor de las implantaciones ERP. Muchos responsables de tecnología, también conocido como CIO (Chief Executive Officer) son conscientes de los desastres que ocurrieron a fines de los ’90 e incluso siguen aconteciendo.

El software ERP comenzó como el paso siguiente al sistema MRP (Material Requirements Planning) y al software MRP II (Manufacturing Resource Planning) que emergieron en la década de los ’80. El movimiento desde el MRP al ERP se inspiró en algo racional: incrementar el alcance funcional para incluir el negocio completo y hacerlo en un modelo simple y con datos integrados.

Mientras el software MRP se focaliza en el planeamiento, compras y manufactura, el MRP II amplia la funcionalidad para enlazar el planeamiento de la manufactura y la ejecución con los procesos financieros.

El software ERP presenta una visión más ambiciosa sobre las capacidades de un sistema de gestión. Puede operar en un ambiente global y manejar todo lo relativo a una empresa: clientes, proveedores, inventario, producción, mantenimiento de planta, servicios, contabilidad, pago de sueldos, finanzas y administración de recursos humanos. Cada dólar o peso que se paga, se cobra o se mueve de cualquier forma en la compañía e incluso fuera de ella, puede ser manejado por el ERP. Tal como dicen los vendedores: el ERP es la pieza de software que una empresa necesitaría siempre.

Alentados por el cambio del milenio (el famoso Y2K) muchos productos salieron a la venta en estado de inmadurez y con metodologías de implementación que aún no habían sido probadas. El problema se agravó porque la primera ola de consultores carecía de experiencia o conocimientos en la industria específica o en el software o en ambas.

Todo el mundo sufrió la peor parte de la curva de aprendizaje al mismo tiempo. No existían las mejores prácticas de la industria y una gran parte de costos y tiempos se emplearon en la re ingeniería de procesos.

Las implementaciones fueron complicadas y pocas compañías tenían conocimiento sobre la administración del cambio (Change Managemen) necesaria para aliviar muchos de los problemas que se producían.

Finalmente los clientes terminaron con soluciones de software ERP muy personalizadas (customizadas) y, con frecuencia, con muchas versiones difíciles de administrar.

Era muy complicado desarrollar interfases para sincornizarse con otras aplicaciones y la constante necesidad de nuevas funcionalidades solo agregaba más barullo.

El resultado fue: costos astronómicos, sistemas pocos flexibles desarrollados en lenguajes extraños que debían ser arreglados y muchos dolores de cabezas.

Nadie debería sorprenderse que los responsables de tecnología actuales tratan de evitar cualquier escenario similar.

Integrar información como una estrategia para sobrevivir

Uno de los argumento de ventas a favor del ERP fue la posibilidad de funcionar en una plataforma global, tanto geográfica como funcional.

El mensaje de globalización de los 90 ayudó. Las empresas debían tener capacidad de ajustarse a la demanda para expandirse en el mercado internacional. Los clientes y proveedores podían estar localizados en cualquier lugar y la debilidad del dólar sirvió para empujar a los negocios a expandirse más allá de sus fronteras geográficas.

En el mercado global, una cadena de abastecimiento efectiva e integrada no es posible sin acceso en tiempo real a datos de plan de producción, fabricación, finanzas, inventarios y demanda.

Los datos son una parte de los elementos de decisión. Además se necesitan herramientas analíticas para que las filas de datos se transformen en información con valor.

Para completar este panorama, el personal de la compañía que se desplaza por el mundo necesita ganar eficiencia usando prácticas de negocios en común soportadas por una infraestructura confiable.

Con la tecnología correcta, los vendedores, proveedores, distribuidores, terceras partes, centros de distribución y agentes de exportación están en condiciones de enviar y recibir información instantáneamente.

No hay nada nuevo para decir sobre la mejora de desempeño que se obtiene compartiendo información empresarial vital.

El ERP del nuevo siglo

Muchos de los ERP’s surgidos en los 90 consideraron necesidades de negocios corporativas. Pero ignoraron los requerimientos de la producción en planta. Ese descuido comenzó a subsanarse.

El software ERP evoluciona para incluir un amplio rango de funcionalidades que estuvieron previstas años atrás. Por ejemplo: Lean Manufacturing, KANBAN, factura electrónica, CRM y otras sofisticaciones para contar con información integrada.

Acerca del autor:

División de Consultoría de Evaluando ERP, es partner de información de APPLICAR.

El Efecto Hawthorne

noreply@blogger.com (applicar) — Fri, 26 Feb 2010 14:09:00 +0000

Por: Jesús Ramírez

En la década de 1920, la dirección de la Western Electric, empezó un experimento en la planta de Hawthorne Works en Cicero a las afueras de Chicago. El experimento buscaba mejorar la vida laboral de millones de personas y expuso un fenómeno que todo investigador que planea un experimento social debe tener en cuenta en su diseño.

En aquel tiempo, el entusiasmo por la búsqueda de incrementos en la productividad, se fundamentaba en el crecimiento que se observaba en la industria de las telecomunicaciones en Estados Unidos. La dirección de la Western Electric decidió investigar si las condiciones de trabajo afectaban la producción. Pero, los estudios iniciales sobre “iluminación” no fueron concluyentes. No importaba si la iluminación aumentaba o disminuía hasta ser tan tenue como la luz de la luna, la productividad siempre aumentaba. Cualquiera que fuere el tipo de intervención, parecía que ésta promovía que el trabajo se desarrolle más rápido.

Confundidos, los directivos recurrieron a la Harvard Business School para que los especialistas diseñen un estudio más complejo. De este modo, en abril de 1927, cinco mujeres fueron retiradas de la planta de producción y ubicadas en una habitación separada – la habitación de prueba de ensamble de transmisores. Durante los cinco años siguientes, a la vez que estas mujeres ensamblaban transmisores complejos, eran monitoreadas minuto a minuto. Sus condiciones de trabajo fueron alteradas de forma regular, pero ya sea que se incluían o removían los descansos, o su jornada laboral era incrementada o reducida, su productividad continuaba aumentando.

El estudio permitió mejorar las condiciones de trabajo en toda la fábrica, por ejemplo, se introdujeron periodos de descanso para todos los trabajadores. Pero, también permitió identificar un fenómeno conocido como el Efecto Hawthorne, el cual debe ser considerado en el diseño de cualquier experimento. El efecto Hawthorne indica que el comportamiento de los sujetos del experimento se ve afectado por el sólo hecho de que éstos sepan que están siendo estudiados.

Sin embargo, el Efecto Hawthorne es y ha sido ampliamente cuestionado. ¿Cómo un experimento que se basa en una muestra tan pequeña – cinco mujeres, dos de las cuales fueron reemplazadas durante el experimento – puede dar como resultado una teoría tan omnipresente?

Este post también se puede encontrar en >>> El Efecto Hawthorne

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

Formulación de una estrategia para la implementación de un ERP

noreply@blogger.com (applicar) — Tue, 02 Feb 2010 11:47:00 +0000

Por: División de Consultoría de Evaluando ERP

La capacidad de un sistema ERP para alcanzar los logros propuestos y planeados, depende en un grado muy elevado del modo en que tiene lugar el propio proceso de implementación. Con el propósito de optimizar el desarrollo de dicho proceso, resulta fundamental establecer modelos que permitan a los consultores y las empresas llevarlo a cabo de manera más fructífera.

La estrategia de implementación define los elementos a tener en cuenta durante el proceso y determina los pasos que se darán para terminar con la puesta en marcha del sistema en condiciones de operatividad. La idea de estrategia es tratar de avanzar más allá de las metodologías de implementación que con frecuencia proponen los propios proveedores de la aplicación o los consultores que participan del proyecto. La estrategia de implementación debe considerar los objetivos que se persiguen con la ejecución del proyecto y las condiciones o condicionantes de contexto que, en última instancia, son las que determinan los resultados de las decisiones que adopta la empresa durante el proceso. En consecuencia la estrategia de implementación debe ser definida de un modo muy específico en relación con la organización para la que se diseña. Esto no es un obstáculo para que puedan considerarse algunas alternativas clásicas en torno a las que gira una estrategia de implementación.

Dependiendo del grado de propensión o aversión al cambio, se podría decir que hay dos caminos a seguir:

Implantación de una versión elemental

A veces se dice que se comienza con el “out of the box” lo que significa que se acepta el sistema tal cual está (“as is”) para añadirle luego, de manera gradual, funciones adicionales una vez que las funciones básicas funcionan y lo hacen de manera satisfactoria. Las principales ventajas de esta opción podrían resumirse en:

Rapidez de implementación y por ende, resultados.
Exito político y por ende, respaldo de la organización.
Reducir la posibilidad de repetir aspectos no deseados de los sistemas heredados.

Esta alternativa es recomendable en el caso que la plataforma del ERP deba ser puesta en marcha en varias instalaciones simultáneamente.

Implementación en un solo esfuerzo (one shot)

Es la estrategia más ambiciosa. En este caso es posible plantear enfoques distintos, que van desde la implementación de módulos aislados, que paulatinamente se vincularán con los sistemas heredados de la empresa (Legacy System) hasta la implementación del sistema completo. La adopción de esta estrategia dependerá de la predisposición de la empresa para adaptar sus procesos a las características del software o su deseo de disponer de un sistema más afín a sus características propias.

Una variante a ambas estrategias es montar un entorno de laboratorio para realizar ciertos ajustes y la capacitación para luego realizar la réplica en el resto de las instalaciones (Roll Out).

Pero para poder tener éxito, además del enfoque general y de la programación del conjunto de actividades necesarias para llevar adelante el proyecto, se debe considerar los factores críticos para el éxito o fracaso, junto con la interacción entre ellos y, como hemos dichos las condiciones o condicionantes del entorno.

Nota:

Este artículo fue elaborado considerando las ponencias realizadas en el X Congreso de Ingeniería de Organización en Valencia, España.

Acerca del autor:

División de Consultoría de Evaluando ERP, es partner de información de APPLICAR.

Las alianzas ¿Son un nuevo modelo de crecimiento?

noreply@blogger.com (applicar) — Mon, 21 Dec 2009 03:19:00 +0000

Por: Daniel M. Aisemberg

Las alianzas suponen una asociación de fuerzas entre empresas que les permitirá compartir recursos, evitar riesgos, y aprovechar las ventajas competitivas de cada una de las empresas con el fin de alcanzar un objetivo común. Las alianzas pueden ser entre dos o más firmas y de carácter temporal o indefinido. Sin embargo hay que distinguir entre los acuerdos transaccionales y los que contribuyen con la estrategia de la organización.

Acuerdos transaccionales

Generalmente están involucradas las áreas de compras o ventas. Las características de estas alianzas son bien definidas:

Las empresas no tienen un objetivo común.
Trabajan juntas pero para una actividad en particular.
Los contratos son de alcance y duración muy limitados.
Por ejemplo: los acuerdos para campañas de marcas compartidas (co-branding).

Alianzas estratégicas

En este tipo de alianzas, las partes tienen un objetivo común. Las empresas involucradas comparten capacidades, acuerdan sus estrategias, y establecen una relación de largo plazo. Se distinguen por lo siguiente:

El contrato es un marco de referencia y no una herramienta de litigio.
Las compañías comparten información, recursos y fondos.
Pueden llegar a realizar inversiones conjuntas.

Aunque la relación entre personas pase por momentos difíciles, el propósito de la alianza mantiene la cohesión necesaria. Para cierto tipo de empresas y mercados, el menú de opciones de crecimiento es limitado.

Las razones que una empresa puede tener para cooperar o aliarse con otra pueden ser de lo más variado, pero se pueden clasificar en tres grandes grupos:

Razones internas.

Razones de este tipo que pueden conducir a la cooperación son compartir: riesgos de costos, recursos físicos y tecnológicos, líneas de productos, canales de distribución, medios y servicios de abastecimiento, personal directivo y especializado, etc.

Razones competitivas.

Tienen por objeto reforzar las oportunidades competitivas de las empresas que forman parte de la cooperación, como puede ser la expansión de negocios ya iniciados, evitar la guerra de precios, etc.

Razones estratégicas.

Como son la penetración en otros mercados, diversificación de productos, transferencia de tecnología, etc.

Las empresas asociadas por una cooperación deben obtener beneficios para que ésta sea posible.

Acerca del autor:

Daniel M. Aisemberg es Director de IMPLANEX, que es partner de información de APPLICAR.

¿Cómo documentar proyectos? (3)

noreply@blogger.com (applicar) — Wed, 09 Dec 2009 23:06:00 +0000

Por: Jesús Ramírez

La siguiente etapa de la documentación de proyectos se da durante la planeación de los mismos.

El resultado del proceso de planeación de proyectos es el Plan de Gestión del Proyecto. Este documento, no es mas que un compendio de otros planes que van a indicar la forma en que le proyecto se irá ejecutando.

El Plan de Gestión del Proyecto, se debe estructurar de modo que todas las respuestas a las dudas que surjan durante la ejecución del proyecto puedan ser resueltas con la información que ahí se encuentra. Los planes que componen el Plan de Gestión del Proyecto son nueve. En esta ocasión se describirán los tres primeros y en las entregas posteriores de esta serie se irán definiendo los demás:

Plan de gestión del alcance

Este documento indica la forma en que será administrado el alcance del proyecto. Esto es, cómo se deberá dimensionar el esfuerzo realizado durante la ejecución y como deberá verificarse de modo que sólo se desarrolle el trabajo que ha sido planeado para el proyecto. Los componentes típicos de este plan son: el WBS (Work Breakdown Structre) y la matriz de trazabilidad de requerimientos del proyecto.

Plan de gestión de los tiempos del proyecto

Aquí se debe indicar los rangos dentro de los cuales el tiempo de ejecución del proyecto es aceptable. Normalmente este plan esta representado por el cronograma del proyecto. Sin embargo, el cronograma en cuestión nunca estará completo a menos que todos los entregables del proyecto hayan sido traducidos en paquetes de trabajo, todos los recursos (humanos y materiales) sean asignados y estos recursos hayan sido balanceados de modo que todos se encuentren adecuadamente distribuidos de acuerdo con su capacidad y calendario de trabajo.

Plan de gestión de los costos del proyecto

Este plan está representado principalmente por el presupuesto del proyecto, hay que anotar que este presupuesto deberá ser el definitivo y aprobado por los patrocinadores del proyecto. Así mismo, es necesario, al igual que en el plan de gestión de tiempos, conocer las políticas de la organización que nos indican cuál es el rango admisible para las desviaciones de costos en el proyecto. Generalmente el presupuesto del proyecto se conoce de forma global, pero, es deseable que se pueda desagregar a nivel de paquetes de trabajo, esto con el fin de realizar un seguimiento adecuado de los costos del proyecto.

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

¿Integrar sistemas es integrar personas? 7 hábitos para el éxito del ERP

noreply@blogger.com (applicar) — Sat, 28 Nov 2009 17:56:00 +0000

Por: División de Consultoría de Evaluando ERP

Tres consultores ingleses describieron la implementación de un ERP como el equivalente a hacerse un tratamiento de conducto: es muy doloroso; es caro y a veces s preferible no hacerlo, aunque los especialistas digan que será mejor.

El ERP es un hueso duro de roer y a través de los años hay una buena cantidad de proyectos fallidos. Muchos de estos pueden atribuirse a fallas en uno o varios de los siete hábitos para una implementación exitosa.

Se trata de hábitos porque muchos de los problemas subyacentes están relacionados con dificultades para afrontar cuestiones culturales dentro de la organización.

Las personas están acostumbradas a trabajar con métodos viejos y quieren continuar con esas formas. Están habituados a trabajar con datos inapropiados, fechas inválidas del sistema y otras “ineficiencias”.

Mucha gente prefiere la informalidad a la formalidad. Tienen ciertos vicios.

¿Por qué cambiar estos hábitos a esta altura de la vida?

La implementación de un ERP trae consigo la necesidad de adoptar mayor formalidad en el trabajo y la adhesión a más procesos de los que la gente está acostumbrada.

La verdad es que el mundo es más global, más competitivo y cambia muy rápido. Y en este contexto las empresas necesitan integrarse tanto en los negocios como en los países, industrias y culturas para poder sobrevivir.

La integración de sistemas es esencial. Sin embargo, la integración de personas es un gran desafío.

Por razones de espacio esta nota está desarrollada parcialmente. Sin embargo puede recibir el documento completo en formato PDF ingresando aquí “Los 7 hábitos para el éxito del ERP

1-Implementar un liderazgo integrado

Hacia finales de los ’80 las empresas comenzaron a reconocer el valor del planeamiento de ventas y operaciones. Fundamentalmente el balance entre la demanda y el plan de capacidad operacional.

Un liderazgo integrado describe el modo en que el CEO lidera la estrategia desde arriba hacia abajo (top-down) y replantea desde abajo hacia arriba (bottom up), basado en información honesta, correcta y realista.

Esto requiere que todas las personas se involucren, no solo ventas y operaciones. El desafío es que todos en la organización sean honestos con lo que entregan y que manejen un único conjunto de números.

No quiere decir un juego de números de finanzas, otro de operaciones, otro de ventas, otro de marketing. En algún momento, todas las compañías necesitan “una versión de la verdad”.

2-Asegurar que el equipo gerencial tiene entusiasmo y compromiso con el proyecto.

Hay ejecutivos de primer nivel creen que la implementación de un software puede sub contratarse a terceros. Pero sub contratar implementación es sub contratar responsabilidades.

Desafortunadamente la implementación es menos seductora que adquirir un negocio o lanzar un nuevo producto. Los “tecnófobos” no quieren involucrarse en proyectos de IT que, generalmente, son largos, aburridos y cargados de conflictos.

3-Asegurar que los datos de la compañía sean precisos.

Una causa frecuente de la falla de proyectos de ERP es la pérdida de datos precisos. Datos de inventarios, listas de materiales o asignación de rutas son tres de los culpables claves.

En un ERP integrado todo es necesario para asegurar la confiabilidad y precisión de los datos.

Las cuestiones claves son limpiar los procesos que hicieron crecer los datos malos y asegurar que, luego de la entrada del sistema en producción, habrá disciplina para mantener la calidad de los datos.

4-Asegurar que hay una línea de responsabilidad en el negocio para el éxito del proyecto.

Los gerentes de la empresa (Marketing, Operaciones, Finanzas, Producción y las otras) son responsables del éxito de la implementación y funcionamiento del ERP.

El equipo del proyecto debe responsabilizarse por entregar el mismo en sintonía con el negocio. La clave está en evitar que el equipo trabaje en una torre de marfil desarrollando procesos, sistemas, entrenando gente a usar el producto y demás tareas.

5-Asegurar que el 100% de las personas del negocio hayan sido educadas (no entrenadas) en el nuevo sistema y los modos de usarlo.

La diferencia entre educación y entrenamiento es crítica. Educar es cambiar el corazón y mente para aceptar la necesidad del nuevo sistema y los procedimientos formales que implica. Esto significa, entre otras cosas, evitar prácticas pobres como operar con doble juego de números (Ejemplo: uno para el presupuesto y otro para propósitos operacionales).

6-Usar una prueba o simulación como un método para experimentar y validar el sistema antes que el ERP ingrese en la etapa de producción.

La forma clásica para asegurar la aceptación de un sistema empresarial es ejecutar cuidadosamente guiones y rutinas piloto que prueben que las expectativas previstas para un grupo de transacciones producen los resultados esperados. Sin embargo, esto no prueba la potencia combinada del sistema, los procesos y personas trabajando todos simultáneamente y menos si la gente está preparada para realizar su trabajo en el nuevo escenario.

7-Asegurar que el sistema está basado en funcionalidades estándar.

Ciertamente, los ERP modernos poseen una enorme cantidad de funcionalidad construida. Y siempre, para los usuarios, es una tentación construir funcionalidad más compleja dentro de la aplicación.

Sin embargo, en muchos productos de software hay ocasiones donde el sistema “no hace lo correcto” por alguna razón. Y aquí se produce un conflicto pues pretenden que el sistema haga lo que ellos no saben explicar como hacer.

Después de todo, si necesita hacerse un tratamiento de conducto, usted querrá el menor de los sufrimientos como sea posible y que no tenga que repetirse. Y esto sucederá solo si toma el hábito de cepillar y limpiar sus dientes. ¿Es muy difícil?

Acerca del autor:

División de Consultoría de Evaluando ERP, es partner de información de APPLICAR.

Actualización tecnológica

noreply@blogger.com (applicar) — Fri, 27 Nov 2009 04:35:00 +0000

¿Cómo documentar proyectos? (2)

noreply@blogger.com (applicar) — Thu, 19 Nov 2009 16:37:00 +0000

Por: Jesús Ramírez

Para iniciar con el desarrollo de un proyecto es necesario contar con los siguientes documentos o sus equivalentes.

Enunciado del trabajo del proyecto.

Generalmente se encuentra en la orden de compra que emite u cliente que contrata nuestros servicios, es una descripción general de lo que se espera del proyecto y cómo debe hacerse. Si el proyecto surge por una iniciativa al interior de la empresa, entonces esta será la descripción del proyecto tal como lo indica la persona o grupo de personas que ideó el proyecto.

Caso de negocio.

Este documento también se conoce como plan de negocio, es el detalle de la evaluación que se hizo a la idea inicial del proyecto con su respectiva justificación y análisis de viabilidad. Este documento incluye además información financiera sobre los costos estimados del proyecto y el periodo de recuperación de la inversión

Contrato

Es el documento que indica que legalmente se ha iniciado el proyecto, establece las relaciones entre el equipo del proyecto y el patrocinador o patrocinadores del mismo. Este documento contiene muchos aspectos legales que no forman parte del proyecto en sí, por ello que se recomienda hacer un resumen de este documento sólo con la información relevante al proyecto y que permita desarrollar un proceso de planeación posterior. La información que debe extraerse de este documento incluye: fechas de corte, plazos de entrega, contraprestaciones, documentos entregables, etc.

Diagnóstico de la organización

Es necesario conocer de manera general cómo se desenvuelve la organización en la cual desarrollamos nuestro proyecto. Los elementos que debemos conocer son:

Factores del entorno de la organización
Procesos de la organización

Si la organización es nuestro centro de trabajo, entonces debemos documentarnos sobre los factores que pueden afectar a nuestro proyecto y los procesos que se desarrollan en ella y que podrían ser útiles o podrían estorbar el avance de nuestro proyecto

Si la organización que busca desarrollar el proyecto es un cliente de la nuestra entonces debemos estudiar los puntos que corresponden al proyecto y que podrían entrar en conflicto con las áreas funcionales del cliente, esto para evitar duplicidad de funciones. Así mismo debemos conocer el desarrollo que a tenido el cliente en el mercado y los problemas potenciales que enfrenta y que podrían afectar a nuestro proyecto.

Todos los documentos anteriores permiten recoger los datos más importantes que llevarán al desarrollo del plan del proyecto.

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

Creación de demanda: 5 métricas que importan

noreply@blogger.com (applicar) — Mon, 16 Nov 2009 17:59:00 +0000

Por: Daniel M. Aisemberg

Hay cinco métricas simples que pueden ayudar a medir la contribución de marketing. Métricas tales como impacto del mensaje, tasa de respuesta y otras a las que se podría prestar atención pueden significar muy poco para el resto de la organización. Sin embargo, hay 5 métricas que brindan un panorama rápido sobre la consistencia de la estrategia de demanda y cómo marketing contribuye con el embudo de demanda.

Registros de consultas

La primera métrica es el combustible que da movimiento al motor de creación de demanda.

Cuando las campañas se ponen en marcha, ejecutan y finalizan, la primera pregunta que se hace la organización es cuántas filas de consultas/ respuestas o interesados se generaron.

En algún momento usted querrá conocer tasas tales como:

Consultas/ respuestas, interesados fruto de las campañas ejecutadas versus nuevos prospectos.
Oportunidades generadas por Cross-Selling o Up-Selling en clientes actuales.

Estos números se tornan críticos cuando trabaja su embudo de oportunidades (Funnel) con una mirada desde la parte superior hacia la parte inferior, calculando tasas de conversión.

¿Está generando el suficiente número de consultas/ respuestas o interesados para alimentar las oportunidades?

Oportunidades calificadas por marketing (OCXM)

Con un grupo de consultas/ respuestas en la mano, el trabajo de marketing es nutrir con oportunidades calificadas a ventas de acuerdo a parámetros acordados mutuamente. Para algunas organizaciones la alimentación a ventas puede ser tan rudimentaria como un pase de datos desde telemarketing. Para muchas otras la alimentación a ventas debería incluir interacciones adicionales y una valoración que brinde un fundamento para convertir al prospecto en una oportunidad.

Cuando un dato estimado como prospecto vale la pena pasarlo a ventas, es decir, cuando cumple con la Definición Universal de Oportunidad (DUO) previamente definida, se puede decir que se tiene una oportunidad calificada por marketing (OCXM).

Entonces, la segunda métrica importante es:

Tasa de conversión de consultas/ respuestas en OCM.

La evolución de esta tasa puede demostrar cómo mejora la prospección trimestre a trimestre.

Aceptación de ventas

Con una DUO clara y consensuada entre marketing y ventas, la organización está en condiciones de tener un proceso formal de aceptación sea que las oportunidades provengan de un externo, de un proceso interno o de un canal.

El acuerdo creado entre marketing y ventas debería incluir tanto los pasos a seguir por el personal de ventas como el resultado de la gestión en un marco de tiempo establecido.

El personal de ventas que acepta una oportunidad que responde a la DUO está haciendo mucho más que recibir un dato. Las oportunidades recibidas solo pueden ser rechazadas por muy pocas razones:

Procedimiento incorrecto: la oportunidad fue encaminada incorrectamente. Por ejemplo, pertenece al mercado de laboratorios y no al de medicina.
Errores administrativos: el registro está incompleto o mal completado.
Conceptual: no encaja en el mercado objetivo, no alcanza un umbral mínimo.

Con la aceptación de la oportunidad, el personal de ventas acepta realizar seguimiento y gestión y devolver resultados en un marco de tiempo determinado (no más de 72 horas laborables).

La tercera métrica crítica es:

Oportunidades aceptadas por ventas.

Bajas tasas de aceptación indican que hay algún tipo de quiebre en el proceso entre marketing y ventas.

Oportunidad calificada por ventas (OCXV)

Por aceptar una oportunidad, el personal de ventas no tiene otro compromiso más que recibir un dato que responde a la DUO. Después de una serie interacciones (llamados, e-mails, reuniones), el Ejecutivo Comercial tiene suficientes evidencias para determinar si la oportunidad existe. Cuando esto sucede, se está en presencia de una oportunidad calificada por ventas (OCXV). Mientras no pueda ser predecible la conversión en contrato (cierre) de esta oportunidad en un plazo no mayor a 90 días (forcasteable) es parte del embudo de ventas.

La métrica crítica en este estado es:

Tasa de conversión de oportunidades aceptadas en OCXV.

Negocios cerrados

Aunque mucho sucede con una oportunidad cuando sale del control de marketing, conocer y analizar la cuarta métrica:

Tasa de OCXV convertidas en negocios cerrados

Esta métrica es crítica para el responsable de detección y generación de demanda. En primer lugar para entender la expectativa de facturación en función del dinero invertido en marketing.

En segundo lugar, esto conduce a marketing a comprometerse más con el proceso de demanda, creando y usando herramientas más efectivas. Como socio de negocios de ventas, marketing aumenta las probabilidades de encontrar oportunidades al inicio del proceso, con poco desperdicio de recursos.

Resumiendo

Registro de consultas/ respuestas o interesados.
Tasa de conversión de consultas/ respuestas en Oportunidades calificadas por Marketing (OCXV)
Oportunidades aceptadas por ventas.
Tasa de conversión de oportunidades aceptadas por ventas en oportunidades calificadas por (OCXV).
Negocios cerrados.

Acerca del autor:

Daniel M. Aisemberg es Director de IMPLANEX, que es partner de información de APPLICAR.

The Fun Theory

noreply@blogger.com (applicar) — Fri, 13 Nov 2009 04:23:00 +0000

DDB Stockholm ha lanzado para la Volkswagen una campaña interesante. Esta campaña se fundamenta en que la mejor forma de conseguir que las personas realicen cambios positivos en sus vidas es a través de la diversión. Esta iniciativa se denomina "The Fun Theory" o en alemán "Rolighetsteorin". A continuación los tres videos que promocionan esta campaña

El bote de basura más profundo del mundo

132% más basura recolectada que en el bote de basura más cercano

Las escaleras piano

66% más personas usaron las escaleras comunes antes que las eléctricas

El juego del bote para botellas de vidrio

4900% más veces fué usado el juego del bote para botellas que su similar mas cercano

Finalmente, los trabajos de las personas que participan en el concurso por €2500

http://www.thefuntheory.com/award-entries

Procedimientos en Gerencia de Proyectos con OPM3®

noreply@blogger.com (applicar) — Wed, 11 Nov 2009 06:34:00 +0000

Por: María del Socorro Arias Ramírez

El OPM3® (Organizacional Project Management Maturity Model) es un modelo de madurez que permite identificar aquellos procesos prioritarios para el desarrollo de capacidades organizacionales en gestión de proyectos.

Este modelo fué aplicado en una empresa que busca pasar de la coordinación y supervisión de obra a la gestión de proyectos. El enfoque de los sistemas, permitió identificar las relaciones entre los colaboradores de la empresa.

Procedimientos en Gerencia de Proyectos con OPM3®

View more documents from APPLICAR.

María del Socorro Arias Ramírez es Directora General de APPLICAR

¿El ERP toma el control de las compañías? Una réplica de Gran Hermano dentro de la empresa

noreply@blogger.com (applicar) — Mon, 09 Nov 2009 08:39:00 +0000

Por: División de Consultoría de Evaluando ERP

Autoriza o desautoriza una acción, informa a los superiores, maneja la vida de cientos de trabajadores, es protagonista de las expulsiones, muchos tratan de ocultarle cosas, pero él sabe todo lo que pasa. En la empresa todos le temen y respetan. Nadie se animaría a hacer algo sin su consentimiento. Y aunque parece que fuera Gran Hermano, es solo un ERP.

Del registro al control

El ERP comenzó humildemente registrando los movimientos contables de las compañías. Poco a poco fue asumiendo mayores responsabilidades:

Emitir facturas, recibos de sueldo.
Procesar órdenes de compra, y todo.
Registrar y procesar movimientos transaccionales de las empresas.

El ingreso de los movimientos transaccionales pasó a ser una función muy básica y el eje de atención se desplazó hacia la integridad de los datos. Para entonces los ERPs comenzaron a incluir reglas de validación pre registral. Por ejemplo, para emitir un remito un ERP de cierto nivel de sofisticación comenzó a exigir que la mercadería efectivamente se encuentre en el stock, y si esta regla no se cumplía era imposible terminar dicha transacción.

A medida que los productos evolucionaron desde el registro hasta la inserción de reglas de control en la emisión de transacciones los objetivos de gestión y control fueron creciendo.

Desde la simpleza inicial de verificación de stock la evolución llegó a funciones tan complejas como la verificación automática de score crediticio para los clientes, o la generación y control del presupuesto.

La voluntad de los directorios

En un principio los controles quedaron bajo estricta definición gerencial. Se trataba de reglas que simplemente economizaran tarea de control administrativo.

Hacia fines de los 90 los directores a cargo de las grandes compañías entendieron que el ERP era un modo muy eficaz de controlar a las gerencias.

Hasta ese momento la auditoría era la función y la práctica que verificaba lo actuado por la gerencia de la compañía. En el mejor de los casos efectuaban “autopsias” de compras mal realizadas e imposibles de revertir, o de políticas de descuento que conducían a la ruina.

Mediante la introducción de controles en la generación de las transacciones el control pasó de realizarse sobre los hechos consumados, a efectuarse antes de que las cosas ocurran. Mientras que en la pre historia del ERP se controlaban las transacciones, en la época actual se controla la aplicación de reglas de negocios.

Por ejemplo, un gerente de compras no puede emitir una orden de provisión que supera el presupuesto establecido, simplemente porque el sistema no emite el documento necesario. Del mismo modo, ante una transacción que no es estándar, es usual que el vendedor de una firma de electrodomésticos, o de un supermercado nos diga: “voy a ver si la computadora lo acepta”. Es decir va a probar si lo que quiere hacer es aprobado por el gran hermano, o sea, el ERP que, finalmente representa la voluntad de la dirección de las compañías.

¿Hacia el control total?

Sin duda que el control de los ERPs sigue avanzando. Cada vez más la gente que vende, compra o gerencia está más controlada por mecanismos cibernéticos que le permiten hacer o no hacer algo. Entonces la pregunta surge naturalmente: ¿Cuántas de esas personas serán reemplazadas por los sistemas en los próximos 10 años? No creo que veamos aparecer a las empresas manejadas sin gente. Pero, poco a poco, el sistema de gestión empresarial va conquistando nuevos territorios o haciendo alianzas con otros sistemas para alcanzar los recónditos procesos de negocios en los que no tiene presencia.

Acerca del autor:

División de Consultoría de Evaluando ERP, es partner de información de APPLICAR.

Lección en Gerencia de Proyectos

noreply@blogger.com (applicar) — Fri, 06 Nov 2009 19:12:00 +0000

Nunca empieces un proyecto a menos que tengas todos los recursos disponibles.

¿Cómo documentar proyectos? (1)

noreply@blogger.com (applicar) — Wed, 04 Nov 2009 14:54:00 +0000

Por: Jesús Ramírez

Durante el desarrollo de los proyectos es necesario documentarlos de forma rápida y eficiente. Pero, ¿Cuáles son los documentos básicos con los que se debe contar en un proyecto?

Existen tres documentos principales, los cuáles deben estar siempre presentes en el desarrollo de cualquier proyecto, cada uno de estos documentos tiene una finalidad específica y permitirá conocer el proyecto en toda su extensión sin necesidad de incurrir en papeleo excesivo.

Dichos documentos son:

Carta de Proyecto. Autoriza formalmente el proyecto. Se recomienda revisar la guia: ¿Cómo elaborar una Carta de Proyecto?.

Enunciado del Alcance del Proyecto. Establece el trabajo que debe realizarse y los productos entregables que deben producirse.

Plan de Gestión del Proyecto. Establece cómo se realizará el trabajo del proyecto.

La figura representa estos tres documentos y la relación con sus componentes. El plan de gestión del proyecto está compuesto por los planes y documentos generados por los distintos procesos. Esos elementos son los planes subsidiarios y componentes del plan de gestión del proyecto.

Se presentarán más definiciones y detalles sobre la documentación de proyectos en las siguientes entregas de esta serie.

Acerca del autor:

Jesús Ramírez es colaborador de APPLICAR en temas de planeación, proyectos, procesos y sistemas de información.

Cómo mejorar su tasa de cierres de ventas vendiendo valor en lugar de precios

noreply@blogger.com (applicar) — Sun, 01 Nov 2009 22:47:00 +0000

Por: Daniel M. Aisemberg

Formular las preguntas correctas es más importante que contar con las mejores respuestas. Hay siete interrogantes importantes que pueden ayudarle a identificar el potencial de cada oportunidad. Hágalas y escuche activamente la respuesta. Si está vendiendo soluciones, usted necesita saber cuál es el problema de su prospecto. En caso contrario, usted nunca tomó la cuestión con un serio problema a resolver. Y no hay forma de saber lo que el prospecto piensa o siente si no es preguntando.

Hay muchos métodos de ventas consultivas en el mercado. Usted puede entrenarse en uno o leer un libro. Cada uno de ellos posee sus técnicas y fortalezas. Pero todos tienen, al menos, una cosa en común. Usted construye un “momentum” de ventas demostrando que está brindando una solución importante para resolver un problema importante. Esta es la esencia de todas las metodologías de ventas consultivas.

Para estar en condiciones de crear una solución centrada en el cliente y de escribir una propuesta centrada en el cliente, hay 7 preguntas que usted debe ser capáz de responder.

1. ¿Cuál es el problema del prospecto?

Mire detrás de toda evidencia obvia. Su contacto en la organización del prospecto describirá el problema en términos que están relacionados con sus intereses. Por ejemplo, para un gerente de TI se preocupa por la pérdida de acceso en línea a los datos de un cliente; para el Gerente de Ventas se trata de un problema de facturación porque el problema no permite que la fuerza de ventas separe los buenos clientes de los que no lo son.

2. ¿Por qué es un problema?

¿Quiénes están afectados por el problema? ¿Cómo los afecta? Trate de dibujar los enlaces o vínculos organizacionales tanto como para sentir cuán grande es el problema. Esto le indicará quienes más deberán ser parte del equipo de decisión.

3. ¿Qué objetivos tiene el prospecto en mente para una solución satisfactoria?

¿Cómo medirá el prospecto el éxito? ¿En términos de negocios o de desempeño financiero? ¿En términos de mejoras en la infraestructura tecnológica? ¿En términos de lealtad de clientes o de moral de los empleados? Cada una de estas áreas (resultados de negocios, mejoras técnicas o relaciones sociales) es potencialmente importante. Esto nos lleva a la siguiente pregunta.

4. ¿Cuál de estos objetivos es el más importante?

Todos los objetivos son importantes pero, seguramente, hay uno que es el más importante. Conocer esto le da dos indicaciones: en primer lugar, esto le dice a usted el orden en el cuál debe colocar los puntos clave de su presentación. Debe colocar los resultados más importantes para su cliente en primer lugar. El cliente pensará que lo que usted piensa está alineado con sus pensamientos. En segundo lugar, conociendo cuál es el objetivo más importante, usted puede desarrollar su propuesta con mayor certidumbre.

5. ¿Cuáles son los caminos por los que podemos resolver el problema del prospecto?

Generalmente hay más de una vía para resolver un mismo problema. No se conforme con el primero que le viene a la mente. No es el único y, probablemente, sea el peor pues su generación no requirió demasiado esfuerzo intelectual.

6. ¿Cuáles son los probables beneficios de cada solución potencial?

Cualquier juego de potenciales soluciones se harán cargo de resolver el problema. Sin embargo, el tema es qué clase de resultado está esperando el prospecto.

7. ¿Cuál es la mejor solución?

Basado en las respuestas a las 6 preguntas anteriores, usted está en condiciones de responder la última pregunta. Esto debería conducir al encuentro entre las necesidades a resolver y la entrega de los resultados que el prospecto desea.

Acerca del autor:

Daniel M. Aisemberg es Director de IMPLANEX, que es partner de información de APPLICAR.