Archivo enero, 2009

Los trolls de los blog

Cito textualmente un post referente a trolls con el link a la página original. De momento no tenemos ninguno por aquí. Esperemos que este artículo no los llame a venir.

Extraído de: http://ww2.grn.es/merce/2008/trolls.html

10/04/08 17:23:36

NO RESPONDAS A ESE “TROLL”

Mercè Molist
Los buscabroncas en Internet tienen nombre propio: “Trolls”. Posiblemente los haya visto escribiendo comentarios incendarios en algún foro o “blog” y sabrá que afearles la conducta no sirve de nada. Los “trolls” disfrutan haciendo perder los estribos, buscan llamar la atención, vengarse de alguien o sabotear el sitio. Lo mejor es pasar olímpicamente de ellos.

Como cualquier comunidad humana, las zonas de charla de Internet tienen sus propias leyendas y mitos. Uno de ellos es el “troll”, un personaje usualmente anónimo que manda comentarios groseros a foros, chats y blogs. No entran en este concepto quienes se dejan llevar por una calentura momentánea. El “troll” lo hace siguiendo una fría estrategia.

Aunque la palabra remite a los ogros de los cuentos, su uso en Internet proviene del verbo inglés “to troll”, que significa pescar con cebo: el mensaje insultante o bromista del “troll” actúa como anzuelo para que piquen los más sensibles, respondan en masa y se arme la de Dios.

Nada gusta más a un “troll” que provocar montañas de mensajes de protesta. Y si la bromita degenera en una “guerra incendiaria” (“flame war”, en inglés), mejor. Se llama “guerras incendiarias” a las discusiones subidas de tono. El “troll” las crea y también las aviva. Algunas han provocado el cierre del foro en cuestión.

Los “trolls” adoptan personalidades ficticias o bien impersonan a los miembros legítimos del foro. Envían mensajes fuera de tema, hacen preguntas tontas o insultan. Son inmunes a las críticas que provocan. Les divierte irritar a los internautas más inocentes o irascibles, quienes no se percatan de que se está jugando a provocarlos.

En su ensayo “Trolls de Internet”, Timothy Campbell explica: “Los “trolls” no captan que hieren a gente real. Para ellos, los demás usuarios no son del todo humanos sino una especie de abstracción digital. Como resultado, no sienten ningún tipo de pena por el dolor que infligen. De hecho, cuanto mayor sea el sufrimiento que causan, mayor es su logro”.

Por eso se utiliza la frase “No alimentes al troll” cuando uno de ellos entra en escena. Campbell asevera: “Devolver los insultos a un “troll” sólo sirve para incitarle, por lo que no responderle es anularle. Si intentas razonar con un “troll”, él gana. Si insultas a un “troll”, él gana. Si chillas a un “troll”, él gana. Lo único que los “trolls” no pueden aguantar es que se les ignore”.

Neal Stephenson, en su libro “Cryptonomicon”, también hace referencia a estos personajes: “Discutir con extraños anónimos en Internet es un juego de bobos porque casi siempre acaban siendo quinceañeros con ínfulas de superioridad y una gran cantidad de tiempo libre, o gente indistinguible de estos”.

Para algunos es un deporte, con trucos propios, como invocar a su libertad de expresión o amenazar con denuncias. También se practica en grupo, como explica el “Manual de Invasión de un Foro”: “El equipo observa durante un tiempo el foro que quiere atacar. Cada “troll” decide qué personaje falso será y pacta una forma de comunicación privada para ir reconduciendo la estrategia”.

El primer asalto es subterráneo: los “trolls” participan en el grupo como un contertulio más, sin crear polémica. En el momento pactado, uno de ellos manda el mensaje incendiario. El resto sembrará la confusión respondiendo airadamente”.

La victoria, explica el manual, llega cuando se ha conseguido sembrar totalmente la discordia: “Los habituales del foro lo abandonan, la mayoría de conversaciones son discusiones, los “trolls” reciben mensajes privados con insultos y el moderador del foro amenaza con echarles”.

TIPOS DE “TROLLS”

1. EL DIRECTO. Envía un mensaje con un título sumamente inflamatorio que garantiza réplicas furiosas, a las que responderá inmediatamente. Por ejemplo llamar “racistas asquerosos” a un foro de “skinheads”.

2. EL TONTO. Envía un mensaje con un título divertido y un texto estúpido con la intención de gastar una broma. Por ejemplo, preguntar en un blog de pesca: “¿Cómo era para poner un anzuelo?”.

3. EL GOLPEA, CORRE Y MIRA. Manda un mensaje provocativo para que la gente se pelee. Por ejemplo, en un foro de animales domésticos, asegurar que los perros son mejores que los gatos, para enfrentar a sus dueños.

4. EL ESTRATEGA. Empieza mandando mensajes normales que cada vez serán más provocadores. Por ejemplo, preguntar a un grupo de fanáticos de los alienígenas: “¿Cómo sé si he sido abducido?”. A medida que le vayan respondiendo en serio, mandará nuevos mensajes con detalles cada vez más surrealistas para tomarles el pelo.

5. EL VENGATIVO. Es el “troll” más visceral. Suele ser un habitual del foro que ha cogido ojeriza a una persona o a todo el grupo y les manda mensajes públicos insultantes.

6. EL PERSISTENTE. Persona extraña y conflictiva que aterriza en un foro y se queda una buena temporada, sin importarle las críticas a sus mensajes. Suele interpretar un papel, como hacerse pasar por franquista.

7. EL “CASCADA”. Persigue generar el mayor número posible de respuestas a sus provocaciones. Cuando ve que la discusión que ha generado flojea, la aviva mandando más.

8. EL TÍTERE. Utiliza identidades diferentes para participar en un mismo foro, respondiéndose a sí mismo como si fuese dos personas. Por ejemplo, si una de sus identidades inicia una discusión, usa la otra para respaldarla o incluso criticarla.

FAMOSOS “TROLLS” ESPAÑOLES

Pedro Castilla
Nombre falso. Se hizo famoso a finales de los años 90 en los grupos de discusión españoles por sus mensajes fascistas, a favor de la raza blanca y la aniquilación de vascos, drogadictos, homosexuales y sindicatos.

Chari Ferrer
Nombre falso. Busca blogs donde se hable de cultura libre para mandar mensajes a favor del sistema tradicional de “copyright”. Es el primer “troll” de la historia a quien dan un premio: fue la Asociación de Compositores y Autores de Música, en 2005, por “sus incursiones surrealistas, teñidas de intenso humor guerrillero”.

Nennito
Nombre falso. Especialista en insultos y hablar de sexo, su principal campo de actuación son los grupos de noticias españoles, donde inicia discusiones que mantiene hasta el aburrimiento.

MÁS INFORMACIÓN

¿Qué son los trolls?
http://personal.telefonica.terra.es/web/modestogarrido/usenet/docs/trolls.html

Los troll del ciberespacio
http://esuntroll.blogspot.com

Trolls de Internet. Timothy Campbell
http://www.newsgrupos.com/es-charla-economia-bolsa/2732-ot-que-es-un-troll.html

Troll. Wikipedia
http://es.wikipedia.org/wiki/Troll_de_Internet

Troll FAQ
http://www.faqs.org/ftp/faqs/net-abuse-faq/troll-faq

The alt.troll FAQ
http://groups.google.com/group/alt.troll/msg/bc2e71e19c590d8e

Guide To Flaming
http://www.flayme.com

The Flamers Bible
http://www.netfunny.com/rhf/jokes/88q1/13785.8.html

Copyright 2008 Mercè Molist.
Verbatim copying, translation and distribution of this entire article is permitted in any digital and no commercial medium, provide this notice is preserved.

No hay Comentarios

Como realizar el análisis inicial para implantar un ERP

En este artículo, intentaremos detallar los aspectos más relevantes que deberán quedar reflejados en la elaboración de un análisis inicial de la empresa en la que se va a implantar un ERP.

Cada punto mencionado debería ser ilustrado en detalle para ofrecer una visión global pero a la vez clara y resumida de los principales procesos de negocio de la empresa.

Se recomienda que toda empresa que vaya a acometer la implantación de un ERP, realice este análisis inicial, previamente a la selección de la empresa consultora o propietaria del software que realizará la implantación. Si se le entregan los requerimientos de la empresa detallados, el presupuesto será más detallado, se podrá realizar un plan de proyecto mucho más ajustado a la realidad y posiblemente se evitarán a posteriori  sorpresas desagradables.

En principio, vamos a pensar en un análisis inicial que cubra únicamente las áreas básicas de la empresa (compras, ventas (Incluido Marketing y CRM),  logística, tesoreria, Recursos humanos )

Como mínimo, un análisis inicial debe contener los siguientes aspectos:

Análisis de datos Maestros:

