Peritaje informático ERP, Web y APP

 Inicio /

 Artículos /

 Informática Forense

En estos días que me encuentro en varios juicios por la geografía española donde como auditor y en experto
en Peritaje informático ERP, Web y APP, estoy dando fe de la correcta e incorrecta realización de varios
proyectos, quisiera compartir varias cuestiones que pueden ser de ayuda a abogados como a clientes finales en
la gestión de sus proyectos informáticos de desarrollo ERP, Web, movilidad…
Peritaje informático ERP, Web y APP
No es casualidad que en las últimas fechas diferentes peritajes informáticos en los que me encuentro
colaborando tengan que ver con alguno de estos tres tipos de proyecto:

1. Proyecto implantación ERP o sistema de gestión.

2. Portales web, integrados o no con el sistema de gestión.
3. Diferentes APP que tratan de aportar la funcionalidad del portal web, ERP, etc en la movilidad de varias
áreas de la empresa.

Microsoft Dynamics NAV (Navision), Microsoft Dynamics AX (AXAPTA), SAP Business One, WordPress,
Prestashop… y algún otro que por confidencialidad no nombrare, son ejemplos, de proyectos que han
fracasado, vistos desde un lado (cliente) y otro (partner), con inversiones en ocasiones que superan los 5
dígitos, que en su día comenzaron como un gran proyecto y se ha convertido en un “gran dolor de cabeza”.
Aunque en ocasiones he escrito al respecto quisiera esta vez ponerme en la piel e los afectados principales
(cliente y partner) y describir aquí como, de un mismo problema, se encuentran dos puntos de vista tan
diferentes. Puntos de vista que como perito de parte o judicial tienes que desgranar, en ocasiones alejarte de
los sentimientos y presión del interlocutor, ver, como siempre digo, que hay más allá de la punta del iceberg,
pese a que, no olvidemos, estamos en un análisis forense informático. Trato de entender que paso, que
ocurrió realmente, para poder extraer las evidencias B que hay detrás de las evidencias A.
Seguidamente quiero incluir una pequeña comparativa de opiniones diferentes contrastadas en casos y
situaciones reales, desde los puntos de vista de cliente y partner. Como verán la visión puede ser, en
ocasiones, tan parcial que debemos entender como de difícil es para el juez entender quién es el realmente
responsable del fracaso o que parte de responsabilidad tiene cada uno:

Cliente Partner o proveedor informático

