M A NUA L INCOM P LETO DE LOS D ETA LLES FINOS                   D E LOS ERPNormalmente se evalúa a los productos ERPs por...
3    ¿Qué relación hay entre sus hijos y las sucursales?En este artículo se trata sobre la estructura de datos para dismin...
En el caso que se da como ejemplo, tanto el talle como el color son dimensiones que terminan de defi-nir, por intersección...
Lo más usual y difundido, por cuestiones de sencillez del código, es el lockeo pesimista. Este consiste entomar una entida...
Los primeros ERP’S se desarrollaron para fabricantes y vendedores de bienes tangibles. Por ese motivohoy se siguen sintien...
7    ¿Qué pasa cuando se corta la luz?Pedro es un amigo que me pidió ayuda para comprar un ERP. Su mayor preocupación es u...
Se pueden distinguir tres tipos de actividad:    •    Actividades colaborativas: Un conjunto de usuarios trabajan sobre un...
9    Motor de impuestos autónomoHistóricamente, los ERPs calcularon los impuestos desde las propias transacciones.Usualmen...
Esto último implica el poder ver, por ejemplo, la dirección que tenía un cliente antes de que hubierainformado una mudanza...
En principio existen dos políticas claramente diferenciadas:a) La de puestos concurrentes, la cual implica contar cuanta g...
Próxima SlideShare
Cargando en…5
×

Compendio incompleto de los detalles finos de los erp