Los datos maestros de un ERP, son aquellos datos críticos y necesarios para poder empezar a operar con la herramienta. En función de cómo se configuren estos datos maestros, la herramienta permitira realizar ciertas acciones o no, o su comportamiento será distinto en algunos aspectos.

Ejemplos:

  • Si en ficha maestra de un cliente le asignamos una forma de pago transferencia bancaria, evidentemente el sistema no generará ningún recibo, por tanto, en la ficha maestra definimos la forma de cobrar a este Cliente.
  • Si en la ficha definimos que un proveedor nos exige un pago los días 10 de cada mes, cuando nosotros habitualmente pagamos los días 5 y 20, deberá quedar reflejado en la ficha del proveedor, y parametrizar la herramienta para que contemple esta situación.
  • Si requiero realizar un pedido a un proveedor, en las fichas maestras o maestros, debe estar registrado el proveedor, el artículo que le queremos comprar, el precio de dicho artículo con las condiciones de tarifa del proveedor….

En fin… existen una serie de datos que si previamente, o en el momento de necesitarlos no se registran, no se puede trabajar con el sistema. Estos datos serían los maestros.

La acción de configurar estos maestros, sería la más complicada de la fase de implantación. Si no se hace correctamente, será imposible que el comportamiento del programa sea el esperado.

A continuación redactaré qué datos maestros son imprescindibles analizar en una empresa standar de tamaño medio. Son todos los que están, pero no están todos los que son.Es necesario destacar que cada sector de negocio tendrá sus propios datos maestros y de aquí surge a veces la necesidad de crear módulos adicionales para el ERP que configuran una solución Vertical para dicho sector.

La tabla adjunta pretende al menos nombrar aquellos maestros existentes en todas las empresas de los sectores de industria y servicios.

Para cada uno de ellos, en el análisis inicial se reflejará cómo es actualmente y qué se espera que se pueda registrar y centralizar en el ERP a futuro. Se incluirá cualquier dato que se considere relevante.

  1. Mi empresa
  2. Catálogo de productos
  3. Almacenes
  4. Clientes
  5. Proveedores
  6. Tarifas de Venta
  7. Tarifas de compra
  8. Formas de pago

Mi empresa (Todos los módulos)

En este apartado incluiremos datos relevantes de mi empresa.

  • Estructura departamental.
  • Sedes y ubicaciones
  • Volumetría de empleados
  • Días de pago a proveedores
  • Días de pago de nóminas…
  • Otros

Empleados (Todas las áreas)

Un empleado puede ser un agente de ventas, un administrativo, un operario de máquina en fabricación, jefes de proyecto…

El concepto empleado es utilizado por casi todos los módulos del ERP donde sea necesario especificar quien hace qué. Operarios de fabricación, Agentes de Venta, Tecnicos de soporte en CRM, administrativos… etc, etc.

  • Datos de empleados
  • Calendarios
  • Horarios
  • Turnos
  • Grupos
  • Categorización
  • Nivel
  • Vacaciones
  • Skills
  • Edad media de los empleados
  • Ubicación física en la empresa.
  • Política salarial de la empresa: Configuración de Rangos salariales, primas, extras (solo requerido en el módulo de nóminas)

Esta parte del análisis es primordial ya que permitirá entre otras cosas:

  • Dimensionar el número de puestos que será necesario habilitar para trabajar con la nueva herramienta
  • Orientar sobre la formación previa en informática de los futuros usuarios y su edad lo que permitira dimensionar y planificar las jornadas de formación.
  • Obtener una visión general de la estructura de permisos y usuarios de la aplicación.

Catálogo de Productos (Logistica, Materiales, Compras, Ventas…)

En este apartado, especificaremos cómo es nuestro catálogo. Algo aparentemente trivial, puede ser el escollo más importante a salvar en una implantación. Existen infinidad de formas de registrar y categorizar los productos de una empresa. Es necesario definir al menos los siguientes aspectos:

  • Tipología de artículos
    • Qué compro
    • Qué vendo
    • Qué fabrico
  • Categorías de artículos
  • Volumen de artículos codificados.
  • El código del artículo. Referencias:
    • Como identifico mi artículo como único. Ojo, no solo tengo que categorizar el que vendo, sino también el que compro y el que transformo.
    • El código será secuencial, o me dará información de forma inteligente, utilizando bloques de cifras para indicar algo dentro de dicho código…
  • Datos adicionales de mi artículo. Como varían en función de la tipología y de las categorías.
  • Unidades de medida en las que compro, vendo y almaceno el artículo.
  • Serialización y números de lote de los artículos. Qué tipologías y categorías de artículos es necesario que lleven números de lote o serial. Quién genera dicho número de lote y cómo se genera.
  • Atributos o variantes del artículo (Color, talla, medidas…etc, etc).  Categorización y tipología de los artículos en los que varía el precio de venta o compra en función de los atributos.
  • Indicar si requieren imágenes o no. Cuantas. La imagen se registra a nivel de producto o a nivel de variante.
  • Indicar si requieren registro de documentos adjuntos. Cuantos. Cuales. Qué formatos.

En el análisis del catálogo se incluirá cualquier aspecto que se considere de interés o inherente al sector que pudiese causar conflicto en su configuración en el ERP.

Almacenes (Logistica)

Cuantos y donde tengo almacenes.  Información y características relevantes de cada almacén

Clientes (Ventas, CRM)

Aquí incluiremos datos relevantes que desee registrar de mis Clientes.

  • Volumetría
  • Codificación de Clientes
  • Datos generales
  • Categorización de Clientes
  • Contactos de Clientes
  • Estructura de empresa de mis Clientes
  • Datos asociados a esta estructura
  • Sedes de Clientes.
  • Direcciones y tipología de dirección (sede, almacén, oficina administración… etc)
  • Formas de pago
  • Bancos
  • Etc…

Canales de Venta

  • Agentes comerciales
  • Tiendas físicas
  • Tiendas On-Line

Proveedores (Compras)

Aquí incluiremos datos relevantes que desee registrar de mis Proveedores

  • Volumetría
  • Codificación de Proveedores
  • Datos generales
  • Categorización de Clientes
  • Contactos de Proveedor
  • Estructura de empresa de mis Proveedores
  • Datos asociados a esta estructura
  • Sedes de Proveedor.
  • Direcciones y tipología de dirección (sede, almacén, oficina administración… etc)
  • Formas de pago
  • Bancos
  • Etc…

Tarifas de Venta (Ventas)

Las tarifas de venta son un aspecto fundamental en la configuración del ERP. Pueden ser dinámicamente calculadas en función de otros campos (la más sencilla: tarifa de compra + %margen), o asignadas para cada uno de los artículos.

En el análisis es necesario reflejar como se realiza en la actualidad esta asignación de tarifas venta a los productos a fin de evaluar la complejidad de su configuración.

Teniendo en cuenta la categorización y tipificación de los productos de venta:

  • Indicar cómo se calcula la tarifa
  • Indicar si se existen o no descuentos por volumen
  • Indicar cómo se configuran las ofertas
  • Indicar si existen packs de productos en oferta
  • Indicar cualquier aspecto relevante referente a las tarifas de venta.

Tarifas de Compra (Compras)

  • Indicar cómo se reciben las tarifas de proveedor
  • Indicar cómo se registran las tarifas de proveedor
  • Indicar si se existen o no descuentos por volumen
  • Indicar cómo se configuran las ofertas
  • Indicar si se recepcionan packs de productos en oferta
  • Indicar cualquier aspecto relevante referente a las tarifas de compra.

Formas de pago (Tesorería)

  • Indicar formas de pago que se utilizan habitualmente en cualquier área de gestión de la empresa (Transferencia, Cheque,  Giro, Pagaré, tarjeta de crédito, facturing, confirming… etc, etc.)

Formas de envío y Transporte(Logistica). Tarifas.

  • Indicar formas de envío que se utilizan habitualmente (Camión propio, Camión de Cliente, Camión de Proveedor, Agencia de transporte, Agencia de mensajería…)

Indicar qué forma de envío es utilizada en función de qué condiciones. Y sobre todo, marcar las excepciones.

Ejemplos:

  • Un proveedor me envía la mercancía en su camión pero me cobra los portes. Habitualmente el resto de proveedores, me envían una agencia de mensajería, que también pago yo.
  • En cuanto a envíos de mercancía a Clientes, tengo una furgoneta de reparto, que utilizo para servir los pedidos locales, para la península utilizo una agencia de transporte.
  • A clientes con pedidos superiores a una cantidad, les envío la mercancía con un 20% de descuento en la tarifa habitual.

Embalajes, volumen y peso (Logistica).

Definir la información requerida para los embalajes:

  • Tipificación de embalajes
  • Códigos de embalaje
  • Asociación de embalajes a artículos, a volúmenes, a pesos…

Cualquier información relevante a embalajes.