El documento de requisitos fue
insuficiente, la culpa o responsabilidad es
del partner, no nos entendió, así como
infravaloro el proyecto.
Las licencias vendidas son insuficientes,
inadecuadas.
El partner no tiene capacidad para
entender nuestro negocio.
El software no funciona, falla en su
totalidad.
El programa que teníamos antes es mejor,
más adecuado,…
Nos cobraban por cada hora de desarrollo
extra aunque fueran cosas que corregían
de algo mal desarrollado.
No nos sirve nada de lo que han hecho.
El director de proyecto era un desastre y
no entendía lo que necesitábamos.
Yo antes tenía unos informes que me
daban todo. En una sola hoja Excel tenía
una visión completa, ahora tengo que ir a
Nosotros hicimos lo que nos explicaron, se tomó
nota varias veces de lo que querían, cada vez
que nos reuníamos el proyecto cambiaba y se
ampliaba.
Se eligió la licencia de menor coste porque así
nos lo pidieron, ahorrar coste a toda costa.
Hemos desarrollado empresas del mismo sector
de manera impecable. El problema es que ellos
deben mejorar en sus procesos y adaptarse al
sector, no seguir trabajando como lo hacían con
Excel.
Apenas hay unos cuantos errores que se han ido
resolviendo conforme lo pedían. Otra cosa es
que nunca pararon de pedir cosas nuevas.
Para utilizar un ERP hay que adaptarse, en parte,
a sus procesos. Ellos querían seguir trabajando
como hace 15 años y eso es imposible porque
este ERP tiene una forma de funcionar.
Se hicieron un montón de cambios sin pasar ni
un solo euro, pero claro, cuando nos plantamos
y dijimos que nos debíamos ceñir al proyecto
contratado y pedimos dinero por cada nuevo
desarrollo empezaron los problemas de verdad.
Ellos siguen con el portal o con el ERP pero con
otro partner. Han reutilizado equipamiento y
licencias lo que evidencia que la elección del
ERP no era incorrecta.
Esta empresa no estaba madura para poder
incorporar un ERP de estas características,
además no tuvieron un responsable interno
capacitado y con tiempo, clave del éxito de estas
colaboraciones.
El ERP es un sistema estructurado, con unas
capacidades enormes, pero claro, no te puede
dar todo en una pantalla, para eso están los
6 pantallas para ver lo que necesito, es informes. Ellos querían seguir como cuando
evidente que ahora estoy peor. cada uno tenía su Excel y eso no puede ser.
Conclusiones
Si algo he aprendido y aprendo en cada peritaje informático de un ERP, de un portal web, app, etc es que cada
parte involucrada tiene su visión. La tabla comparativa anterior podría extenderse varias páginas y no
terminaríamos nunca. No he hablado de integraciones con terceros, migración de datos, calidad de informes,
etc cuestiones clave para estos proyectos. Sin embargo, en todo ese bosque, nosotros los peritos informáticos,
abogados, jueces, etc debemos estudiar que ocurre, quien tiene la razón, cual ha sido realmente el problema,
cuando en ocasiones no es blanco o negro, sino una gama de grises que pueden repartir la responsabilidad. En
otras ocasiones no es así, es más claro, por ejemplo situaciones donde el proyecto ha sido claramente
infravalorado, mal definido por el partner,… o por ejemplo el cliente no ha puesto al frente a un responsable
de proyecto adecuado con tiempo, con capacidad, no ha colaborado, etc
Cuando termine este mes de diciembre abre asistido a 4 juicios en calidad de perito informático de esta
temática de proyectos. Muchos de ellos se habrían solucionado si hubieran contratado a un director de
proyecto externo que hubiera mediado, dirigido objetivamente, etc el mismo, de manera que al final del
proyecto el coste incremental del director de proyecto externo hubiera ahorrado el fracaso del mismo, los
tiempos invertidos, costes ahora de abogados, procuradores y peritos, entre otros. Lo barato sale caro.
Luis Vilanova Blanco. Perito informático judicial.
Luis.vilanova@leyesytecnologia.com
El ERP salió mal: Lecciones de fracasos
[29/11/2010] Los proyectos de ERP se encuentran entre los esfuerzos más críticos que
compromete a TI, al tocar casi todas las operaciones empresariales esenciales y al ser
técnicamente complejos. Por ello, no sorprende que algunos fallen espectacularmente. A
pesar de que los ERP han estado en el foco de las empresas durante una década, muchas
compañías siguen embarcándose en tales esfuerzos, y más aún, tratan de rehacer los ERP,
debido a las fusiones y los cambios del negocio. Esto es lo que podemos aprender de los
fracasos de los demás y utilizarlos en provecho de sus proyectos.
Me concentro en las implementaciones fallidas de SAP porque los detalles son más fáciles
de adquirir, gracias a la enorme presencia de SAP en las grandes empresas de propiedad
pública y del gobierno, donde los documentos que rodean los litigios y los principales
proyectos cancelados deben hacerse públicos. Sin embargo, las lecciones se aplican a
Oracle y otras implementaciones fallidas de ERP.
¿Qué es un fracaso de los proyectos de ERP? No solo el exceso en los costos, sino que es
un acontecimiento cuyos efectos son tan grandes que obligan a una empresa a replantear
sus ganancias, o una entidad gubernamental a cancelar un proyecto que está bien
financiado.
John F. Kennedy dijo una vez: "La victoria tiene mil padres, pero el fracaso es huérfano".
En el mundo de los proyectos de ERP, lo contrario es casi siempre cierto: Las fallas tienen
un millar de causas. Estas causas casi siempre surgen, señala Michael Krigsman, CEO de la
consultora Asuret y un conocido analista de fallas de ERP, debido a la falta de alineación
entre las tres partes principales de un proyecto: el cliente, el proveedor de software, y el
integrador del sistema.
Fallas del cliente
La falta de adaptación a menudo comienza con problemas en la variable “cliente” de la
ecuación. En su forma más común, consiste en la falta de planificación adecuada. David
Bergen, ex CIO de Levi Strauss & Co., quien llevó a cabo varios proyectos SAP en la
fábrica de prendas de vestir, dice que la mayoría de las empresas no están preparadas para
un proyecto de ERP, porque los pasos básicos no se han realizado adecuadamente. "Las
empresas no suelen ser buenas para el cambio. Además, muchas empresas tienen problemas
en definir sus procesos de negocio. Los que luchan con el rediseño de procesos tendrán
dificultades para alcanzar el éxito y la realización de los beneficios".
Un tema recurrente en los proyectos fallidos es la extralimitación por parte del cliente. Esta
ambición es a menudo alimentada por los integradores y proveedores de software, que
tienden a crear escenarios improbables de éxito y fomentan proyectos de gran tamaño.
Un ejemplo de ello le ocurrió a Shane, una joyería con 200 millones de dólares en ventas.
En 2006, la compañía llevó a cabo un proyecto ERP de 36 millones de dólares que estuvo
enlatado por tres años. Este fue un proyecto de enorme tamaño y probablemente demasiado
grande para la compañía, señala la firma de asesoría ERP, Panorama Consulting. Su
encuesta de 1.300 implementaciones de ERP llega a la conclusión de que la empresa
promedio gasta un 9% de sus ingresos anuales en un proyecto de ERP -Shane gastó el
doble. Shane se declaró en bancarrota en el 2009, culpando en parte al exceso de gastos en
su incompleta aplicación ERP.
Sin embargo, incluso una vez que un proyecto está bien planteado y puesto en marcha con
un plan validado, con frecuencia los clientes no pueden gestionar el proyecto
correctamente. Normalmente, esto toma la forma de malas decisiones, impulsando las
tareas que el cliente debe realizar sobre el personal del integrador, y no manteniendo al
integrador en el plan del proyecto, los horarios, y sobre todo, los presupuestos. Cuando una
empresa con una gestión deficiente del proyecto se asocia con un integrador que no entrega
las especificaciones técnicas, puede acarrear un desastre en la venta al por mayor.
Un ejemplo de esto es FoxMeyer, un distribuidor de medicinas de cinco mil millones de
dólares -el cuarto más grande en los Estados Unidos. El equipo directivo fue uno de los
primeros y ruidosos impulsadores de un proyecto de ERP para racionalizar las operaciones
de almacén. A pesar de las advertencias de que el calendario de aplicación era demasiado
agresivo, la empresa siguió adelante y firmó un acuerdo enorme de distribución de
medicamentos y redujo drásticamente el precio de sus productos en anticipación de la
finalización del proyecto.
El proyecto, sin embargo, cada vez se retrasaba más. Los retrasos se agravaron por las
exigencias cambiantes y los procesos de negocio a consecuencia del nuevo acuerdo.
Mientras la situación empeoraba, los consultores de gestión sugirieron que el proyecto se
redujera y se ejecutará por fases. Sin embargo, el CEO y CIO, que tanto apoyaron la
conversión de ERP, dijeron que habían "apostado la casa" en el proyecto y en su lugar
optaron por ampliarlo. Esta decisión aceleró el fracaso, y en un plazo de dos años, la
compañía se vio obligada a declararse en bancarrota.
Un estudio realizado por Judy Scott (entonces en la Escuela de Negocios de la Universidad
de Texas) concluye que FoxMeyer fue un fracaso de la administración. El empleo de
consultores sin experiencia por el integrador principal, Andersen Consulting, fue un factor
que contribuyó, señala ella, pero el factor que selló el destino del proyecto fue la
incapacidad de la administración para recuperar el control del proyecto y tomar las
decisiones indicadas. Los proyectos exitosos requieren un manejo sensible, reflexivo.
Fallas del integrador del sistema
Debido a que los integradores hacen el trabajo de implementación, con frecuencia son una
parte integral de todas las fallas del proyecto. Sus principales ofensas tienden a consistir en
el uso de consultores que no están suficientemente capacitados en los paquetes que están
instalando -a veces incluso en aspectos básicos de ERP- y tienden a ser pobres en regularse
a ellos mismos. Ambos factores derivan directamente en cómo los integradores cargan: por
hora. (Pocos contratos son buenas ofertas.) Como resultado, el personal más barato que
puede hacer el trabajo resulta el mayor beneficiado, mientras que implementando tareas
adicionales produce un compromiso más rentable.
El conflicto de intereses inherente entre el integrador y el cliente es una fuente frecuente de
controversia, no solo entre los dos partes, sino que con el proveedor de software también.
En el 2009, por ejemplo, Léo Apotheker, el entonces director general de SAP (y ahora
consejero delegado de Hewlett-Packard), condenó en términos muy contundentes como el
interés propio de los integradores (en este caso, Accenture e IBM), llevó a proyectos
fallidos que se reflejaban negativamente en el software, en lugar de hacerlo en los
integradores. "No me importa si se trata de Accenture o IBM... Me parece notable que la
gente [los integradores] estén andando por ahí hablando con los clientes y no tengan
experiencia. [Ellos] no tienen ni idea. Es muy molesto, pero eso es un hecho".
La práctica de los integradores de enviar consultores sin experiencia es tan dominante que
casi todos los pleitos en los proyectos de ERP la mencionan como una causa de acción.
Greg Hatch, director gerente de Alvarez & Marsal Business Consulting, una firma que
ofrece servicios de asesoramiento a clientes en grandes proyectos de ERP, afirma que este
problema se deriva en parte de una percepción equivocada de los integradores: "Se puede
ver como la participación de una empresa, pero realmente debe verse como la contratación
de un equipo de personas. Se debe entrevistar al personal de categoría superior, como el
director del proyecto y jefes de equipo, y estudiar las hojas de vida de los demás. Asegúrese
de que no solo tenga relevancia la experiencia de ERP, pero lo ideal es que hayan hecho
proyectos ERP en su industria en particular".
Como cliente, debe abordar el problema de los plazos extendidos a través de una fuerte
gestión del proyecto. Debe resistir activamente la tentación de empujar el calendario debido
a problemas inesperados o des-proyecciones de tiempo y recursos. Cada retraso es síntoma
de un problema mayor, y el equipo de gestión de proyectos, con el integrador, tiene que
averiguar lo que está mal y arreglarlo.
Hatch observa: "Los proyectos no van al sur, de repente, al final. Ellos siempre han estado
languideciendo poco a poco. Esta "muerte por mil cortes" tiene que ser abordada con
prontitud por el equipo de gestión de proyectos del cliente".
Fallas de los vendedores de software
Los proveedores de software, como SAP y Oracle, tienden a ser culpados por los pecados
de sus vendedores -es decir, prometiendo características o software que no existen o no se
pueden entregar. En muchos casos, esto es simplemente una verdad extendida o una
representación excesivamente ambiciosa de los beneficios, pero de vez en cuando, los
proveedores pueden bajar el acantilado por completo.
Consideremos el caso del gigante de procesamiento de basura Waste Management, que
demandó a SAP por fraude en un fracasado proyecto de ERP en el 2008. En su demanda
afirmaba que SAP había mostrado un software que era una solución "fuera de la caja" para
las necesidades de la empresa. En cambio, el software, según la compañía, fue "una versión
maqueta de aquel software con la intención de engañar a Waste Management". El "software
falso" fue utilizado en varias ocasiones en demostraciones para los ejecutivos de la
empresa. El pleito de Waste Management se liquidó a principios de este año, con SAP
pagando una liquidación en efectivo.
Hatch comenta que escenarios similares pueden ser evitados -en gran parte- consiguiendo
compromisos por escrito. Además, dice, "la demostración debe hacerse con secuencias de
comandos utilizando los datos específicos del cliente y de la industria, no una aplicación
genérica". Y, añade, que con un proveedor Tier 1 de ERP (SAP y Oracle), usted debería ser
capaz de obtener referencias a otras implementaciones que la empresa ha hecho en su
segmento de la industria. Si existe un paquete para su industria, úselo sin personalizarlo
hasta el punto de hacerlo irreconocible.
Krigsman está de acuerdo: "Una de las cosas por las que está pagando a una empresa como
SAP es su conocimiento de los procesos de negocio en su sector. Su software normalmente
encarna las mejores prácticas, por lo que en la medida de lo posible, evite escribir código
personalizado, y en su lugar, donde sea posible, cambie sus procesos de negocio para
alinearlos con el paquete de ERP”.
Triada compleja ERP: Haciéndolo bien
La alineación de la necesidad del cliente, el software del proveedor, y la implementación
del integrador es una tríada muy compleja, cuya naturaleza dinámica requiere que todas las
partes -el cliente, sobre todo- monitoreen la actividad cuidadosamente y respondan de
forma inmediata cuando se produzcan problemas.
Pero incluso los gerentes que están bien versados en las implementaciones de ERP pueden
incurrir en problemas graves e inesperados. Considere a Hewlett-Packard, una empresa que
en el momento de su fracaso interno de SAP tenía una unidad de negocio, que consultaba
sobre los proyectos SAP. La fallida implementación le costó a HP 400 millones de dólares
en los ingresos del tercer trimestre. Según un artículo de Register.co.uk, "empleados de HP
se mantenían sobre camiones de 18 ruedas etiquetando a mano los traslados de servidores
Superdome de millones de dólares y similares. Los ejecutivos de alto rango estaban
obligados a pasar su tiempo aprobando pedidos urgentes de 50 dólares en partes a los
clientes clave".
Como varios analistas señalan, no importa cuán bueno sea usted, los proyectos de ERP son
difíciles. Sin embargo, hay algunos consejos en los que los consultores y analistas están de
acuerdo.
Definir el proyecto por completo. Entender lo que la empresa debe hacer antes, durante y
después de los proyectos. Algunas de las actividades que preceden a un proyecto son
completar las migraciones hacia nuevos sistemas, documentar los procesos del negocio, y la
limpieza de datos.
Una falla en el suministro de datos limpios puede ser costosa. En el 2008, los
manifestantes salieron a las calles de Los Ángeles para protestar contra un proyecto de
nómina que llevó a que algunos profesores sean pagados en exceso, otros mal pagados, y
otros sin paga. Una de las causas fue, según una investigación realizada por Los Angeles
Times, "años de mala calidad en el mantenimiento de registros y una compleja unión de
contratos haciendo que las preguntas básicas -incluyendo a cuánta gente se debe pagar y en
qué puestos de trabajo- sean casi imposibles de responder”. Como muchos consultores
señalan, las preguntas deberían haber sido contestadas antes de que el proyecto se llevara a
cabo. La preparación paga bien en los proyectos de ERP.
Elija al proveedor con cuidado. Bergen recomienda que las empresas que carecen de una
amplia experiencia en proyectos ERP contraten a consultores no afiliados, ya sea con el
vendedor o el integrador potencial para asesorar al cliente con la planificación y ejecución.
Un beneficio clave de estos asesores es que facilitan el diálogo entre los clientes,
integradores y vendedores, y se aseguran de que la solución propuesta se adapte a las
necesidades de la empresa. Los buenos asesores sabrán lo que está faltando en un contrato y
serán capaces de verificar que está recibiendo lo que usted piensa que está recibiendo.
Krigsman subraya la necesidad de obtener todas las promesas sobre el software y la
aplicación por escrito.
Elija el integrador con mucho cuidado. Normalmente, el integrador trae al proveedor de
software, por lo que el aviso previo en la selección del proveedor es aún más crítico cuando
se selecciona el integrador. Entreviste a los altos funcionarios y repase las hojas de vida de
los demás participantes. Asegúrese de que tienen experiencia en el segmento de la
industria.
Prepare un equipo fuerte para que supervise el proyecto. El equipo debe incluir al CEO,
CIO, los jefes de las líneas afectadas del negocio, el oficial de gestión de proyectos (que es
con frecuencia un asesor externo), y cualquier patrocinador principal del proyecto, informa
Hatch. La integración de los ejecutivos de negocios en el equipo es crucial para el éxito,
señala Ross Wainwright, vicepresidente ejecutivo de servicios profesionales de SAP
América del Norte. "Una aplicación ERP es un proceso de negocio, no un proyecto de TI",
señala.
Muchas de las prácticas sugeridas de SAP se centran en el equipo del proyecto. La clave es
su autoridad para actuar en dos ámbitos importantes: el rechazo (o aprobación) de las
solicitudes para alcanzar la aprobación y pidiendo al integrador y al personal de TI que
expliquen y resuelvan los retrasos, las etapas perdidas y excedentes del presupuesto. Sin
esta autorización, el proyecto seguramente se desviará de su curso.
Gestionar activamente el proyecto. Los proyectos de ERP son casi siempre muy amplios,
por lo que es tentador no darles una atención constante. Pero el éxito está en los detalles.
Los miembros del equipo deben estar recibiendo actualizaciones constantes sobre los
avances y problemas. Si surge un problema importante, los miembros disponibles del
equipo de supervisión deben ser convocados y tomar una decisión. Todo el equipo, según
Hatch, debe reunirse como mínimo una vez al mes. Wainright añade que las corrientes en el
proyecto deben ser claras y fáciles de entender, ya que esto facilita las correcciones
rápidamente.
Comprender el impacto en el negocio. Los proyectos de ERP en general, tienen un
impacto profundo en muchas de las funciones internas de la empresa. Es por eso que los
efectos de los grandes proyectos tienen que ser entendidos y previstos desde el principio,
señala Pam Daniels, quien encabeza Stylus Group, una consultoría de desarrollo
organizacional. "La gestión del cambio es una práctica fundamental que debe acompañar a
los proyectos ERP desde el principio hasta el final. Se continúa incluso después de que los
consultores han dejado las instalaciones", agrega. Si se descuida la gestión del cambio, los
empleados pueden resistirse al nuevo software o usarlo mínimamente. De cualquier
manera, los beneficios del proyecto son inferiores incluso si se trata de un éxito técnico.
No escatimar en la formación. Una de las formas más dramáticas de rendimientos
decrecientes es la capacitación insuficiente de los usuarios del nuevo software. En el
modelo de formación más común, el integrador redacta la documentación sobre las distintas
partes a medida del paquete, y luego se entrena a los capacitadores, que en última instancia,
formarán a los usuarios. Pero el modelo de formación de formadores se rompe cuando el
personal del cliente no se desempeña bien capacitando, señala Jennifer Jackson, de Elliott
Jackson Communications, que se especializa en lanzamientos de formación de SAP. Ella
prefiere un método en el que el personal del cliente participe activamente con instructores
externos en las reuniones de información, por lo que las sesiones de entrenamiento pueden
ser muy específicas para la empresa, mientras se base en la experiencia del entrenador
externo con el software de SAP.
Jackson agrega que todo entrenamiento con demasiada frecuencia es precipitado y que las
empresas no dan tiempo a los instructores para que practiquen o perfeccionen su
experiencia en capacitar. Teniendo en cuenta que el beneficio final del proyecto ERP se
basa en el uso que hacen los empleados del software, ella advierte sobre tomar atajos en la
formación o apurar el programa de entrenamiento.
Incluso si sigue este consejo, no hay garantía de éxito, por desgracia. Pero es más probable
que pueda evitar el fracaso con una adecuada planificación, la supervisión activa del
proyecto y una rigurosa gestión del cambio.
Andrew Binstock, InfoWorld (US)