302 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
302
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Compendio incompleto de los detalles finos de los erp

  1. 1. M A NUA L INCOM P LETO DE LOS D ETA LLES FINOS D E LOS ERPNormalmente se evalúa a los productos ERPs por los grandes títulos. Si el producto es cliente servidor otres capas, si tiene workflow definible o tableros de comando, si integra manufactura o recursos huma-nos, entre otros.Pero dentro de los módulos básicos del ERP existen detalles finos que hacen que una aplicación seamucho mejor o mucho peor al momento de utilizarla, que permita escalar a gran cantidad de puestos ono, que sea útil para empresas localizadas en distintos países, etc.En esta sección iremos viendo una colección de puntos que pueden ser muy útiles a la hora de evaluarproductos. División consultoría de Evaluando ERP.1 Imputaciones de facturaEn la gran mayoría de los ERP’s, cuando se factura, aunque el documento contenga numerosos ítems, ala cuenta corriente va a parar un total que es la sumatoria de todos esos ítems y los impuestos agrega-dos. Esto es lógico ya que de lo contrario el resumen de cuenta de un cliente podría ser una cosa extre-madamente larga y compleja.Pero existen muchos casos donde los clientes pagan algunos ítems específicos de una factura y no otros(podría ser, por ejemplo, por no cumplimiento o disconformidades), o los impuestos de la misma.En algunos ERPs es posible especificar en un recibo, a que ítems de una factura aplica total o parcial-mente.Las ventajas de este manejo son múltiples: En principio permite mantener clara y bien definida la cuentacorriente del cliente, pero por otra parte permite manejar en debida forma las comisiones por ventasque se calculan sobre cobranzas y tipo de productos.2 Atributos sobre la fusión de inventariosCuando se manejan inventarios en un sistema existe para cada producto un detalle mínimo de defini-ción del mismo, debajo del cual no hay apertura de información.Vea el caso de los granos. Realmente es interesante. Por ejemplo el trigo a granel. Los que están en eltema hablan del lote (con los datos de fechas, o características de calidad), pero lógicamente dentro dellote es imposible e inútil tener mayor discriminación. En este caso el único atributo de fusión es el lote.¿Qué pasa con los productos de mayor elaboración? Por ejemplo, en una fábrica de bicicletas. Los fabri-cantes agrupan las mismas por lotes de producción, pero dentro de esa agrupación distinguen a cadauna de ellas por un número de serie. En este caso los atributos de fusión son dos: Lote de producción yserie.Dicen que la Argentina podría llegar al absurdo de importar leche. Mientras esto no suceda, el ERP de- 1bería manejar ciertas particularidades de los lácteos, donde hay lotes de producción, pero dentro de los Páginamismos, fechas de vencimiento diferentes. En este caso los atributos de fusión son el lote y la fecha devencimiento.Lógicamente existen muchos otros casos, algunos más o menos obvios, otros muy específicos de merca-dos verticales.Por este motivo es muy importante que el ERP permita definir los atributos de fusión para cada pro-ducto independientemente.
  2. 2. 3 ¿Qué relación hay entre sus hijos y las sucursales?En este artículo se trata sobre la estructura de datos para disminuir la carga de los mismos. En losviejos sistemas de gestión el ABM de clientes era muy popular (ABM= Altas, Bajas Modificaciones). Alingresar a la “pantalla” de ABM se cargaban los datos que incluían información tal como domicilio, telé-fono, contactos, etc.Algo parecido sucedía con el ABM de proveedores en el que se cargaba información similar.¿Y cuando la misma persona jurídica era cliente y proveedor de la empresa? ¿Qué pasaba?En este caso los datos debían ser cargados dos veces, y consecuentemente actualizados dos veces en sise producían variaciones.El mundo va cambiando y hoy las relaciones cruzadas son comunes. Resulta que una misma personapuede ser cliente, proveedor, empleado, y familiar a su vez de otro empleado.Algunos ERPs rediseñaron su estructura de datos para conceptualizar lo siguiente: Existen personasfísicas o jurídicas que cumplen roles, esto es el rol de cliente, o de proveedor, o de socio, o de lo quefuera, pero su información personal no varía fundamentalmente en función de papel que cumpla.Es así que cuando se ingresan por ejemplo los domicilios, la web, o los teléfonos de un cliente, el mismoingreso de datos sirve también para su eventual rol de proveedor disminuyendo las tareas de manteni-miento, y fundamentalmente, aumentando la coherencia de la información del sistema.Así, por ejemplo, se hace viable el mantener cuentas corrientes donde se intercambian bienes o servi-cios con proveedores que a su vez son clientes.Y con una estructura de datos así, también se resuelven problemáticas que suelen ser extrañas para losERPs como ser el manejo de los socios de un club, los alumnos de un colegio o los afiliados a una obrasocial, que reconocen vínculos familiares, por nombrar algunos ejemplos.¿Usted tiene hijos o sucursales?Por ejemplo un ERP que debe facturar en un colegio debe reconocer el vínculo de padre, hijo, hermano.En este caso el alumno no es el cliente del colegio, sino su padre, y normalmente se deben agrupar lascuotas de los hermanos en una misma transacción.Lo más curioso que llegamos a ver fue definir a todos los miembros de una familia como un conjunto declientes con sucursales. Este tipo de soluciones es posible, pero antinatural y generadora a posteriori demúltiples problemas, que usualmente se sufren luego durante años.4 ¿Qué talle usa? ¿Que color quiere? 2 Página¿Qué tienen en común las zapatillas con los bulones? ¿En que se parecen un par de zapatos y los vi-drios? ¿Por qué los tornillos y las botas de trabajo son parientes lejanos?Un ítem fundamental en algún tipo de negocios es el manejo de dimensiones en el catálogo de artículos.El ejemplo más típico de esto es el uso de talle y color en los productos.
  3. 3. En el caso que se da como ejemplo, tanto el talle como el color son dimensiones que terminan de defi-nir, por intersección, las ocurrencias de los productos en cuestión.O sea, una zapatilla Interminable (¿Quién las recuerda?) no existe en si misma, sino por ejemplo en talle37 y color verde.Los ERP’s que no manejan dimensiones de los productos obligan a definir como un artículo diferenciadoa cada intersección posible de las dimensiones, o sea zapatilla 37 verde, zapatilla 37 marrón, ….., zapati-lla 40 verde, … y así sucesivamente. Es decir, si hay 10 talles y 50 colores se deden definir 50 artículos,con la mayoría de sus atributos repetidos. Si se agregan, por ejemplo, 3 materiales diferentes, ya secuentan con 150 intersecciones, o sea 150 artículos en el catálogo.¿Qué sucede con artículos como los bulones o flejes metálicos de medidas y materiales diversos? Sepodrían tener miles, o decenas de miles de intersecciones por cada artículo, lo cual vuelve inviable estemodo de solución del problema.Para estos casos hay dos niveles de soluciones: 1- La solución más básica. Los productos que permiten definir dimensiones homogéneas para to- do el catálogo de artículos: Esto funciona bien, por ejemplo, para zapaterías, ya que práctica- mente todos los productos que venden se definen por las mismas intersecciones. No es útil de ningún modo, por ejemplo, para una ferretería, que vende artículos extremadamente hete- rogéneos. 2- La solución elegante. Los productos que permiten definir dimensiones heterogéneas para los diversos tipos de artículos: Esto implica que cada artículo en particular puede tener su defini- ción dimensional específica. Se pueden vender ventanas que se definen por alto, ancho y gro- sor del vidrio, tornillos por medida y paso de la rosca, y botas de trabajo que van por talle y co- lor.La definición de dimensiones tiene luego implicancias en las listas de precios, en las fórmulas de manu-factura, en el manejo transaccional y en otras partes más.La realidad es que pocos productos disponen de alguna de las dos soluciones enumeradas, y esto haceque muchos sectores de la industria que requieren ERP deban solucionar este tema con respuestas muyrústicas.5 Un tema clave para más de 30 puestos de trabajo- Política de BLO- QUEOS O “lockeos”Este punto puede parecer muy técnico y de escasa significación práctica, pero como se verá a continua-ción es el tema fundamental que define si un ERP puede o no escalar, funcionando bien más allá de los20 o 30 puestos de trabajo. De hecho este es un punto fundamental que opera como divisoria de aguasentre productos para empresas pequeñas, y productos para empresas medianas o grandes, si bien severá que pueden encontrarse sorpresas. Por División Consultoría de Evaluando ERP. 3 PáginaLas alternativas que existen para lockear las entidades son básicamente dos. a) La optimista b) La pesimista.
  4. 4. Lo más usual y difundido, por cuestiones de sencillez del código, es el lockeo pesimista. Este consiste entomar una entidad y cerrarla al acceso de cualquier otro potencial usuario. Existen a su vez dos nivelesde cierre: • Completo: ningún otro usuario puede ni siquiera leer dicha entidad. • Parcial: solo se inhibe la edición de dicha entidad.Por ejemplo: Un usuario accede a modificar los datos de un cliente, y el lockeo pesimista cierra el accesoa dicha entidad. En el caso más leve solo negará el acceso a otro usuario que quisiera a su vez editar elmismo cliente, en el caso más extremo (y más usual) impedirá, que se le pueda facturar o emitir cual-quier tipo de transacción.En el caso del lockeo optimista nunca se cierra el acceso de nadie a nada.Como funcionaSuponga el caso más simple detallado previamente:Un usuario A entra a modificar los datos de un cliente Z. La sesión del usuario A se lleva una copia delcliente Z, con la fecha y hora de última modificación del mismo.Ahora suponga que dicho usuario A deja su pantalla en el medio de la transacción por una llamada tele-fónica, o porque se va a almorzar. Entonces entra otro usuario B a modificar dicho cliente Z, y como seutiliza lockeo optimista, este último usuario también accede.Suponga ahora que B modifica y graba antes que el usuario A retorne de su almuerzo. El cliente Z quedacon una fecha-hora nueva registrada.Cuando A retorna a utilizar el sistema y termina la modificación que tenía en curso, al intentar grabarverá que la operación no se realiza por no tener una copia actualizada del cliente Z. Esto puede ser mo-lesto para algunos, pero es el único modo de evitar lockeos peligrosos en implementaciones que super-an los 50 puestos. De este modo funcionan las reservas de las compañías aéreas, de otro modo una consulta acerca de un pasaje de alguna ignota agencia de turismo podría lockear las consultas de un vuelo completo. Aunque resulta extraño, algunos productos que siempre fueron vendidoscomo para empresas grandes, utilizan política de lockeo pesimista, generando enormes inconvenientes.Tal es el caso de J.D. Edwards. 4 Página6 Especial para las empresas de serviciosGran parte de los ERP’S implementados no contemplan el negocio de los servicios. Tal es así que el soft-ware quiere venderlos y facturarlos como bienes físicos sin stock, lo que implica perder una gran partede la información que involucra ese negocio. Por División Consultoría de Evaluando ERP.
  5. 5. Los primeros ERP’S se desarrollaron para fabricantes y vendedores de bienes tangibles. Por ese motivohoy se siguen sintiendo los efectos de dicha génesis.Si bien las empresas de servicios masivos (de telefonía, de electricidad, de gas, etc) y los bancos, acce-dieron a la informática durante las décadas de los 60 y los 70, incorporaron el concepto de planeamien-to de recursos empresariales a mediados de los 90. En el caso de las empresas de servicios profesiona-les, muchas de ellas implementadoras de ERP, lo hicieron incluso más tarde. De hecho muchas de ellassiguen utilizando soluciones caseras, o simplemente Excel. A propósito, en nuestro centro de Evaluacióningresan empresas buscando ERP que contemplen la operatoria de empresas de servicios.Pero cuando estas empresas de servicios profesionales deciden implementar un ERP, se encuentran quela gran mayoría de los mismos no conceptualizan lo que es un servicio. Los ERP’S están muy bien ade-cuados para vender galletitas, chapa, yogurt o medicamentos, manteniendo su lote, su serie, su fechade vencimiento, etc.Pero a la hora de vender servicios, la mayoría de los mismos quieren venderlos y facturarlos como bie-nes físicos sin stock, lo que implica perder una gran parte de la información que involucra ese negocio.El problema fundamental es que la gran mayoría de los ERPS no tienen un concepto definido de servicio,y suelen tener, en el mejor de los casos, un archivo con los títulos de los mismos que pueden ir a parar aun pedido o una factura.Hacen falta varios elementos para tratar adecuadamente este tema: • El sistema debe conceptualizar los recursos que prestan servicio, y tales recursos deben estar sujetos a un calendario propio. En el caso de tratarse de un recurso humano esto debe estar conectado con el módulo de RRHH de modo, por ejemplo, de anticipar vacaciones o licencias. • El software debe tener especificado que recursos pueden prestar el servicio, y con que tasa de eficiencia realizan dicha labor. O sea: Si tengo en la compañía el servicio de relevamiento, y el mismo puede ser cumplido por un junior, eventualmente por falta de los mismos podría ser cumplido, incluso con mayor eficiencia, por un semi senior, incluso por un senior o un gerente. Es conveniente que este tipo de relaciones se especifique para casos de emergencia, y pensan- do que todo esto hoy camina hacia la automatización y la programación automática de los re- cursos. • Se debe poder generar la solicitud del servicio, de modo de comprometer el calendario de los recursos adecuados, y esto funciona como un pedido de ventas en el caso de venta de bienes. Se especifica claramente cuando, o en que franja de fechas y horarios puede ser prestado el servicio, si se requiere algún tipo de equipo especial, etc. • Se debe poder generar un parte de servicios que informa el cumplimiento del trabajo solicita- do, y que funciona como lo hace el remito en la venta de bienes. Este reporta quien, cuando y como se prestó el servicio, si hubo algún resultado especial, algún inconveniente, etc. • Finalmente lo que se debe facturar son los partes de servicio. 5Manejando adecuadamente estas estructuras, se puede ir paulatinamente a la asignación automática de Páginarecursos a tareas, que sin dudas, será el siguiente paso.
  6. 6. 7 ¿Qué pasa cuando se corta la luz?Pedro es un amigo que me pidió ayuda para comprar un ERP. Su mayor preocupación es una posiblecrisis de energía y su problema es: qué sucedería ante un corte de electricidad. Yo le dije “Pedro, cuan-do se apara la luz, se enciende….”Le recomendé “pídele al proveedor que cargue una transacción de muchos ítems y, mientras la estácargando, desconecta abruptamente la computadora”. Además de la antipatía que esto produce ¿Quécree usted que puede pasar? Cuando se corta la luz, se enciende la integridad transaccional. Por la Divi-siónQuizás el problema más clásico de los ERP’S, por tratarse de productos que realizan transacciones muycomplejas y extensas, es el de la integridad transaccional.Veamos un caso típico: Un vendedor realizó una operación que da salida a 40 ítems de mercaderíasdiferentes a un buen cliente. Llegó el momento de registrar la transacción para facturarla y afectar losarchivos que correspondan y de golpe……… la electricidad, la red o el servidor fallan.Entonces sucede algo por el estilo: Resulta que toda la mercadería, o una parte de ella figura como egre-sada, pero no se registró la deuda en la cuenta corriente del cliente.Esto ocurre cuando el ERP en cuestión no tiene integridad transaccional, es decir, que el sistema nogarantiza que la transacción se graba completa, o no se graba.Típicamente los sistemas tenían este tipo de inconvenientes antes de la llegada de los motores de basede datos, que proveyeron herramientas denominadas de control de sección crítica.Los productos de software que garantizan integridad transaccional no pueden evitar que la electricidadse corte, pero lo que hacen es grabar la transacción completa en un área especial, y recién una vez com-pletada la misma guardan los datos. En caso que la transacción no se complete, los datos de la mismaserán eliminados completamente debiendo cargarse nuevamente.La integridad transaccional es una condición necesaria para garantiza la coherencia de la información enla base de datos.8 El Workflow de los ERP’sEl Flujo de trabajo (workflow en inglés) es el estudio de los aspectos operacionales de unaactividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su ordencorrelativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómose le hace seguimiento al cumplimiento de las tareas.Generalmente los problemas de flujo de trabajo se modelan con redes de Petri.Mediante una red de Petri puede modelizarse un sistema de evolución en paralelo compuesto de variosprocesos que cooperan para la realización de un objetivo común. 6Si bien el concepto de flujo de trabajo no es específico a la tecnología de la información, una parte esen- Páginacial del software para trabajo colaborativo (groupware) es justamente el flujo de trabajo.Una aplicación de Flujos de Trabajo (WorkFlow) automatiza la secuencia de acciones, actividades o tare-as utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de susetapas y la aportación de las herramientas necesarias para gestionarlo.
  7. 7. Se pueden distinguir tres tipos de actividad: • Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común. Tiene entidad el trabajo de cada uno de ellos en sí mismo. • Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particu- lar, estableciendo los mecanismos de cooperación entre ellos. No tiene entidad el trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final. • Actividades de coordinaciónObjetivos de un sistema de WorkFlow • Reflejar, mecanizar y automatizar los métodos y organización en el sistema de información • Establecer los mecanismos de control y seguimiento de los procedimientos organizativos • Independizar el método y flujo de trabajo de las personas que lo ejecutan • Facilitar la movilidad del personal • Soportar procesos de reingeniería de negocio • Agilizar el proceso de intercambio de información y agilizar la toma de decisiones de una orga- nización, empresa o instituciónEl flujo de trabajo que de los ERPsExisten una gran cantidad de productos de Workflow. En general los mismos permiten conectar aplica-ciones, llevar tareas a distintos responsables dentro de una organización, y disponibiliza la visual de lasmismas desde tableros de unificación.Los ERPs pueden utilizar estas herramientas para tareas colaterales, como pueden ser la autorización deuna transacción, o el envío de mails de aviso de eventos, u otras tareas sencillas.En el ERP se manejan transacciones y por eso se implementa una modalidad de Workflow conocidacomo multi estado que, los productos no especializados no soportan.Excepto honradas excepciones estos workflows específicos son fijos de cada aplicación y vienen arma-dos en la estructura del producto, tales como el circuito de compras, de ventas o de pagos.La gran diferencia que existe entre los ERP’s colaborativos con los workflows tradicionales es que en losERP’s las transacciones pueden explotar en N instancias, mientras que en las herramientas de flujo detrabajo tradicionales operan como instancias únicas.Un ejemplo sencillo aclara el concepto. En un Workflow tradicional, por ejemplo, un ticket de reclamosolo tiene un estado en un momento dado. En cambio, en un ERP, un pedido puede estar parcialmenteremitido, incluso una parte del remitido puede haber sido facturado y cobrado. Es decir que ese pedido,nacido como una instancia de Workflow ahora está abierto en cuatro instancias. 7Esta problemática no es cubierta por ningún Workflow tradicional, y de hecho muy pocos ERP’s permi- Páginaten el manipuleo del Workflow que incorporan.
  8. 8. 9 Motor de impuestos autónomoHistóricamente, los ERPs calcularon los impuestos desde las propias transacciones.Usualmente dicho cálculo estaba indisolublemente vinculado desde el código fuente a las facturas, lospedidos, los pagos, etc. ¿Cuál es la solución para una empresa usuaria que opera en varios países y endiferentes estados? Por la División consultoría de Evaluando ERP.Este hecho fue uno de los fundamentales a la hora de complicar la internacionalización de los ERPs.Dicha falencia estaba ocasionada en el hecho de que, la gran mayoría de los mismos, incluidos SAP oEdwards, los más antiguos, comenzaron como productos a medida para empresas que requerían algu-nos módulos de administración.Lógicamente, en la década del 70 y el 80 era inimaginable la estandarización que sobrevendría, y por lotanto nadie preveía aislar el cálculo impositivo de las aplicaciones de modo de poder modificarlo fácil-mente.A principios de los 90, con la internacionalización avanzando, algunos productores de software comen-zaron a concentrar los cálculos impositivos en módulos específicos, de modo de aislarlos de las aplica-ciones.Así es cómo nacen los más conocidos como “tax engines” o motores de impuestos.Normalmente se encuentra disponible un motor de impuestos, en los paquetes de software de gestiónempresarial más sofisticado. Si están bien hechos permiten la definición y redefinición de cualquier tipode impuesto, aplicarlo a cualquier transacción, y finalmente liquidarlo correspondientemente.Con un motor de estas características, se define el impuesto, o se define el comportamiento de los yaexistentes de modo de mantenerlo adecuado a las exigencias de las agencias impositivas de cada regióny país.El motor de impuestos es uno de los elementos fundamentales que permite que un ERP se adapte adiferentes países, incluso, si la aplicación lo soporta, debe permitir operar la misma instancia del produc-to en diferentes geografías simultáneamente.10 HistoricidadSe puede decir que esta es una de las funcionalidades claves que dividen productos para grandes em-presas de productos para PYMES. Por la División Consultoría de Evaluando ERP.La historicidad se vincula estrechamente con la auditoría, y se define de modo muy simple: Historicidadcompleta significa poder ver el estado del sistema en cualquier momento del tiempo pasado. Es decir 8 Páginaque se puede obtener, por ejemplo, el listado de facturas impagas a como era hace 45 días, el reportede inventarios como estaba hace 6 meses, o bien, ver el estado de cualquier entidad del sistema encualquier momento del pasado.
  9. 9. Esto último implica el poder ver, por ejemplo, la dirección que tenía un cliente antes de que hubierainformado una mudanza, conocer el precio de un artículo previo a su aumento, la condición impositivade un proveedor un año atrás, o cualquier otra combinación que pudiera ocurrir con cualquier entidaddel sistema.Es importante señalar que la historicidad en un sistema es casi indispensable para poder cumplimentarlas exigencias que plantean las normas Sarbanne Oxley.11 No todos hablan igual en América hispano parlanteUn tema que surge cuando uno utiliza productos que no son desarrollados en el país de uso como Méxi-co, Colombia, Perú o cualquier otro de América hipano parlante, es el tema del idioma.Es simple comprender que no es práctico utilizar un sistema de gestión en inglés o portugués o en untipo de español que no es el que se habla localmente. Los productos internacionales usualmente tienenprevistos mecanismos para solucionar ese tipo de inconvenientes. ¿Realmente lo tienen? Por Divisiónconsultoría de Evaluando ERP.La cuestión es que la solución puede ser de de diversas ‘calidades’, y es interesante conocerlas. • Solución versión en español: El sistema tiene una versión, con un ejecutable especial, para un idioma determinado. Esta solución es la más sencilla y la más débil desde el punto de vista técnico. El que exista un ejecutable en el idioma que no es original implica una versión del pro- ducto desvinculada base. Esto trae aparejado demoras en la disponibilidad de las nuevas ver- siones, e incluso puede implicar incompatibilidades en la persistencia de los datos en las tablas. Es una solución que prácticamente no se puede utilizar si el sistema es utilizado simultánea- mente por usuarios que de idiomas diferentes de modo concurrente. • Solución con diccionario único: Existe un diccionario de traducción donde se especifica en los mensajes de output como deben ser vistos en el idioma de los usuarios. • Solución de diccionario múltiple: El sistema dispone de N diccionarios de traducción, y los mismos se aplican de acuerdo al usuario que accede a la aplicación. De este modo se puede manejar una aplicación multi país. Es decir que al mismo tiempo está accediendo un uruguayo, que ve el sistema en español, y un brasilero que lo ve en portugués. Es sin duda la solución mas avanzada al problema planteado.12 Cómo controlar los puestos de trabajoCuando se adquiere un ERP, usualmente el mismo es vendido por ‘cantidad de puestos de trabajo’.Esto significa que se adquiere el producto para ser utilizado por una cantidad de personas determinada.Pero la cuestión no es tan simple, y puede dar lugar a equívocos y a diferencias sustanciales en los valo-res de adquisición. 9 Página
  10. 10. En principio existen dos políticas claramente diferenciadas:a) La de puestos concurrentes, la cual implica contar cuanta gente estará utilizando como máximo el ERP en un momento determinado. O sea, podría tener 200 personas utilizando el sistema en distin- tos turnos que, de movida, implicaría la no concurrencia de más de 100 en ningún momento. Esta política es muy clara en su definición y en su control.b) La de puestos nominales, que requiere la adquisición de un puesto para cada persona que poten- cialmente accederá al sistema en algún momento. O sea que en el caso anterior de 200 personas trabajando en dos turnos, la empresa debe adquirir 200 puestos. La cosa se complica cuando hay mucha gente que reporta datos de modo muy eventual, la cual puede ser muy numerosa.En resumen: Cuando evalúe el precio de un ERP y le digan el precio por puesto siempre verifique quetipo de puesto le están vendiendo (o está comprando). 10 Página

×