Ejemplo: Envío mi mercancía en contenedores. La agencia de transporte me cobra por contenedor con un límite de peso, independientemente del número de bultos que incluyo. Requiero registrar tamaños y volúmenes de embalajes, materiales que la componen, relación de artículos con embalajes.

Plan de cuentas contable (Contabilidad)

Imprescindible en el área de contabilidad, si el plan contable no está definido correctamente será imposible llevar las finanzas con el ERP.

  • Definición de la estructura del plan contable.
  • Relación de estructura contable con codificación del área de gestión.

Una vez definidos estos aspectos podriamos hablar  de que tenemos una visión general de los datos maestros de la empresa en las áreas mencionadas y podriamos comenzar a definir los procesos operativos.

Procesos de negocio de la empresa (Workflow de procesos):

En este apartado incluiremos en la medida de lo posible los procesos actuales de la empresa. Es necesario al menos indicar 2 niveles de procesos:

Nivel 1: Procesos interdepartamentales:

  • Cuales son las áreas/dptos en los que se divide la empresa
  • Cómo interactúan entre ellas:
    • Flujos de documentos
    • Procesos de aceptación, validación, asignación de tareas…
    • Herramientas utilizadas

Ejemplo muy simplificado de un proceso interdepartamental

  • Cliente realiza pedido de venta (Att Cliente)
  • Se verifica si existe stock del producto en almacén (Logística)
    • Si existe, se sirve al Cliente. (Logística)
    • Si no existe y el producto es de distribución
      • Se realiza pedido de compra a proveedor. (Compras)
      • Se recepciona el material (Logística)
      • Se verifica su calidad (Calidad)
        • Si pasa el control, se incluye en almacén (Logística)
        • Si no pasa el control
          • Se devuelve al proveedor (Logística).
          • Compras gestiona la devolución (Compras)
          • Att Cliente indica el retraso en la entrega al Cliente y facilita nueva fecha de entrega (Att Cliente)
    • Si no existe y el producto es de fabricación, se fabrica (fabricación)
      • Se verifica su calidad (Calidad)
        • Si pasa el control, se incluye en almacén (Logística)
        • Si no pasa el control ….
      • Se almacena y se sirve al Cliente. (logística)

En este ejemplo,  se puede comprobar que intervienen distintos departamentos desde que se recibe el pedido del Cliente hasta que es posible entregarlo.  Entonces, actualmente ¿como se gestiona esta comunicación interdepartamental?

  • Como se registran los pedidos
  • Como se comunica att cliente con compras para indicarle que tiene que hacer un pedido
  • Como sabe fabricación que tiene que fabricar un producto y cómo lo tiene que fabricar. Como sabe fábrica a qué fecha debe tener fabricado el producto.
  • Como conoce ventas las incidencias que ha habido desde que el Cliente hizo el pedido y como sabe que tiene que avisarle de un retraso en la entrega…

En fin, cuanto más se detalle este proceso interdepartamental más sencillo resultará configurar los flujos de información correctos en el ERP.

Nivel 2: Procesos intradepartamentales (Dentro de un mismo área/dpto)

Al igual que el proceso a primer nivel, es necesario realizar el mismo ejercicio, pero dentro de un mismo área/dpto.

Por cada área/Dpto se indicará:

  • Cómo se trabaja
  • Quien hace qué
  • Cómo lo hace
  • Qué herramientas usa actualmente

En el mismo ejemplo utilizado anteriormente, se pueden dar infinitas combinaciones de formas de trabajar. Pongamos un ejemplo irreal pero posible de una empresa ficticia:

  • Att Cliente recibe un pedido de venta:
    • Existen 3 canales de entrada de pedidos de venta:
      • Teléfono, Fax
      • E-mail
      • Tienda On-Line
    • Hay un agente de ventas asignado a cada canal.
    • Cada agente recepciona únicamente los pedidos que entran desde dicho canal.
    • Al recepcionar un pedido, se registra en un access.
    • Posteriormente se envían por e-mail al almacén para que verifiquen in-situ si tienen stock o no. Los agentes del canal de Fax, Teléfono y Tienda on-line registran el pedido en el access y además lo copian en outlook para enviar el e-mail a almacén.
    • A veces, los clientes que realizan el pedido por teléfono también envían un e-mail, por si acaso.
    • El agente que atiende el canal e-mail, no sabe que el del teléfono ya ha registrado el pedido en el access por lo que se registra el mismo pedido 2 veces por 2 personas distintas, con distinto número.
    • Almacén recibe 2 e-mails solicitando la misma cantidad de producto para el mismo Cliente pero por el volumen diario de pedidos, no identifica que se trata del mismo pedido duplicado.

Como se puede comprobar, ya en el primer punto de nuestro proceso interdepartamental, ya hemos detectado que existen puntos de mejora que ahorrarían  tiempo, errores y en definitiva costes.

  • En Att Cliente, registran el pedido 2 veces. Una en el access y otra para enviarlo por e-mail a almacén.
  • No existe comunicación entre los distintos agentes del dpto. No conocen si otro agente ya ha tratado el pedido.

A partir de este punto, donde el error ya se ha producido, si continuasemos con el ejemplo, este Cliente podría acabar recibiendo 2 pedidos iguales, pero con una diferencia importante de tiempo. Llevando el ejemplo al límite, supongamos que en almacén recepcionan el primer pedido, tienen stock y lo sirven. Pero cuando llega el segundo, no tienen stock suficiente y pasan aviso a compras para que emita el pedido a proveedor. O peor aún, tienen que pasar a fábrica el aviso para que se fabrique…

Se fabricará algo innecesario que ya fue entregado. El Cliente recibirá un pedido que no solicitó. Se producirá una devolución… en fin, que el lío fue montado inicialmente y se complicará todo lo que pueda complicarse causando pérdidas de tiempo y económicas a la empresa.

Ahora pongamos el mismo ejemplo con el ERP:

  • Att Cliente recibe un pedido de venta:
    • Existen 3 canales de entrada de pedidos de venta:
      • Teléfono, Fax
      • E-mail
      • Tienda On-Line
    • Hay un agente de ventas asignado a cada canal.
    • Cada agente recepciona únicamente los pedidos que entran desde dicho canal.
    • Al recepcionar un pedido, se registra en el ERP.
    • En el análisis inicial, se verificó que se producían errores de duplicación de pedidos de clientes por lo que se incluyó un control, donde al registrar un segundo pedido del mismo cliente y el mismo artículo en las mismas cantidades, el mismo día, advirtiera al agente que dicho pedido ya existe en el sistema.
    • El agente verificará si es el mismo pedido o realmente el Cliente solicita 2 pedidos y podrá optar por registrar o borrar el segundo pedido.
    • Se ha decidido eliminar el envío del e-mail a almacén. En su lugar, se ha establecido que almacén tendrá acceso a consultar los pedidos de venta pendientes registrados en el ERP.

Hemos eliminado varios pasos del proceso anterior. Hemos mejorado la productividad, hemos eliminado tareas repetitivas y sin valor añadido. Hemos agilizado la labor de nuestros empleados y optimizado nuestros recursos, lo cual se traduce en definitiva en un ahorro de costes para la empresa.

CONCLUSIONES:

El objetivo de este apartado es detectar aquellos procesos repetitivos, poco productivos y sin valor añadido que se podrían eliminar del proceso de negocio.

A su vez, permite examinar los procesos actuales y verificar si los procesos definidos de base en el standar del ERP podrían encajar o adaptarse a los requeridos por la empresa. En caso de no ser así, permite identificar aquellos elementos que por ser inherentes y específicos de la empresa, no estarán en definidos de base en el standar del ERP. En nuestro ejemplo anterior, se detectó que el ERP cubría el proceso de base, ya que permitía registrar pedidos y enviarlos por e-mail, pero en esta empresa concreta, se requería un control adicional en el ERP para evitar registrar pedidos de venta por duplicado.

Los procesos mínimos que habrá que detallar son:

  • Presupuestación de productos
  • Sistema de Cálculo de costes
  • Procesos de Compras
  • Procesos de Ventas
  • Procesos de fabricación
  • Procesos de Calidad ( en fabricación, en recepción de materiales, en subcontratación, en atención al Cliente …)
  • Procesos de recepción y expedición de materiales
  • Procesos de devolución de materiales a proveedor
  • Procesos de gestión de devoluciones de Cliente

Este apartado puede ser sumamente sencillo o tremendamente complicado según la empresa que se esté analizando.

Informes, Documentos, estadísticas

En este apartado indicaremos los documentos requeridos en cada área/dpto que deberán estar configurados en el ERP antes de la fecha del arranque, para que puedan ser impresos desde la herramienta. La empresa deberá definir el formato y la información que requiere mostrar en estos documentos.

Es habitual que todos los ERP incluyan en el standar documentos preformateados, que pueden ser perfectamente válidos en cuanto a la información que muestran, por lo tanto bastaría con adaptar su diseño a la imagen corporativa de la empresa. Incluso, si la exigencia en este sentido no es muy alta, ni siquiera esto será necesario. No obstante es necesario analizar los requerimientos de la empresa.