https://cioperu.pe/articulo/5798/el-erp-salio-mal-lecciones-de-fracasos/
Ar quit ect o de sol uciones de negocios (ERP, C RM, POS) de Grupo Consis a.
S e ha escrit o m ucho sobre las funci onali dades de los si st emas de gesti ón
admi ni st rat ivos financi ero o ERP (Ent erpri se R esource P l anni ng o
P l ani fi caci ón de l os R ecursos de la Em presa por l as si gl as en i ngl és), pero
m u y poco sobre l a form a de sel ecci ón del si st em as que admi ni st rará o que
l l evará el cont rol de su negoci o, m ucho m enos sobre l a em presa en que
es t án deposit ando la responsabi li dad de i mpl em ent arl o. Muchas veces se
t om an est as d eci si ones si n fundam ent o t écni co, si n det enerse a pensar, que
es t án suscri bi endo una rel ación de negoci os con una em presa que apoyara
l a gesti ón y cont rol de sus fi nanz as, inventarios, cost os, vent as, act ivos,
pers onal , et c.
P ara muchos ej ecutivos l a decis ión al mom ento de el egi r un Sist em a ER P,
l o del egan al área de t ecnol ogí a o i nform áti ca, si n darse cuent a que est án
del egando una de l as deci si ones m ás import ant es de su empresa, al go asi
com o decidi r l a cont rat aci ón de sus Gerent es que serán los responsa bl es
del éxi to o al fracaso de su negoci o.
Tam bi én es ci ert o que poco se habl a sobre l as i nversi ones que deben
real iz arse en est as tecnol ogí as, y no se cuant i fi ca en t érmi nos económi cos
l a i nversi ón que deben real iz ar para admi ni st rar o cont rol ar sus negoc i os ,
por ej em pl o: su negoci o ti ene un volumen de vent as de 2, 5 o 7 mi ll ones de
dól ares al año para l as pequeñas o m edianas em presas o bi en 15, 30, 50 o
m ás mi llones de dól ares para empresas grandes, sin em bargo, l a
i nform aci ón vit al para l a compañí a se qu i ere m anej ar con sistem as de 5, 10
o 15 m il dól ares, que apenas represent a un valor por debajo del 0.25%.
M uchas veces se conform an con l a gesti ón adm inist rati va fi nanci era que
al canz an a procesar con una o vari as hoj as el ect róni cas, i nvi rt i endo una
gran c anti dad de horas y sus respect ivos cost os que no se cont abi liz an por
ni ngún l ado, y t odo para obt ener un i nform e que al dí a sigui ent e ya s e
encuent ra desact ualiz ado o que si mpl ement e no cuadro con la cont abi li dad
o el i nvent ario.
Las em presas que se encuen t ran en proceso de evolución y en pleno
creci mi ento, ven con buenos ojos l a uti liz aci ón de si st em as de gesti ón
admi ni st rat iva fi nanci era para el cont rol de sus negoci os, sin embargo, no
s aben por dónde empez ar o cuanto i nvert i r.
1 2 cri teri os a consid erar p ara la el ección d e u n b u en ERP
A continuaci ón present o 12 cri t eri os a t ener en cuent a en el proceso de
evaluación de un buen ERP , sin embargo, acl aro por el tí tulo sel ecci onado,
no he t ipifi cados estos si st em as como buenos o m al os, cada em presa deberá
evaluar y considerar que sist em a se acom odan m ej o r a sus requeri mi ent os
funci onal es, y con base a estos crit eri os al gunos sist em as y part ners se i rán
des cal i fi cando por no cum pli rlos.
N ecesi dades f uncional es de la empresa.
Es im perant e que para l a eval uaci ón de un si st em a ERP ini ci al m ent e
deberem os defi ni r y docum ent ar l as necesi dades de adm inistración y
control (requisit os funcional es) de l a em presa, vali dando que el si st em a
ERP a eval uar l os sat isfaga t ot alm ent e o en un porcent aj e m a yor al 80%.
Adi ci onalm ent e debe considerar ot ras funci onal idades que puede bri ndar el
s is t em a en evaluación que l e perm it irá m ej orar sus capacidades ant e l a
posi bil idad de un creci mi ent o previst o.
Fl exi bi li dad y escalabili dad.

