Análisis inicial para implantar un

ERP
• Como mínimo, un análisis inicial debe
contener los siguientes aspectos:
– Análisis de datos Maestros
– Procesos Operativos
 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 permitirá 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….
• 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.
• 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
• 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
• 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 o Qué compro o Qué vendo
o 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…
• 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 (Logística)
• 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, 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 (Logística).
• 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…
• 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)
• Una vez definidos estos aspectos podríamos
hablar de que tenemos una visión general de
los datos maestros de la empresa en las áreas
mencionadas y podríamos 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
– Nivel 2: Procesos intradepartamentales
 Nivel 1: Procesos
interdepartamentales
• Cuales son las áreas/departamentos 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
• 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
programa 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.
 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 re
 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