Algunos de los documentos mencionados podrían ser:

  • Pedido de compra a proveedor
  • Albarán de Venta
  • Factura de Venta
  • Certificado de calidad
  • Recibos
  • Orden de fabricación
  • Albarán de devolución de mercancía
  • Lista de embarque
  • Informes contables (mensuales, trimestrales, anuales)
  • Reclamación a proveedor por retraso en entrega de mercancía
  • Reclamaciones de pagos a Clientes
  • Informes de gestión en tesorería
  • Informes estadísticos de cada área


Migración de datos de sistemas actuales

Es imprescindible especificar con qué sistemas de gestión se cuenta actualmente y sobre todo las fuentes de datos que se utilizan.

El objetivo es analizar la calidad de estos datos y comprobar si es posible su inserción automática en el ERP bien sea parcial o totalmente.

En un ERP, todos los datos deben ser consistentes. La estructura de datos está centralizada y normalizada. Si los datos de la empresa están distribuidos en varios soportes y sistemas, cada uno de ellos realizará sus propias codificaciones en los objetos, sus validaciones… Organizar, unificar y normalizar todos estos datos puede ser sumamente complejo y a veces imposible.

En ocasiones, en función del volumen y calidad de los datos, es muchísimo mejor configurar y registrar estos datos manualmente en el ERP pero otras, por los mismos motivos, es imprescindible realizar una migración de datos automática desde dichas fuentes de datos al ERP.

En este caso habrá que desarrollar los procesos de migración correspondientes. Estos desarrollos, son de por sí un proyecto y hay que tratar su desarrollo, como tal. En ningún caso es necesario definirlos en este documento de análisis. El objetivo de este apartado es:

  • Analizar las estructuras de datos en los que se encuentran actualmente los maestros de la empresa.
    • Ejemplo: Llevo las ventas en un Acces, tengo un listado de proveedores en un excel. Tengo un progrma a medida que me gestiona el almacén.
  • Analizar la calidad de los datos
  • Analizar la codificación de los datos y su posibilidad de normalización.
  • Analizar volumetría de los datos susceptibles de ser migrados.

Se recomienda NO MIGRAR datos de operativas antiguas. Es decir, habitualmente no hay problema en migrar los datos de Maestros pero por la extrema complejidad que tiene mantener la integridad de datos y evitar incoherencias en el nuevo sistema no es recomendable migrar:

  • Temas pendientes, abiertos o en proceso  (Pedidos, albaranes, facturas, casos, tickets, ordenes de fabricación….etc). Se recomienda finalizar la gestión de estos casos en el sistema antiguo. Una vez finalizados pueden quedar en dicho sistema como histórico.
  • Temas cerrados:  Aunque se recomienda siempre que queden en el sistema antiguo como histórico, siempre son mucho más sencillos de llevar al nuevo sistema porque no hay que unificar los procesos del sistema antiguo con los del nuevo. A veces es imprescindible migrar (ej: Casos antiguos cerrados como historial del Cliente en el CRM)

Plan de Arranque

Es necesario pensar en Como quiero arrancar.  Como y cuando quiero dejar de trabajar en el sistema antiguo y empezaré con el nuevo. En este punto indicaremos la fecha límite “deseada” para el arranque.

Hay muchas formas de realizar un arranque. Básicamente, depende de si se va a realizar migración de datos o no, pero pueden influir muchísimos factores.

Con migración:

  • Se define un día donde se cierra el sistema antiguo y se empieza con el nuevo.
  • Previamente es necesario extraer los datos del sistema antiguo y cargarlos en el nuevo. En función del volumen de datos, puede ser complicada esta definición… pero esto merece un capítulo aparte, en este blog.
  • Una vez realizada la migración no se debería seguir trabajando en el sistema antiguo, ya que se generarían nuevos datos que no se habrían llevado al ERP.

Sin migración:

  • Poquito a poco, se van introduciendo los datos manualmente en el sistema.
  • Según se van teniendo configurados los datos de maestros de cada área dicha área ya puede operar. Pueden comenzar en paralelo, realizando pruebas en un sistema y en otro y verificando la consistencia de los datos.
  • Se define una fecha real de arranque donde todas las áreas de la empresa estarán trabajando con la herramienta. Los datos introducidos por los distintos dptos, previos  a esta fecha serán considerados como no consistentes o de pruebas en entorno real.

Responsables del proyecto

Es necesario por parte de la empresa definir un jefe de proyecto.

Es muy recomendable que un responsable de cada área esté implicado en todas las fases de implantación del proyecto e imprescindible que lo esté en las fases de análisis inicial y en el arranque.

Conclusiones

Antes de solicitar un presupuesto para un ERP, intentad reflejar en un documento al menos los aspectos identificados en este artículo, pero no dejeis de incluir los que considereis relevantes o críticos para llevar vuestra aventura a buen fin.

3 Comentarios

Y nosotros? Qué pensamos los consultores de ERP

Y bien.. hasta ahora he hablado del Cliente, de los consultores noveles, de la herramienta, de la implantación… pero ¿Y nosotros? ¿Qué pasa con los consultores de ERP?

Como director de proyectos de ERP, puedo decir que en gran medida el éxito de la implantación no depende ni de la herramienta, ni del Cliente, ni de nuestra empresa. Depende directamente de nosotros los consultores.

Cada nuevo proyecto es un reto. Habitualmente desde comercial anuncian que un nuevo Cliente ha firmado un contrato y te pasan toda la información al respecto. A no ser que hayamos colaborado en la fase preventa, inicialmente no conocemos ni al Cliente, ni a la empresa, muchas veces ni el sector…

Los datos que nos pasan son totalmente objetivos. Módulos contratados, estimación en coste y tiempo del proyecto y poquito más. Y ahí te ajustas…y a veces también te asustas… pero hasta que realizas el análisis inicial del proyecto, ves los procesos de negocio que tiene la empresa, hablas con cada uno de los departamentos y usuarios, ves lo que se cuece en el Cliente, no ves de verdad si la implantación “puede” llevarse a cabo con éxito o no.

Cuando aterrizas en un Cliente por primera vez, siempre llevas el cosquilleo en el cuerpo. ¿como serán? ¿Qué gente habrá? ¿Como me irá? En muchas ocasiones, realizas el análisis inicial y YA en ese momento el puzzle entero con todos los procesos se monta en tu cabeza y ves clarísimo como llevarlo al ERP. Ves que el standar cubre casi todo lo que necesitan, que los usuarios están ilusionados y dispuestos a participar y que la implantación será divertida y sumamente satisfactoria. Realizar jornadas en estos Clientes es una tranquilidad y una satisfacción plena. Cuando realizas una implantación según el plan y la metodología prevista inicialmente y se realiza el arranque el día estimado… es como haber ganado un premio.

Y para el Cliente también. Te mandan botellas de buen vino en Navidad, te regalan décimos de lotería y te llaman de vez en cuando para que te pases por allí a analizar algún proceso nuevo, les presupuestes un nuevo módulo o les analices un nuevo desarrollo que requieren incorporar a la herramienta. Llegas a la empresa y todo el mundo está trabajando con el ERP que les facilita la vida, les evita trabajos repetitivos y ves que realmente lo están usando y les es útil. Es lo mejor.

También se da el caso, de que inicialmente lo ves crudo, pero resulta que el jefe de proyecto por parte del Cliente es un crack y conoce todos los recovecos de la empresa. Y según avanza la implantación, vas buscando soluciones que inicialmente eras incapaz de ver.

Otras, es al revés. Inicialmente lo ves fácil y según se avanza, van surgiendo problemas y casuistica que no fue detectada en el análisis inicial. Lo que inicialmente empezó en una llanura se convierte en una montaña de 3 puertos de subida y bajada donde tienes que sudar si quieres llevar a término la implantación.

En cualquier caso, aunque en el análisis inicial veas que va a ser sumamente complicado configurar la aplicación para que cubra todos los procesos de negocio, aunque veas que el dimensionamiento en tiempo o coste es excesivo o insuficiente, aunque veas reticencias de los usuarios… da igual. El contrato ya fue firmado por lo que ya es tarde para levantar los riesgos y tienes que tirar adelante con la implantación sí o sí asumiendo los parámetros que se han firmado en el contrato.

Lo único que puedes hacer es advertir a tu empresa (que al final es la que te paga) de dichos riesgos, pero ante el Cliente tienes que seguir manteniendo tu optimismo y aportando todas las soluciones posibles para llevarlo a buen fin. Jamás puedes decir ante el Cliente lo que de verdad piensas, si lo que piensas es negativo. Cuanto más avance la implantación, más difícil es para el Cliente tomar la decisión de parar y cambiar de aplicación. Porque la inversión ya fue hecha y bien o mal, hay que seguir. Y esto puede acabar bastante mal. Primero porque el Cliente compro algo que no cubría sus necesidades. Segundo porque la empresa vendió a un Cliente al que no podía satisfacer y el desastre puede producirse en cualquier momento.