Debe consi derarse contar con los recursos necesarios para obt ener l os
res ul t ados deseados, es m uy probabl e que el si st em a evaluado no cumpl a el
100% de l os requi sit os funcional es, pero debe acercarse al m enos al 80%,
de t al form a que el 20% fal t ant e pueda adecuarse l a organiz aci ón y el
s is t em a t enga l a fl exi bil idad para ajustarse m edi ant e pequeños cambios,
adem ás , es fundam ent al que el si st em a evaluado permit a adecuarse a los
cam bi os de l a empresa, a los nuevos requisit os funci onal es y a los cambios
l egal es a l os cual es se enfrent e su negoci o.
Facili dad de uso e int uit i vi dad
Es i mport ant e en l a ev al uación de su sist em a, que el proceso de
i mpl em ent aci ón considere l a real iz aci ón de capaci t aci ones en l a cual se
real i ce t ransferencia de t ecnologí a, que permi t a al usuario asimi l ar el
conocim i ento en un periodo de ti em po razonabl e y que el sist em a cuent e
con form as i nt ui tivas de uso, de tal m anera que l es permit a s er
aut os ufi ci ent es en el m enor ti empo posibl e. Si n embargo, es im port ant e en
es t a et apa que l a ansi edad por echar andar el si st em a no se om it an pasos en
el proceso, generando frust raci ón y desco nt ent o, sobre estas actividades
deben darse pasos seguros y confi abl es.
C ambio constant e e i nnovaci ón.

El si st em a ERP evaluado deben cont ar con el respal do de una empresa que

l e permit a i r m ej orando const ant em ent e, es deci r, que se va ya adecuando a
l as t ecnol ogí as em ergent es, por ej em plo, su sist em a debe cam bi ar en el
m is mo ri tm o que van evoluci onando l as plat aform as con l as cual es
i nt eract úa, por ej em pl o: sist em as operat ivos, bases de dat os, i nt ernet,
pl at aform a en l a nube o disposi tivos móvil es, et c. Es t a caract eríst i ca del
s is t em a ERP y de su proveedor permit i rá que no se est anque en versi ones y
que pueda aprovechar todas l as funcional idades que surj an en el m ercado
t ecnológi co.
Pr esupuest o apropiado
P ara l a sel ecci ón de su si st em a ERP es im port ant e d estinar un presupues to
adecuado a l as necesidades de su negoci o, que l e permit a t om ar l as
decis iones oportunas para di smi nui r sus costos, opti miz ar sus inversiones,
m ejorar sus vent as, control ar adecuadament e sus invent ari os y pro yect ars e
para el crecimi en t o com o product o de l a com pet enci a que se est á generando
en el m ercado.
Al gunas fi rm as para esti m ar el val or de inversión de un sist em a ut il izan un
porcent aj e sobre sus vent as o facturaci ón de l a si gui ent e form a:

T a ma ñ o % de la Facturación Ventas al año

Micro Empresa 1,50% $ 2,000,000

Pequeña Empresa 1,80% $ 5,000,000

Mediana Empresa 2,00% $ 7,000,000

Gran Empresa 2,50% $ 30,000,000

Or gani zación adecuada.

Un t em a que poco se com ent a al m om ent o de eval uar su si stem a ERP es la

i mport anci a que ti ene el cont ar con el personal adecuado en cuant o a
conocim i ento y cant i dad, para hacerl e frent e a l as nuevas real idades de la
em pres a, aunque es bi en sabi do que el per sonal de l a empresa no es experto
en l a apli cación a im pl ant ar, debe contar con los conocimient os básicos
neces ari os para com prender y asi m i l ar l o que l os consul t ores l e t rasl aden
en el proceso. Otro fact or rel acionado es que el dí a a dí a de l a empresa no
s e det i ene, en consecuenci a el proceso de im pl em ent ación es dem andante
t ant o para l os usuari os cl aves com o para el área de TI y di rección del
proceso. Est e fact or sin duda es un punt o fundam ent al para el éxi to del
pro yect o.
Sel ecci ón del partner i dóneo

La el ecci ón del sistem a ERP adecuado a l as necesidades funci onal es de la

em pres a es fundam ent al , pero l a sel ección del part ner idóneo es i gual o de
m a yor im port anci a. Debe evaluarse un partner de impl em ent ación que
cuent e con el respaldo del fabri cant e, con l as debi das cert i ficaci ones, ot ro
fact or im port ant e sobre l a idonei dad del part ner sel ecci onado es l a
experi enci a en proye ct os si mil ares y l a di sponibili dad para at ender
i nci denci as en el m enor ti empo y cost o posi bl e.
Res paldo del f abri cant e