Es más, una de las claves del éxito es evitar los desarrollos a medida en la fase de implantación. Cuanto más grandes y complejos sean estos desarrollos más hay que evitarlos, pero se da la paradoja de que si una empresa en la que estás implantando requiere un desarrollo grande y complejo, entonces es que el standar no le cubre sus necesidades básicas, por lo que compró mal. Cuando te toca hacer el análisis de estos desarrollos, te imaginas cual será finalmente su coste aproximado y sabes que cuando se presente al Cliente saltarán chispas… pero… No puedes hacer nada. Lo mejor… hacer el análisis solicitado lo más detallado posible, lo más sencillo posible, callarte tus opiniones para tí, no posicionarte y que se arreglen empresa y cliente que son los que firmaron el contrato. Evidentemente, las implantaciones en estos Clientes suelen ser stresantes y tensas.

Por último, hay implantaciones en las que tienes que “recuperar” al Cliente. Por los motivos que sean, bien porque los consultores anteriores no supieron buscar la solución, bien porque los usuarios no se implicaron lo suficiente, bien porque los procesos de negocio no estaban bien definidos o se definieron mal por ambas partes, tienes que retomar un proyecto “a medias” y tratar de llevarlo a término. Las situaciones en estos casos son curiosas. Habitualmente, te encuentras con usuarios rebotados que no hacen más que comentarte las anécdotas negativas del anterior intento de implantación y sacan a colación todo lo que se pueda imaginar. Por supuesto, la “culpa” es siempre de la empresa implantadora o del consultor, en ningún caso de ellos y escuchas críticas durísimas a tu empresa o a tus propios compañeros y a veces es difícil contenerte.

En este caso complejo, hay que ganarse a los usuarios. Traerlos a tu terreno. Dejar que hablen todo lo que quieran, sin darles la razón (porque sería echar piedras sobre tu propio tejado) pero sin discutir en ningún momento. Evasivas, capotes y sobre todo dejar clarísimo que empezamos otra vez. Vamos a ver qué es lo que falló, vamos a volver a analizar los procesos, comprobar la parametrización que se hizo con la herramienta y sobre todo dejar claro que es necesario realizar un punto y aparte y buscar LA solución.

Lo cierto es que tal y como puse en otro post, las virtudes más importante de un consultor son la paciencia y la imaginación. Ayudan bastante una sonrisa y saber escuchar. Siempre escuchar. Aparte de esto, no imponer, sino razonar.

No hay un ERP malo. Todos cubren muchísimas áreas de la empresa. Solo hay que encontrar aquel que más se ajuste a las necesidades del Cliente que lo compre y si ha comprado lo que no es adecuado, hay que intentar sacarle el máximo provecho e intentar configurarlo para que le cubra el máximo posible de sus necesidades, sin desarrollos a medida. Y ahí está el quid de ser o no un buen consultor.

2 Comentarios

Reinstalar postgreSQL

Si alguna vez instalaste postgreSQL en Windows y quieres reinstalar una nueva versión, probablemente obtengas el siguiente error:

The password specified was incorrect. Please enter the correct password for the postgres windows user account

Posiblemente no te acuerdes de dicha password y te quedas completamente pasmao porque no sabes por donde tirar. Después de mucho navegar, encontré la solución. Aquí va.

  1. Entra en Inicio/Panel de control/Herramientas administrativas/Control de equipos
  2. Encuentra el usuario postgres
  3. Modifica la contraseña y pon la que quieras.
  4. Introduce dicha contraseña en el asistente de instalación del postgres.

Y ya está.

16 Comentarios

Conexión de un ERP con una Tienda OnLine

Desde el punto de vista conceptual existen las siguientes diferencias a tener en cuenta cuando se va a desarrollar la conexión entre una tienda on-line y un ERP.

Integración de Clientes, Contactos y Usuarios

Cualquiera de las premisas que detallaré a continuación puede nos ser cierta en casos puntuales. Pero pongamos que son ciertas en su gran mayoría.

  • Hasta hace bien poco solo las grandes empresas tenían acceso por coste a la implantación de un ERP.
  • Las grandes empresas venden a grandes o pequeñas empresas, es decir, personas jurídicas o autónomos con un código de identificación fiscal.
  • El concepto Cliente en una gran empresa suele identificarse con un CIF.
  • El concepto usuario que realiza la compra, no suele ser trascendente. Una empresa vende a otra.
  • Un cliente puede facilitar los datos de uno o varios contactos (empleados) que tienen potestad o no para realizar pedidos a la empresa.
  • El registro de datos contiene además de los datos del Cliente como tal (Nombre fiscal, Nombre coloquial, e-mail, web…) otros datos asociados y críticos como pueden ser la Dirección fiscal, Dirección de envío de mercancías, Dirección de envío de documentos, Contactos, Teléfonos de contactos, departamentos de la empresa, departamentos a los que pertenecen los contactos…)
  • Una empresa puede facilitar infinidad de direcciones de e-mail, tanto generales como personales de sus empleados o departamentos. O direcciones específicas, de soporte técnico, de soporte de facturación, comercial… etc, etc que serán gestionadas por distintos contactos o empleados.
  • Dicho esto, identificar y registrar todos los datos de un Cliente en el ERP puede ser tan complejo como grande sea la estructura departamental de la empresa y el número de empleados que tenga, por tanto la estructura que soporta esta información en el ERP debe ser igual de compleja y coherente, evitando la duplicidad de datos.

Miremos ahora el registro de Clientes de una tienda On-line:

  • Las tiendas On-line pueden vender tanto a empresas como a Cliente final.
  • El dato clave que identifica al Cliente suele ser una dirección de e-mail.
  • La tienda on-line no permite el registro de estructuras complejas de empresa, ni suele ser necesario para la  gestión de las ventas.
  • El objetivo de una tienda on-line es captar clientes por lo que cuanto más sencillo sea el formulario de registro, menos Clientes se echarán atrás en la compra.

Ahora bien… ¿como integramos dos estructuras donde las premisas básicas de registro son tan sumamente distintas? La forma más sencilla podría ser unificar usuarios de la tienda on-line con contactos del ERP.

En el formulario de registro se incluiría un único campo nuevo que contemplaría la inclusión de un CIF y un nombre de empresa no obligatorios. El usuario de la tienda on-line solo debería introducir estos datos en caso de que pertenezca a una empresa.

La integración debería contemplar:

  • La creación automática de un Cliente en el ERP tomando los datos de registro de un usuario de la tienda on-line
  • La creación automática de un usuario en la tienda On-Line con los datos de contacto del ERP.
  • Si una empresa sólo autoriza a algunos de sus empleados a realizar pedidos bien sea mediante la tienda on-line bien sea por otro medio, el ERP debería contemplar la posibilidad de autorizar o rechazar los pedidos de venta recibidos.

Integración de catálogo

De nuevo nos encontramos con diferencias substanciales a la hora de registrar el catálogo en un ERP y el catálogo mostrado en una tienda on-line.

En un ERP

  • Es necesario registrar artículos tanto de compra, como de fabricación, semielaborados, utillajes, herramientas…. en función de la industria y del sector que se trate, tendrá que comprar ciertos elementos, que puede vender o no. Y tendrá también productos que utilice para fabricar, pero que no incluya en su catálogo de venta. Es el caso por ejemplo de una tienda de muebles, que requiere comprar madera, pero en su catálogo final únicamente pone muebles.
  • El registro del artículo en el ERP suele estar enfocado únicamente a eso, a registrar información.
  • La información guardada suele ser objetiva. Resumida. A menudo sin imágenes.
  • La clave del artículo en el ERP es su código de referencia. La descripción o las observaciones pueden no existir.
  • Una persona ajena a la empresa difícilmente comprende la estructura de los artículos o las referencias.

En la tienda on-line

  • Solo se incluirán en el catálogo aquellos artículos que se vayan a vender.
  • La información mostrada tiene que ser atractiva. Comprensible para el usuario.
  • Cuantas más imágenes, explicaciones y descripciones se den al usuario mejor.
  • Cualquiera debe ser capaz a un vistazo de ver lo que vende la tienda.
  • Las ofertas y descuentos deben estar visibles.
  • Se debe cuidar el diseño de cada página que presente un producto a la venta.
  • Cada página de producto debe contener etiquetas o descripciones SEO, que permitan a los buscadores mostrar los productos de la tienda en primeras posiciones.

De nuevo nos encontramos con que el cometido del registro de artículos en el ERP no tiene nada que ver con el de la tienda On-Line. Así como el objetivo en el ERP es mantener un registro interno de los artículos para permitir su control, almacén, fabricación, compra y venta, en la tienda on-line además hay que tener en cuenta el aspecto visual, la forma de presentar el producto para que sea atractivo y produzca una posible compra.