Es im perant e en el proceso de sel ecci ón del sist em a y partner a i mpl ant ar

cuent e con l a posi bi li dad de poder recibi r di rect am ent e del fabri cant e el
apo yo necesario para resol ver i nconveni ent es, es deci r, que ant e un
s it uaci ón no solventabl e por el part ner sel eccionad o, l os casos puedan s er
es cal ados hast a el fabri cant e qui en deberá resol ver por sus propios m edios
o con apoyo de ot ros partner los casos report ados. Esto garantiz a que ante
cualqui er si tuaci ón se cuent a con el respal do necesario para resolver
probl em as qu e se present en en el proceso.
Adecuaciones a l as funcionali dades estándares
El s is t em a ERP deberá cont ar con herrami ent as de program ación que
permi t an al cl ient e poder
el aborar sus propi os form ul arios, agregar funci onal idades, el aboración de
report es, et c.,
en el m ismo entorno en el que est á desarroll ado el sist em a.
Segur idad de usuarios por rol es

Es fundam ent al l a identi fi cación del número de usuari os y defi ni r los rol es
que desem peñan,
es to t endrá un fuert e im pact o sobre l a form a de li cenci am i ento, si es
concurrent e o nombrada,
t ambi én deberá consi derarse si el si st ema evaluado ti ene l a caract erí st i ca
de s eguri dad de usuarios por rol es vs funci onali dades, es deci r si l as
l i cenci as pueden di ferenci arse por el tipo de rol ,
t rat ando que l a inversión en li cenci as cubra l as necesi dades del cl i ent e
evit ando el sobre
o sub di m ensi onamient o en núm ero y t i po de li cenci as.
Infr aes truct ura informát i ca

Debe t om arse en cuent a l a i nfraestruct ura i nform áti ca, aunque s on

el em ent os com pl em entarios del si st em a, l os res ul t ados obt eni dos t am bién
dependerán que t an buen análi si s se ha ya real iz ado para l a sel ecci ón y
dim ens ionam i ento adecuado de l os servi dores, redes, com uni caci ones,
s is t em a de respaldo, conti ngenci as, et c., de i gual form a es necesario para
es t e dim ensionam i ent o l a defi ni ción de topologí a de instal ación de la
apli cación, por ej empl o: i nst al aci ón t odo en uno, es deci r que t ant o l a bas e
de dat os, el si st em a ERP y ot ras funcionali dades rel aci onadas a la
apli cación serán i nst al adas en el m ismo servi dor o bi en si se uti liz ara un
s ervi dor para apl i caci ones, uno para base de datos, ot ro para obj et os, et c.
de i gual modo es necesario que se defi na si l a estrat egi a de servidores se
real iz ara
m edi ant e servi dores fí si cos o vi rt ual es.
Valor es agregados

En l a evaluación del si st em a ERP deberá consi derarse val ores agregados

s um inist rados por el
fabri cant e del si st em a, t al es como consul t as y report es est ándares de l a
apli cación, generación de cubos de i nform aci ón, m ét ri cas e indi cadores
cl aves del desem peño, port al de infor m aci ón y ot ras m ás
a t ener en cuent a, com o l a exi st enci a de verti cal es de i ndust ri a, ej em pl o:
farm acéuti cas o l aborat ori os, pro yect os de construcci ón, m anufact ura
dis cret a, et c. los cual es pueden com pl em ent arse
en impl em ent aci ones por fases o et apas del pr oyect o.
UN ERP PROTEGE TU FERRETERÍA FRENTE
A UN DESASTRE NATURAL
06 Nov 2017 Arístides Palma, Director General de Zafiro Sofware
Mi Negocio

 construccion

 2017Noviembre Diciembre

 Ferretería

 software
497 times

Frente a las graves afectaciones provocadas por huracanes y sismos, los sistemas de Planificación de
Recursos Empresariales salvaguardan un activo fundamental de la empresa: la información.
Los recientes huracanes y terremotos que vivió México han demostrado que la naturaleza puede afectar
severamente al sector empresarial, un área vital para la economía del país.
Las interrupciones inesperadas en las operaciones de una compañía pueden causar pérdidas monetarias en
millones de pesos o dólares, dependiendo del tamaño de usuarios o clientes que tenga la empresa. Piensa
por un momento cuánto dinero perderías si las operaciones de tu empresa se detuvieran por dos días o una
semana.
Una de tantas maneras en que un negocio puede hacer frente a un evento como un huracán o un sismo, es
a través de la tecnología con el fin de proteger sus datos. Una solución de ERP (Enterprise Resource
Planning) no sólo organiza toda la información de una compañía, también la protege, la respalda y la pone
a disposición de directores y gerentes desde cualquier ciudad, estado o país donde se encuentren.
Un ERP es un software profesional y especializado que proporciona estrategias para el manejo y control
de prácticamente todas las áreas de un negocio, además de ser flexible y adaptable a los cambios que hacen
evolucionar al mercado.
Un ERP dirigido al sector ferretero ayuda no sólo a obtener una visión integral del negocio y todas sus
áreas, sino a la automatización y gestión de todos los procesos, haciendo más fácil la toma de decisiones.

¿Por qué implementar un ERP en tu ferretería?

1. Porque integra y consolida la información de las áreas vitales de una

organización:finanzas, contabilidad, inventarios, recursos humanos, producción, calidad,
mantenimiento, cadena de suministros y marketing. Los pequeños negocios manejan las áreas de su
negocio en forma separada, mientras que un ERP permite su unificación. Un negocio tiene que verse
como un todo junto, y no por separado.
2. Porque te ayuda a adaptarte según el desenvolvimiento del mercado, y ayuda en la planeación
de imprevistos. Al tener mayor disponibilidad de la información, es posible realizar estimaciones y
previsiones realistas que te permiten anticiparte frente a escenarios futuros, basadas en información
directa en la operación de la empresa.
3. Porque protege tu información, así de simple: un ERP te permite mantener tus datos
protegidos gracias a los altos niveles de seguridad con los que cuentan.

Los desastres naturales no pueden ser detenidos por el hombre, pero sí tenemos la capacidad de la proteger
a nuestro personal e información, para el bien de nuestros empleados, clientes y proveedores. Para este fin
es recomendable que cada negocio ferretero elabore un “Plan de Recuperación de Desastres” e
implemente un ERP que pueda anticiparse y ayudar a su óptima gestión.
Disponer de un ERP para ferreterías te ayudará no sólo a ahorrar tiempo y dinero, te dará una visión más
clara de cada una de las partes de u negocio; permitiéndote identificar las áreas e oportunidad, las
fortalezas, qué productos se venden más o cuándo es el mejor momento para comprar mercancías, invertir
en recursos humanos, etcétera. Sobre todo te ayudará a hacerle frente a cualquier adversidad.
Ingeniero Arístides Palma es fundador de Zafiro Software, experto en tecnología egresado del ITESM,
con Maestría en Administración de Sistemas de Información. Fue fundador del Clúster Tamaulipas de
Tecnologías de la Información, además de ser catedrático.