La integración debería contemplar estos aspectos. El master de productos debería ser el ERP. La comunicación sería unidireccional desde el ERP a la tienda on-line, nunca al revés, por lo que sería necesario ampliar los campos descripción, observaciones, imágenes y campos SEO para que pudieran ser actualizados en el ERP. Además, se debería permitir publicar únicamente los productos marcados como de Venta on-line.

Integración de pedidos de ventas

Este aspecto ya es más parecido en los 2 sistemas. En un ERP, habitualmente un pedido cuenta con una cabecera de pedido y unas líneas, en las que consta el código de producto vendido, la cantidad y el precio.

En la tienda on-line es exactamente igual. Existe una cabecera de pedido donde constarán los datos del Cliente, forma de pago y envío, productos con su cantidad y precio.

La integración debería consistir en la creación automática de pedidos desde la tienda on-line al ERP. Habrá que tener en cuenta aspectos tales como el cliente que realiza el pedido. ¿Como se le identifica? Si no se puede identificiar el Cliente en el ERP, ¿se crea un nuevo Cliente con dichos datos? ¿Se obliga a la verificación de los datos antes de la creación?

Otros aspectos a tener en cuenta

Con un ERP el proceso habitual, al ser de empresa a empresa es.

  • Pedido de venta, albaranes totales o parciales, facturación y cobro.
  • Las formas de pago, suelen ser diferidas (Giro a 30 días, confirmin…etc)
  • Las formas de envío suelen ser bien en camión del Cliente, bien en Camión propio o con agencias de transporte 24h.

En la tienda on-line

  • Pedido de venta, cobro, albarán/factura.
  • Las formas de pago suelen ser inmediatas (Transferencia, paypal, tarjeta de crédito)
  • Las formas de envío suelen ser las agencias de transporte o correos.

Es decir, el proceso de negocio de la venta es distinto en el ERP y en la tienda on-line. Sería necesario adecuar el proceso de venta del ERP  para que tomase en cuenta este aspecto y permitiese el registro y gestión de estas formas de pago. Normalmente cuando el pedido llega al ERP desde la tienda on-line, estaría ya pagado.

, , ,

4 Comentarios

Errores flagrantes cometidos por empresas implantadoras de ERP

1. Vender por vender:

El error más común y más habitual es vender por vender.

La mayoría de los comerciales de ERP tienen comisiones altísimas por captar un Cliente. Según esta premisa les da bastante igual a quien vendan y qué vendan. La cuestión es vender y se buscarán las vueltas en las demos para captar el interés del Cliente y obtener la firma del contrato.

Si el comercial es muy bueno, previamente hará un sondeo sobre la empresa a la que va a intentar “colocar” el ERP. Verá a grosso modo el sector, sus necesidades y en la demo preventa, prácticamente todo estará cubierto y la herramienta le será válida sino a un 100% al menos en un 95%. Quitará importancia a aquello que no cubre y enfatizará sobremanera aquello que sí cubre.

En muchísimas ocasiones, es cierto que el ERP es capaz de cubrir todas las necesidades de la empresa. De hecho, hay muchas “buenas” empresas implantadoras, que directamente forman a sus comerciales para vender únicamente a aquellos Clientes que saben que su producto puede satisfacer. Previo a la venta, analizan en detalle a la empresa y si las discrepancias son demasiadas, directamente desechan la venta. Esto es lo que tendrían que hacer todos. Pero desgraciadamente no es así. Los problemas que pueden surgir una vez realizada la venta, una vez que el comercial ya se ha llevado tajada con su comisión correspondiente, son infinitos. Los consultores se pierden. No hay soluciones reales que ofrecer. El Cliente se decepciona. El coste de adaptación es enorme. Al final, incluso la relación implantador-cliente se pierde y todo acaba en tribunales. Uno alega que compró lo que compró y el otro que le engañaron en la venta. Problemas para todos y ninguna satisfacción. Por esto, es importantísimo que el Cliente exija y compruebe in-situ o mediante varias demos si hace falta que lo que está comprando es lo que realmente necesita. Es mejor para todos.

Consultores sin experiencia metidos en camisas de once varas.

En ocasiones, cuando el mercado es favorable y se producen varias ventas a la vez, la empresa implantadora se encuentra con varios Clientes que solicitan comenzar YA, cuanto antes mejor. Queremos arrancar en 3 meses como mucho. Necesitamos que esto empiece la semana que viene. Y… les pillan en un renuncio porque los consultores experimentados son habitualmente muy solicitados y su agenda suele estar bastante apretada. La solución suele ser, contratar consultores sin experiencia en la herramienta, que difícilmente van a buscar soluciones al Cliente. Si además, por ahorrar costes, estos consultores son recién licenciados o tienen mínima experiencia previa con otras herramientas, es imposible que funcione. El cliente se sentirá decepcionado. Pasarán las jornadas de formación totalmente insatisfactorias. Al final un consultor experimentado tendrá que recuperar la cuenta, si es que aún es posible recuperarla… Problemas para todos.

Y como solucionamos esto.

  1. A veces, es mejor retrasar el inicio de la implantación uno o dos meses, aunque el Cliente se queje.
  2. Es crítico asignar un personal experimentado que lleve las riendas. NO es para nada recomendable soltar a un consultor Novel en un Cliente hasta que esté realmente certificado y haya hecho unas cuantas salidas con un consultor experto.
  3. No enviar a un consultor a un Cliente cuya historia y casuistica no conozca.
  4. Mucho menos enviar a un consultor novel a realizar trabajos complejos como un análisis inicial o una reingeniería de procesos, si no conoce como mínimo el sector de negocio y como recomendable al Cliente.
  5. Invertir tiempo en formación de los consultores noveles y realizarles pruebas de certificación, tanto en los distintos módulos de la herramienta, como en el trabajo de consultor en sí.
  6. Forzar workshops semanales donde cada consultor forme al resto, sea novel o no en las experiencias vividas en Cliente durante la semana.
  7. Tener un repositorio de casos prácticos que puedan ser consultados por cualquier consultor.
  8. Tener un plan de formación adecuado que les haga ser productivos en el menor tiempo posible. Sin prisa, pero sin pausa.
  9. Estar al tanto de todas las salidas y actuaciones de los consultores noveles, realizando seguimiento de todas sus acciones.

Hay personas cuyo perfil, no acaba de encajar en el mundo de la consultoría. Algunos aspectos que deberían alarmarnos cuando contratamos un nuevo consultor serían los siguientes:

  • Lo sabe todo. No se deja enseñar. Siempre tiene razón en todo. No reconoce sus errores.
  • Oculta sus actuaciones en Cliente. Siempre está todo bien. Un buen consultor, advierte de que la jornada no ha ido correcta, el Cliente está insatisfecho o ha tenido problemas… si advierte, habitualmente se suele poder solucionar. Si no advierte, la bola se va haciendo más grande hasta que lo rechazan de plano y es demasiado tarde.
  • No tiene facilidad de palabra.
  • No tiene buena expresión escrita.
  • No tiene modales.
  • No tiene facilidad de aprendizaje.
  • No pregunta nada. Si no pregunta, malo. Es muchísimo mejor que pregunte más de lo debido. Esto demuestra interés.
  • No quiere salir. Tiene miedo escénico a enfrentarse a las formaciones.
  • Es indiscreto.
  • No es capaz de autoformarse.

No ver las carencias de la herramienta.

Cuando un Cliente solicita una funcionalidad. Puede ser exclusiva de su sector o de la empresa concreta.

Cuando son tres o cuatro Clientes los que la solicitan, hay que pensar en que la herramienta realmente tiene una carencia.

Cuando son todos los que la solicitan… es necesario desarrollar dicha funcionalidad e incorporarla a la mayor brevedad a la herramienta, bien sea como funcionalidad standar en una publicación posterior, o como módulo que se pueda instalar de forma independiente.

Hay empresas que consideran que cualquier funcionalidad que no exista en la herramienta, es necesario que sea financiada por algún cliente. Es decir, no evolucionan la herramienta si no hay solicitudes “a medida” que pidan los Clientes. Es una forma de enfocar la evolución de la herramienta.

En otras, se recogen las sugerencias de mejora emitidas por los clientes, se evalúan, se empaquetan, se priorizan y desarrollan para ser publicadas en siguientes versiones. Negar que una herramienta debe evolucionar, bien sea mediante solicitudes “financiadas” bien sea de motu propio, es llevar a la herramienta a una discontinuidad segura.

Cada vez el mercado es más exigente con los ERP. Cada vez los clientes están más informados de las distintas opciones y las distintas tecnologías. Un ERP que no evolucione al mismo nivel que el mercado está condenado al olvido, incluso a su desaparición.

2 Comentarios

Quiero ser consultor de ERP… y ¿Esto qué es?

Para ser consultor de ERP, lo primero que tienes que tener es muchísimas ganas de aprender. Tienes que ser resolutivo. Saber escuchar. Tener don de gentes y muuuucha paciencia.

Lo que se solicita a un consultor de ERP por parte de la empresa, es primero tener una licenciatura o una diplomatura, bien en áreas técnicas como ingenieria o informática, o bien en Empresa. Si tienes algún master o MBA mejor aún. Pero a veces, la mayoría de las veces, tener un título no te hace ser mejor o peor consultor.

¿En qué consiste el trabajo? ¿Qué hacemos los consultores? Básicamente ayudamos a que la implantación de un ERP en una empresa se lleve a buen término. Algunas de nuestras tareas consisten en.

  1. Formar a los usuarios en el uso de la herramienta. En función de la cantidad de módulos contratada por el Cliente y el número de usuarios que utilizarán la aplicación, la formación puede consistir en explicar cómo funciona a un par de personas delante de un ordenador, o enfrentarte a un aula de 15 alumnos, incluida pizarra y cañón. En cualquier caso, es necesario hacer amena la formación. Hacer que los usuarios disfruten con el aprendizaje. Cualquiera puede DAR CLASES… muy pocos pueden FORMAR.
  2. Realizar el análisis inicial de la empresa. Al inicio de la implantación, lo habitual es que se realice un análisis inicial donde deberán constar aquellos procesos de negocio críticos que cubrirá la nueva aplicación.
  3. Realizar tomas de requerimientos de funcionalidad no contemplada por la herramienta. Un consultor debe ser capaz de detectar y plasmar en un documento aquella funcionalidad crítica para la empresa, que no está cubierta por la aplicación. Esto implica Hacer de “traductor” con el equipo de desarrollo. El consultor debe ser capaz de transmitir lo que el Cliente quiere al equipo que desarrollará la nueva funcionalidad. Para realizar esta labor, suele ser “mejor” aunque no imprescindible que el consultor tenga formación informática.
  4. Buscar soluciones, sin desarrollos adicionales. En muchas ocasiones, aquello que parece requerir un desarrollo a medida, puede ser cubierto sin ningún desarrollo utilizando una funcionalidad existente, configurando la herramienta de manera distinta. En la medida de lo posible es recomendable minimizar el desarrollo de funcionalidad a medida, al menos hasta que transcurra un cierto tiempo desde el arranque y se verifique que dicho desarrollo es estrictamente necesario.
  5. “Vender” el ERP. Vencer las posibles reticencias de los usuarios. Convencerles. Hacer que “les encante” la nueva herramienta. Vencer su resistencia al cambio.
  6. Ayudar al Cliente en la definición de los nuevos procesos de negocio. Es lo que se denomina “Reingeniería de procesos”. En ocasiones hay que adecuar sus procesos a los que ofrece la herramienta. Hay que detectar y en la medida de lo posible eliminar los procesos repetitivos y definir el máximo aprovechamiento de tiempo y recursos con el uso de la nueva aplicación.
  7. Tienes que estar dispuesto a viajar. Hoy estás en Madrid y mañana en Huelva.
  8. Tienes que tener la mente abierta y no cerrarte a una única forma de hacer las cosas. Cada Cliente trabaja de una determinada forma. No hay mejores y peores formas, solo distintas. Y de cada una aprendes. Hay que sacar lo mejor de cada una y coger ideas. Todas las que puedas. Una solución aportada a un cliente o por un Cliente puede ser perfectamente válida para otro. Cuantas más conozcas, más opciones podrás aportarles y más fácil podrás resolver los problemas que te surjan a futuro.
  9. Escuchar. Siempre. Antes de cerrarte en banda, tienes que analizar lo que te están diciendo. Tienes que evaluar lo que te están proponiendo. Antes de decir que no se puede, preguntar.
  10. Levantar riesgos. En cualquier punto de la implantación pueden surgir riesgos que pongan en peligro la implantación. Desviaciones en el planning inicial, reticencia o rechazo de la aplicación por parte de los usuarios, reticencia o rechazo hacia el propio consultor, Clientes que no se dejan aconsejar y que pretenden llevar el peso de la implantación sin conocer la herramienta, retraso en la entrega de los desarrollos solicitados, mala calidad en los datos de la migración, desinterés o falta de asistencia de los usuarios a las formaciones, decisiones tomadas de forma unilateral por el Cliente con las que el consultor no está de acuerdo, alta rotación de personal en el Cliente… en fin… todas aquellas situaciones que se dan y sobre la que es necesario informar con el mayor grado de detalle a los responsables de la empresa implantadora.
  11. En ocasiones los consultores debemos acudir a las demos preventa con los comerciales para dar respuesta a las dudas planteadas por los Clientes, o para mostrar módulos que los comerciales no conocen.

Cuando un consultor adquiere experiencia en las labores propias de consultoría, realizará además labores de Jefe de proyecto de implantación o director de proyecto. Entre otras, sus labores serán las que siguen:

  1. Cotizar implantaciones o realizar presupuestos de implantación.
  2. Planificar y definir las fases, recursos y tiempo requerido para la implantación.
  3. Realizar el seguimiento de costes y desviaciones del proyecto
  4. Formar a nuevos consultores
  5. Asignar tareas y realizar el seguimiento a los consultores de su equipo.
  6. Realizar el seguimiento de la satisfacción del Cliente en cuanto a la implantación.
  7. Realizar los informes de seguimiento del proyecto
  8. Planificar y dirigir las reuniones de seguimiento.

Temas en los que un consultor debe permanecer al margen:

  1. Problemas políticos o de poder en el Cliente. Jamás entrar al trapo de cotilleos, rumores de pasillo o tomar absolutamente ningún partido por ningún usuario.
  2. Hacerse eco de los comentarios negativos de los usuarios contra la herramienta.
  3. Mentir sobre la funcionalidad que cubre la herramienta.
  4. Decir “esto te lo haremos gratis”, a no ser que tenga potestad suficiente y la empresa implantadora le haya dado el visto bueno a dicha afirmación.
  5. Poner en duda, o causar incertidumbre al Cliente con respecto al buen término de la implantación.

9 Comentarios

Que solicitar en una Demo de un ERP

Si yo fuese el gerente de una empresa que va a contratar la implantación de un ERP, previamente a solicitar que una empresa implantadora o propietaria de un software realice una Demo, tendría apuntados aquellos puntos críticos que quiero cubrir con la nueva herramienta.

Los comerciales se tienen aprendida una ruta por los distintos módulos de la herramienta, que es la que muestran en la demos. Normalmente el tiempo de la demo suele estar limitado y no se ve más allá de lo que el comercial nos quiera enseñar. Esto puede ser correcto en ocasiones, cuando la empresa es muy pequeña o los procesos de negocio son sencillos, basta con conocer los procesos más generales de cada una de las áreas. Pero si previamente yo he realizado un análisis exhaustivo de lo que realmente necesito, podré consultar sobre aquellos procesos que no me han mostrado en la demo.

Mis consejos son los siguientes:

PREVIO A LA PRIMERA DEMO:

  1. Analiza tu empresa.
  2. Llama a otros Clientes que hayan implantado esta herramienta. Consulta los casos de éxito en la Web. Solicita que te faciliten los nombres de otros Clientes en los que hayan implantado.

DURANTE LA DEMO:

  1. No te creas todo lo que te cuenten. Verifícalo. Si tienes cualquier duda pregunta.
  2. Si un proceso es crítico para tu negocio y no te lo han enseñado, solicita que lo hagan.
  3. Pide el ratón un rato. Solicita que te dejen manejar la aplicación. Entra en pantallas que no te han enseñado, aunque no sepas como funcionan. Esto te permitirá ver si hay “errores ocultos” o funcionalidad aún no desarrollada que saldrá en “proximas versiones”.
  4. Si es necesario, solicita la presencia de un consultor experimentado en la demo.
  5. Según te vayan enseñando los distintos procesos, táchalos de tu lista. Si al finalizar ves que tienes en tu lista demasiada funcionalidad por cubrir… pregunta cómo te lo van a resolver.
  6. Solicita un presupuesto muestra de un desarrollo ” a medida”. Esto te puede dar idea de lo que te costará llegar a cubrir al 100% la funcionalidad que necesitas
  7. Pregunta cual es la metodología de la implantación. Qué formación tendrán los consultores de la implantación. Qué experiencia tienen estos consultores.
  8. Si tienes que realizar alguna migración de datos, pregunta por la tecnología y metodología que utilizarán en dicha migración.
  9. Consulta el coste de la elaboración de documentos a medida. Consulta si este desarrollo de documentos podrá ser realizado por personal de tu empresa o estás atado a que te lo tengan que presupuestar.
  10. Solicita una copia de un precontrato. Lee todo, hasta la letra pequeña.
  11. Consulta sobre la cuota de soporte y mantenimiento. Que cubre. Qué no. Cada cuanto tiempo publican nuevas versiones. Quien y cómo realiza la instalación de estas nuevas versiones. Cual es el coste de actualizarte.
  12. Consulta sobre la tecnología de la herramienta. Lenguaje de programación, base de datos, sistema operativo, posibilidades de conexión remota mediante portátiles o pdas, a través de internet. Consulta sobre la interconexión entre sedes. Tecnología utilizada en las conexiones remotas. Por ejemplo, si es 100% basado en TCP/IP, o sea, Web… ¿qué pasa cuando te quedas sin conexión porque se cae el ADSL? Al revés, si es Cliente/Servidor… ¿como se conectará tu sede de Sevilla?

DESPUES DE LA DEMO:

  1. Evalúa la profesionalidad de las personas que han realizado la presentación.
  2. Evalúa la funcionalidad del software presentado.
  3. Evalúa el coste tanto del páquete básico como de los posibles desarrollos que tendrás que realizar.
  4. Evalúa el número de documentos que tendrás que definir y desarrollar. Evalúa si lo podeis hacer vosotros mismos o no.
  5. Evalúa la metodología que utilizará la empresa, el perfil y la formación de los consultores de la implantación.
  6. Evalúa la publicación de nuevas versiones y su instalación.
  7. Evalúa el nivel de actualización tecnológica de la herramienta y sus diferentes alternativas de conexión.

Cuanto más claro tengas qué es lo que necesita tu empresa y qué es lo que te están ofreciendo, más probabilidad de éxito en la implantación. Ten en cuenta que a veces

  • El más caro no es el mejor, ni el más barato el peor.
  • Hay aplicaciones que parecen muy completas y no excesivamente caras que a la larga pueden ser mucho más costosas que otras que previamente parecían menos asequibles.
  • En ocasiones, firmar un contrato puede ser un saco sin fondo donde tendrás que pagar absolutamente por todo. Incluso por la definición de un simple documento de pedido de compra.
  • Estás poniendo los datos de tu empresa, los de gestión, los de operativa, los cuadros de mando, los datos que te permitan ver la evolución de la empresa en manos de un sistema informático. En definitiva, el sistema debe ser fiable, estable, actual, tecnológicamente puntero, no excesivamente caro, con contratos de mantenimiento y soporte que cubran cualquier eventualidad en función de tus necesidades. Si no puedes permitirte el lujo de que tu sistema esté caído el fin de semana, necesitas un soporte 24X7, por ejemplo. Si tu empresa permanece cerrada durante la noche, los fines de semana y cierras todos los puentes, evidentemente un soporte 24X7 es excesivo e innecesario en tu caso…

Como veis, las variables para tomar una decisión son infinitas. Como en casi todo hay que evaluar coste/beneficio. ¿Que es mejor? Una empresa que lleva muchos años en el mercado, con una tecnología no tan puntera pero que te ofrece estabilidad y fiabilidad en tus datos, cuyos costes de desarrollo son desorbitados, o una empresa tecnológicamente puntera recién inaugurada, con pocos clientes de referencia, cuya base funcional es limitada pero que te ofrece unos desarrollos a medida con un coste muy reducido? Complicada elección…

2 Comentarios

Motivos de fracaso en la implantación de un ERP

Hace poco leí por ahí un artículo en el que indicaba que un 70% de las implantaciones de ERP fracasaban. Y esto porqué? En principio, debería ser sencillo. Una empresa tiene la necesidad de comprar un software. Varias empresas le ofrecen un paquete abierto o cerrado que podría cubrir sus necesidades. Todo el mundo está ilusionado. El nuevo paquete les va a facilitar la vida. Va a hacer que todo vaya más rápido. Todos los departamentos estarán conectados. No habrá que esperar a que otro me facilite la información que necesito. Simplemente iré y la cogeré. Gerencia podrá obtener información sobre la evolución del negocio, inaccesible hasta el momento… entonces… ¿qué pasa? ¿Porqué más implantaciones de las debidas acaban en tribunales?

Según mi modesta opinión hay varios puntos que llevan al fracaso:

  1. El cliente está pagando muchísimo dinero por un software que pareciendo inicialmente precioso y maravilloso y que cubre todo lo que su empresa necesita… resulta que no es así. Cuando realmente se desgranan todos los módulos con toda su funcionalidad, se ve que lo que han comprado no es ni mucho menos lo que esperaban obtener. Cuando la empresa implantadora o la propietaria de la licencia presenta los presupuestos para cubrir aquellas áreas no cubiertas por el software base… empiezan los problemas.
  2. Los usuarios están demasiado habituados a su forma de trabajo actual. A pesar de que el nuevo software comprado sea mejor, más ágil, mas completo… se niegan a cambiar su operativa actual. Este problema se agudiza cuando se eleva la edad de los usuarios. Por mi experiencia, es diez veces más complicado formar a personas mayores de 45 años. A veces, aunque pongan de su parte y lo intenten… es imposible. Siempre vuelven a su fichero excel o a su access de toda la vida.
  3. Los consultores que realizan la implantación no están formados o no tienen la suficiente experiencia. Conocen lo básico de la herramienta, pero no son capaces de buscar soluciones alternativas. No tienen la suficiente experiencia para escuchar las necesidades del Cliente y buscar una posible configuración, una ruta alternativa en la operativa para solucionar aquel problema irresoluble que quizás con una puesta en común, una tormenta de ideas o la aportación de un consultor más experimentado se solucionaría.
  4. El programa comprado es excesivamente rígido en su configuración o sus modificaciones.
  5. Los comerciales que ofrecen la herramienta le atribuyen funcionalidad que esta no contempla.
  6. El que paga… no opera. O sea, por buena que sea la información que se va a extraer de la herramienta a posteriori, los que van a utilizarla en su operativa diaria, son los que deben registrar esta información. Si el nuevo sistema no es lo suficientemente bueno en cuanto a usabilidad, navegabilidad, búsquedas… en definitiva, no es “user friendly”, lo que se conseguirá es que el usuario aborrezca la nueva aplicación. En lenguaje coloquial, durante la implantación “cogerán manía” a la aplicación… la implantación será muy complicada a partir de este punto.
  7. La lógica de aplicación o los procesos que cubre, hacen variar tantísimo la forma actual de llevar las cosas, que aunque la funcionalidad solicitada está cubierta… no es lo mismo. Al igual que en el punto anterior, el rechazo está asegurado.
  8. La empresa Cliente no informa a sus usuarios con suficiente antelación. No define la reestructuración de sus procesos. Deja que la implantación fluya… sin más. No se replantea los cambios que van a sufrir sus procesos e incluso las responsabilidades de sus empleados cuando se implante la nueva herramienta. Incluso puede haber empleados que sientan amenazado su actual puesto de trabajo, con lo que harán lo imposible para que la implantación de la herramienta no se lleve a término. Este caso, aunque parezca exagerado, sucede. Pongamos por caso en una gran empresa, alguien cuyo trabajo principalmente es imprimir documentos de calidad del producto terminado. Con el ERP la obtención del documento es automática. O el caso de gente de administración cuyo principal trabajo es emitir facturas. Con el ERP la factura podrá obtenerse de forma automática incluso desde el pedido del Cliente. O en compras, donde hay un equipo que se dedida a enviar e-mails a proveedores solicitando tarifas y registrarlas en algún sistema una vez recibidas. Pongamos por caso que el ERP permitirá la carga automática de tarifas de proveedor o incluso permite que se conecte directamente al ERP del proveedor actualizando la tarifa automáticamente cada vez que este la cambia… En fin, la casuistica es infinita. Cuanto más grande es la empresa, más empleados potenciales que pueden “reventar” la implantación. Es tarea de los responsables de la implantación por parte del Cliente redefinir los procesos, y asignar nuevas tareas y responsabilidades a los empleados para eliminar tareas repetitivas y convertir el tiempo no productivo en productivo y sobre todo concienciar a la gente de que la implantación no es un proceso trivial y requiere la colaboración de todos y cada uno de los usuarios que utilizarán la nueva aplicación.
  9. Migraciones de datos: Otro punto de bloqueo. Si la migración de datos del sistema anterior, no se realiza con el suficiente rigor y calidad de datos… puede llevar al fracaso de la implantación.
  10. Documentos personalizados. Hay que definir previo al arranque TODOS y cada uno de los documentos que deberán obtenerse del ERP. Como mínimo, habrá que contemplar aquellos que se usen actualmente. En ocasiones, se da más importancia a la formación de los usuarios o a los datos migrados que a los documentos, pero tengamos en cuenta que no podremos realizar un pedido de compra a un proveedor si no hemos definido previamente este documento “pedido de compra”.

En fin, seguro que hay muchísimos más puntos que se podrían incluir en este artículo. Estos son los que me han parecido más relevantes!!!

1 Comentario

buy prednisone cheap propecia