¿Qué Software es apto para su empresa?

Acceda a nuestros evaluadores

Clasificación de software según su licenciamiento

Las licencias de software son contratos de uso de un determinado software, dicho contrato es sostenido entre el productor del software y el usuario. Esto quiere decir que cuando un usuario adquiere una licencia en ningún momento compra el programa o se convierte en propietario de él, solamente adquiere el derecho de uso, aunque haya pagado por adquirir la licencia. Al igual que cualquier otro contrato, las licencias son muy importantes tanto para el software propietario como para el software libre.

A continuación se presenta la clasificación del software según su licencia de uso.

Software propietario

En términos generales, el software propietario es software cerrado, donde el dueño del software controla su desarrollo y no divulga sus especificaciones.

El software propietario es el producido principalmente por las grandes empresas, tales como Microsoft y otras. Antes de poder utilizar este tipo de software se debe pagar por el. Cuando se adquiere una licencia de uso de software propietario, normalmente se tiene derecho a utilizarlo en un solo computador y a realizar una copia de respaldo. En este caso la redistribución o copia para otros propósitos no es permitida.

Software shareware o de evaluación

El software tipo shareware es un tipo particular de software propietario, sin embargo por la diferencia en su forma de distribución y por los efectos que su uso ocasiona, puede considerarse como una clase aparte.

El software shareware se caracteriza porque es de libre distribución, de tal forma que se puede usar, contando con el permiso del autor, durante un periodo limitado de tiempo, después de esto se debe pagar para continuar utilizándolo, aunque la obligación es únicamente de tipo moral ya que los autores entregan los programas confiando en la honestidad de los usuarios.

Este tipo de software es distribuido por autores individuales y pequeñas empresas que quieren dar a conocer sus productos. Muchas veces por ignorancia los programas de esta clase se utilizan ilegalmente. A menudo el software shareware es denominado como software de evaluación.

Software de demostración

Es el software con fines netamente de demostración, el cual no es 100% funcional o deja de funcionar después de cierto tiempo. Es similar al software shareware con la diferencia de que en esencia es sólo software propietario limitado que se distribuye con fines netamente comerciales.

Software libre

El software libre es software que, para cualquier propósito, se puede usar, copiar, distribuir y modificar libremente, es decir, es software que incluye archivos fuentes. La denominación de software libre se debe a la Free Software Foundation (FSF), entidad que promueve el uso y desarrollo de software de este tipo. Cuando la FSF habla de software libre se refiere a una nueva filosofía respecto al software, donde priman aspectos como especificaciones abiertas y el bien común, sobre software cerrado y ánimo de lucro. Esto no impide que el software libre se preste para que realicen negocios en su entorno.

Software de dominio público

El software de dominio público (public domain software), es software libre que tiene como particularidad la ausencia de Copyright, es decir, es software libre sin derechos de autor. En este caso los autores renuncian a todos los derechos que les puedan corresponder.

Software semi-libre

Para la FSF el software semi-libre es software que posee las libertades del software libre pero sólo se puede usar para fines sin ánimo de lucro, por lo cual lo cataloga como software no libre.

Software freeware

El software freeware es software que se puede usar, copiar y distribuir libremente pero que no incluye archivos fuentes. Para la FSF el software freeware no es software libre, aunque tampoco lo califica como semi-libre ni propietario. El software freeware se asemeja más al software libre que al software propietario, porque no se debe pagar para adquirirlo o utilizarlo.

Síntesis de los tipos de software según su licencia

Los diferentes tipos de software según su licencia pueden agruparse de varias formas, por ejemplo, por la disponibilidad de los archivos fuentes o por el costo que representa para el usuario. También es posible agrupar el software según los fines que persigue, aunque en este caso el resultado no ayuda mucho porque lo que interesa es diferenciar el software propietario del software libre.

Administración de licencias de uso

Con relación a los costos licencias del ERP, el principal problema de las empresas usuarias es que no pueden distinguir con claridad y precisión entre lo que las licencias les permiten usar y lo que realmente utilizan. Esta dificultad surge debido a factores históricos, el cambio de las estructuras empresariales, muchos tipos de licencias del ERP y las interconexiones entre finanzas, informática, y legales.

La opción lógica para hacer rendir los presupuestos sin dejar de lado la calidad de su servicio o productos que reciben es innovar.

Cómo se usan las licencias del ERP

Un estudio reciente sobre el uso de licencias / gasto en un vendor de la industria, había demostrado que:

  • 95% de las organizaciones están pagando por algún usuario que no utilizan el sistema.
  • 90% de ellos no evalúan las necesidades exactas de autorización de sus usuarios y terminan dándoles autorizaciones superiores, aún cuando no hay necesidad de pagar derechos de licencias del ERP más elevados.
  • 60% de las organizaciones compran más licencias del ERP de lo que realmente necesitan.
  • 50% no sabe que la clasificación incorrecta de los usuarios se traducirá en mayores costos porque consideran sólo los usuarios profesionales.
  • 40% no son conscientes que compartir los ID da lugar a fuertes sanciones.
  • Al menos el 10% de las organizaciones sin saberlo cometer fraude mediante la supresión de los ID de usuario antes de que el audite.

Recomendaciones para un uso eficiente de licencias

A continuación se enumeran cinco recomendación que ayudan a las empresas minimizar sus gastos de licencias del ERP.

# 1 – Siempre “Clasificar” al usuario bajo un tipo de licencia

Teniendo en cuenta que las diferencias entre los distintos tipos de licencias del ERP que algunos vendors ofrecen no son claras, el administrador es quien está obligado a asignar el tipo apropiado para un usuario determinado sobre la base de una magra información.

Si el responsable no asigna una licencias del ERP para un usuario en particular, entonces el software puede llegar a designarlo, automáticamente, como usuario profesional. Las empresas terminan pagando enormes costos en estos usuarios no identificados. Por lo tanto, siempre es recomendable asignar la clasificación correcta cuando se crea el usuario.

# 2 – Comprobar periódicamente los usuarios inactivos

La identificación de los usuarios inactivos es una tarea crítica y podría ser un salvavidas en muchos casos. Es una práctica común para crear un ID de usuario en sistemas cuando ingresa un nuevo empleado. Sin embargo, muy pocas organizaciones revisan el uso de identificadores de usuario. Es una buena práctica identificar, revisar y tomar las medidas apropiadas sobre la disposición de los usuarios inactivos.

# 3 – No compartir los ID de los usuarios

Otra práctica común en muchas empresas es compartir la identificación de manera que un mismo ID de usuario se utiliza comúnmente por varios a la vez. Los administradores piensan que podrían ahorrar enormes costos al compartir los ID de usuario.

En realidad, esto tiene más riesgos que ventajas. Con identificadores comunes, los auditores pueden tener dificultades para conocer quien ha realizado una actividad específica. Incluso hay proveedores que penalizan los ID de usuario compartidos en gran medida. Si sigue esta práctica, asegúrese de crear un ID para cada usuario en el sistema.

# 4 – Asignar sólo el número correcto de autorizaciones

Hay algunas situaciones donde a los usuarios funcionales se les proporcionan acceso SYSTEM_ALL en el entorno de producción. Esto podría ahorrar los tiempos para dar autorizaciones, pero traerá aumentos exponenciales de costos de licencia debido a que esos derechos, en algunos casos, se otorgan con precios diferenciales. Además abre el camino a potenciales riesgos y al fraude financiero.

Siempre es aconsejable seguir el modelo “Principio de mínimos privilegios” al dar autorizaciones a un usuario en el sistema. Si el software tiene un diseño de autorización eficiente, es recomendable separar los procesos de negocio y las actividades que deban llevarse a cabo.

# 5 – Nunca borrar un ID de usuario

Es una práctica frecuente eliminar el ID de usuario cuando un empleado deja la organización. Sin embargo, siempre es mejor mantener ese ID en un modo inactivo mediante la eliminación de las autorizaciones, el bloqueo de la ID, y la limitación de su validez.

Hay productos de software ERP que no cuentan a estos ID en su auditoría, de manera que, al contabilizar, estará disponible la cantidad de licencias válidas y activas.

Por qué debe ser contratado el servicio de mantenimiento

Algunas de las razones por las cuáles debe contratarse el servicio son las que se detallan a continuación:

Nuevas versiones y actualizaciones (o cómo evitar la obsolescencia)

El producto ha de incluir mejoras continuas, bien a consideración del proveedor, bien a petición de los propios clientes, que con sus necesidades van requiriendo nuevas prestaciones al software. El producto se enriquece así enormemente, sobretodo si nos referimos a productos sectorizados donde las necesidades y requerimientos de todos los usuarios están alineados. Estas mejoras suelen ser en ocasiones bastante subjetivas, por lo que el software deberá permitir la parametrización. Dicho esto, se entiende que no es lo mismo hacer un desarrollo condicionado a un único cliente y con un coste reducido, que hacer el desarrollo tratando de parametrizarlo y adaptarlo para su uso intensivo por muchos clientes.

Cambios legislativos

Nuevos impuestos y cambios en las normativas y modelos oficiales, obliga al software a adaptarse para no quedar los clientes fuera de la legislación. Casos de las últimas nuevas leyes pueden ser acerca de cambios en facturación en materia de abonos, cambios plan general contable, cambios impositivos, etc.

Mercado cambiante

En un mercado tan convulso como el actual, las necesidades se multiplican y diversifican. Las empresas tienen que reinventarse en materia de productos, tarifas, logística, producción, etc. El software habrá de contemplar las nuevas condiciones si no queremos quedarnos fuera del mercado.

Formación adicional

Productos como los ERP requieren de una formación continua que suele considerarse no acabar nunca, dado que en la empresa cliente se produce bajas y altas de personal, y por tanto hay que formar a los nuevos usuarios si los que quedan no tienen la capacitación suficiente.

Capacitaciones de nuevos módulos

De las áreas no tratadas durante la fase de implantación, se requiere en un momento dado su puesta en marcha. Desde módulos relativamente generales como seguridad y auditoría, con la creación de perfiles y roles de usuario, menús personalizados, niveles de acceso, etc, hasta módulos más específicos: cargas en el muelle, control tareas en planta, gestión de incidencias y otros.

Incidencias / postventa

Es difícil que no se produzcan incidencias en el manejo diario del software. Estas incidencias pueden ser propias del software, las cuales lógicamente estará obligado el proveedor a subsanar, y otras ocasionadas por los usuarios debido a errores en la propia operativa diaria.

Casos de manipulación de datos errónea de forma consciente e intencionada hasta casos donde se saltan procesos y flujos de trabajo para lograr ciertos objetivos sin medir las consecuencias.

Con cierta periodicidad, más de la deseable, nos encontramos con datos incoherentes o inconsistentes que requieren de una labor de “forense de datos”. Gracias a la auditoría se trata de determinar y analizar cual es la fuente del error, en unos casos como decía del propio software y en otras por el mal uso de éste. En estos casos se requiere, no solo del mantenimiento correctivo que evite el error o mal uso futuro, sino de la realización de procesos que regeneren o den consistencia a los datos.

Chequeo y mantenimiento de la base de datos

Toda base de datos requiere de una administración, monitorización, desfragmentación, reindexación, etc. Éstas se vuelven pesadas e ineficaces con el paso del tiempo a pesar que inicialmente estuvieran perfectamente tuneadas. El cliente requerirá en más de una ocasión en todo el período de uso de su software de este tipo de mantenimiento.

Instalación y reinstalación servidores y puestos

Los cambios en el hardware, la incorporación de nuevos usuarios a la empresa, etc. requiere de la instalación y testeo del software en cada puesto.

Evolución y adaptación del software a nuevos sistemas operativos

En ocasiones una nueva versión del sistema operativo convierte una aplicación en no funcional, o en el mejor de los casos, menos funcional. Esto condiciona a una evolución “obligada” del software y sobre la que el proveedor no suele tener control.

Recuerdo el caso de un cliente extranjero en el que su proveedor informático le vendió un nuevo servidor y con un sistema operativo de reciente hornada. Recomendamos a nuestro cliente que nos diese unas semanas para montar un entorno de pruebas del nuevo sistema operativo en nuestras oficinas y corriésemos las aplicaciones durante unos días con el fin de “certificar” la nueva versión de sistema operativo, así es como solemos hacerlo la mayoría de veces. Las prisas no sé si de nuestro cliente o de su proveedor local no nos dieron esos días de gracia, por lo que la reinstalación fue un desastre, el sistema no respondía frente a ningún informe. No podían lanzar facturas, órdenes de fabricación ni nada que les permitiera continuar con el trabajo diario. Nuestra empresa tardó alrededor de dos semanas y dos personas con dedicación exclusiva para corregir el error, que no era del software evidentemente, sino del propio sistema operativo, pero nos obligaba a reprogramar librerías y procedimientos de base de datos para realizar ciertos procesos de forma alternativa.

A pesar de todo, seguirá habiendo clientes que se pregunten para qué y porqué un servicio de mantenimiento software. Tengo un cliente que cada vez que le llega la cuota anual nos llama para renegociarlo con la excusa de que no llama nunca. Y realmente lo que es llamar, lo hace en contadas ocasiones, pero la realidad es que 2-3 correos electrónicos semanales no se los quita nadie. Alguno de esos correos he tardado más de un día de trabajo en contestarlo, documentándole procesos con texto, imágenes y hojas de cálculo para que observase el resultado de las pruebas realizadas.

En cualquier caso, lo importante es que el cliente perciba el mantenimiento software no como un gasto más sin contraprestaciones, sino como un servicio por el cual el proveedor responde de forma adecuada y ágil a sus problemas. Y además, facilitándole el trabajo. Si el cliente percibe que tras un error (propio o del proveedor) requiere de un esfuerzo considerable para subsanarlo, percibirá que el apoyo del proveedor no existe. En ocasiones, una pequeña actuación de éste de algunas horas puede ahorrar al cliente un esfuerzo en trabajo y tiempo de días. El cliente percibirá esto como un servicio y no como una cuota periódica.

Aportes de la comunidad

Usar el mismo software que otras empresas del sector garantiza indirectamente conocer por dónde anda la competencia, permitiendo así no quedarse descolgado del resto.

Riesgos a considerar antes de cancelar el contrato de mantenimiento del ERP

Si bien las empresas usuarias tienen la libertad de cancelar el contrato de mantenimiento, antes de hacerlo deben evaluar los riesgos, impactos a corto plazo y los efectos a largo plazo de cancelación de contrato de mantenimiento del ERP. En este artículo se presentan algunos de esos riesgos.

Antes de cancelar el contrato de mantenimiento del ERP con el proveedor, evalúe cuál de las cuatro opciones de asistencia alternativas mejor se adapta a sus necesidades.

Además, prepararse para el mantenimiento post-contrato abordando factores como planes de contingencia, las obligaciones y limitaciones contractuales.

Riesgos de cancelar el contrato de mantenimiento

La empresa ya no recibirá nuevos parches del fabricante o revisiones.

Mientras que los parches y correcciones son necesarias para las nuevas versiones de software, los clientes dicen que, una vez que están en producción, las actualizaciones (distintas de las actualizaciones de seguridad) y correcciones o bien no se aplican o son de impacto mínimo. Deben evaluar si el negocio y la organización de TI estarán satisfechos con la funcionalidad y la plataforma técnica que está disponible actualmente, hasta que la empresa tome el siguiente paso en su plan de trabajo ERP.

La empresa ya no recibirá los parches de seguridad del proveedor.

Las actualizaciones de seguridad del ERP son un tema delicado. Cuando la empresa cancela contrato de mantenimiento del ERP, ya no tiene acceso a los parches de seguridad de software provistos por el proveedores. Si bien esto suena inquietante al principio, deben considerarse dos puntos.

En primer lugar, muchos de estos parches son para las brechas de seguridad que han estado en vigor durante algún tiempo y han tenido poco o ningún impacto en los clientes. En segundo lugar, la mayoría de las vulnerabilidades de seguridad en soluciones de software maduros se encuentran fuera de código de la aplicación principal del proveedor – en la capa de presentación, el portal u otra tecnología de conexión. Para compensar los problemas de seguridad, los desarrolladores externos que apoyan al proveedor ofrecen parches similares. Mientras que algunas empresas no serán capaces de absorber el riesgo de vulnerabilidades de seguridad, para muchos clientes de ERP que decidieron cancelar el contrato de mantenimiento del ERP, esto ha resultado ser un factor de riesgo bajo.

La empresa puede necesitar una nueva fuente de actualización de nómina, impuestos y cambios regulatorios.

Las empresas que reciben actualizaciones la nómina, impuestos y / o cambios regulatorios desde su proveedor de software se ven afectados. Una vez que el acuerdo de mantenimiento con el proveedor de ERP ha sido cancelado, la empresa ya no recibirá la nómina, impuestos y cambios normativos desde ese proveedor y tendrá que buscar otra fuente para contar con estas actualizaciones. Esta pérdida tiene que considerarse, ya que el tiempo necesario para obtener una nueva fuente de soporte puede ser importante en caso de cancelación del contrato de mantenimiento del ERP con su proveedor.

La empresa ya no tendrá el derecho de actualizar las nuevas versiones publicadas después que el mantenimiento ha sido cancelado.

Esto significa que la versión de software disponible en la actualidad, a partir del momento en que se cancela contrato de mantenimiento del ERP con su proveedor, es la última a la que tendrá acceso, independientemente de si se ha aplicado la anterior actualización. La empresa no tiene porqué haber actualizado a la versión más reciente, pero para no perder el acceso a ella, tendría que asegurarse de que ha descargado la versión anterior a la cancelación del contrato de mantenimiento del ERP con su proveedor.

Quien toma la decisión, debe evaluar si el resto de los ejecutivos y la empresa estarán satisfechos con la funcionalidad y la plataforma técnica que está disponible actualmente hasta que la compañía tome el siguiente paso en su plan de trabajo ERP.

Todos los otros servicios de apoyo serán cancelados.

Un cliente señaló que no se dieron cuenta lo mucho que su equipo de apoyo ERP interno utiliza notas técnicas del proveedor donde lee periódicamente la información detallada acerca de las funciones del software de uso poco frecuente. Los ejemplos incluyen procedimientos de fin de año, el archivado y el proceso de reorganización de tablas.

Haga una encuesta al equipo de apoyo y los usuarios finales que tienen acceso a los servicios de apoyo del proveedor para determinar con qué frecuencia y con qué fines se accede a los servicios de consulta. Conozca sus opciones antes de cancelar el contrato de mantenimiento del ERP con su proveedor, especialmente si hay una alta dependencia de estos servicios. Si bien hay terceros que suelen proporcionar acceso directo a un ingeniero con experiencia, que puede ser una opción atractiva para evitar buscar a través de notas técnicas, no siempre tienen el conocimiento habilitante (certificación) para darle el mismo nivel de soporte. Si los servicios de apoyo se utilizan poco, puede ser apropiado para cancelar contrato de mantenimiento del ERP con su proveedor.

Para las empresas que participan en una fusión o adquisición puede ser necesario ajustar el tiempo de cancelación de mantenimiento.

Cuando dos empresas se fusionan, la necesidad de soporte del proveedor puede aumentar mientras que se fusionan los componentes funcionales, técnicos y de datos de la solución ERP.

Alojamiento de la solución ERP (Hosting).

¿Qué sucede cuando el ERP está alojado en un centro de datos del proveedor del software?

Cuando la aplicación se encuentra alojada en el centro de datos del proveedor de software, y se contrató a un tercero para tareas de mantenimientos, para éste sería difícil tomar las actualizaciones de ese mismo proveedor y aplicarlas a su propio software. Además puede haber una obligación contractual del proveedor de software que exige, a cualquier cliente alojado en su centro de datos, estar actualizado en cuanto a las versiones.

Algunas empresas han cambiado el hosting a un servicio diferente con el fin de cancelar el contrato de mantenimiento del ERP con su proveedor y cambiar a un tercero para el apoyo técnico. A veces los acuerdos de hosting incluyen cláusulas que exigen al cliente estar al día con contrato de mantenimiento del ERP con su proveedor, pero esto se puede evitar si el cliente solicita al proveedor de alojamiento renunciar a la exigencia. Pero el cliente debe tener un acuerdo con el proveedor de alojamiento que le permita recibir apoyo de terceras partes para intervenir en las actualizaciones ante cambios normativos, impositivos y otro tipo de soporte técnico.
El cambio de proveedores de alojamiento podría causar demasiada agitación y ser muy costoso, por lo que los que deciden acerca del ERP debe sopesar cuidadosamente la decisión contra el valor y el ahorro derivado de la decisión de cancelar el contrato de mantenimiento al migrar a un tercero.

Su contrato de licencia de software puede contener cláusulas que restringen ciertos tipos de servicios de apoyo

Para mitigar este riesgo, debe examinar la documentación del proveedor de software y / acuerdos de servicio con su asesor legal para garantizar el cumplimiento de los requisitos de protección de propiedad intelectual. Asegúrese de que las cláusulas del contrato de software no interfieran con su derecho al libre soporte o la contratación de terceros certificados para servicios de apoyo. No cancele el contrato de mantenimiento de su proveedor de ERP hasta que se resuelvan las restricciones contractuales de software.

Licencias runtime.

Oracle E-Business Suite sólo se ejecuta en la base de datos de Oracle, y algunos de sus clientes utilizan versiones del runtime de la base de datos. SAP (antes de Hana) fue el distribuidor más grande del runtime de Oracle.
Cuando un cliente utiliza el runtime de una base de datos su acuerdo de mantenimiento de software ERP puede estar cubriendo el soporte del runtime. En esos casos la cancelación del contrato de mantenimiento de aplicaciones también cancela el soporte del runtime. Este es un factor de bajo riesgo cuando la mayoría de las necesidades de apoyo ERP de una empresa afectan a la aplicación o en su configuración.

El código fuente de base de datos es muy sólido, necesita muy poco apoyo directo. La mayoría de problemas de soporte de bases de datos son relativos a la interoperabilidad de aplicaciones, configuración, integridad de los datos y los ajustes del rendimiento.

Antes de cancelar el contrato de mantenimiento del ERP, evalúe cuál de opciones de soporte mejor se adapta a su situación y necesidades.

Garantía

Algunos vendors suelen incluir, en letra mayúsculas y con negritas, una aclaración similar a la que se escribe a continuación:

El licenciante no garantiza que el software esté libre de errores, que el software se ejecute eficientemente en todas las combinaciones de hardware y software que el licenciatario pueda seleccionar para su uso, ni que el software vaya a operar en forma ininterrumpida, ni que todos los errores del software puedan ser o serán corregidos. No se garantiza que el software vaya a operar en otras combinaciones que las especificadas en la documentación. Las versiones que no están comercialmente a disposición del público en general y los materiales relacionados con éstas se entregan en el estado en que se encuentran sin ningún tipo de garantía expresa o implícita.

La pregunta que se debe formular es ¿Desde qué momento comienza a regir la garantía del producto? Hay tres momentos claves en el desarrollo de un proyecto relacionados con la garantía:

  • La entrega de las licencias
  • La implementación del software. También llamada implantación.
  • La puesta en marcha del proyecto, conocida como entrada en producción o Go Live.

Una vez que el período de garantía termina, comienza a regir el servicio de mantenimiento amparado mediante el Fee Anual o cargo de servicio de soporte.

Desde el punto de vista de los entregables, un proyecto de software empresarial tiene dos componentes importantes:

  • La licencia del producto.
  • La consultoría de implementación.

Desde un punto de vista formal, la licencia es la cesión de derechos de uso bajo determinadas condiciones que se encuentran estipuladas en el contrato de licenciamiento. En este contrato intervienen dos partes: el licenciante, es quien otorga los derechos y el licenciatario, quien recibe esos derechos. Luego de cerrarse los aspectos formales del contrato de licenciamiento, el licenciante (el fabricante del producto, también llamado vendor) entrega al licenciatario (también llamado el cliente) un CD o un acceso a un sitio de Internet para descargar el software y proceder a su instalación, es decir, a descargar el software a un medio magnético (generalmente un disco) para que el cliente disponga del mismo.

Desde el punto de vista del material entregable, el vendor cumplió con su parte del contrato. De manera que el producto está disponible y a partir de ese momento comenzaría el período de garantía. La actividad de instalación tiene dos responsables: el vendor (que entrega el software) y el cliente que debe recibirlo (instalarlo).

El software ¿Está en condiciones de ser utilizado?

En algunos casos sí, en otros no tanto. Para que el software esté en condiciones de ser utilizado se necesita realizar un conjunto de actividades conocidas como implementación, también llamadas implantación. Estas actividades son una responsabilidad compartida entre el implementador y el cliente. El implementador puede ser el mismo fabricante del producto o un tercero certificado para realizar tal actividad.

La implementación puede incluir tareas tales como, pero sin limitar, parametrización, capacitación, definición de circuitos, pruebas funcionales, pruebas de volumen, ajustes en los formularios o reportes de salida. Incluso hay proyectos que requieren de programas llamados interfaces para vincular sistemas existentes que, poco a poco se irán desactivando, con el nuevo software.

Cuando más rápido se pueda implementar el software, mejor. No solo porque el cliente puede comenzar a obtener los beneficios por los cuáles tomó la decisión de licenciarlo, sino también porque más pronto puede ser probado el software y, en consecuencia, hacer valer la garantía que, dicho sea de paso, ya comenzó a regir desde el momento que se entregó la licencia o se instaló el producto.

Dado que la implantación tiene como responsables a ambas partes, debería haber un esfuerzo mancomunado para llevar adelante el proyecto. Los inconvenientes se presentan por el hecho de que trabajan equipos de personas de culturas diferentes.

El entregable de la implantación es el software en condiciones de ser puesto en marcha.

Por lo expuesto, la garantía no podría comenzar a regir desde el momento de la implementación. Se trata de dos contrataciones diferentes de naturaleza distinta. En un caso un producto terminado (el software), en el otro de un servicio que, incluso, puede ser dado por un proveedor diferente al fabricante del software.

Una vez que la implementación termina, el siguiente paso es la decisión de puesta en marcha. Esta es una responsabilidad exclusiva del cliente pues es quien debe decidir en qué momento se desactiva el sistema viejo y cuando comienza a funcionar el nuevo. Si se diera el caso que la garantía comenzará en el momento de puesta en marcha, los perjuicios para el proyecto serían mayúsculos. Cualquier atraso en la puesta en marcha colocaría al cliente en una situación de potencial conflicto con el fabricante del software.

Diferentes situaciones

Hay distintos hechos que justifican la validez de la garantía desde el momento de la entrega de la licencia. Algunas situaciones que se han dado en la práctica pueden confirmar esta práctica.

Software listo que no puede ser instalado

Un caso típico es la falta de hardware. El cliente no posee el equipamiento que el proveedor del software requirió. A veces por negligencia del cliente, otras porque se demora la entrega del hardware.

Software instalado que no se implementa

Suele pasar cuando el equipo de proyecto del cliente no está armado. Otra situación es que las personas claves están de vacaciones. En cualquiera de los dos casos, el proyecto no puede comenzar.

Software implementado que no entra en producción

Esto puede suceder porque el cliente cree que aún la organización no está preparada para el impacto que causará el nuevo software o por razones políticas (un cambio de gobierno, una modificación en la dirección de la empresa, etc.).

En los ejemplos mencionados, las demoras fueron producidas por causas no atribuibles al fabricante del producto o al implementador. De hecho el fabricante cumplió con su parte del trato: entregar la licencia del producto y el software en sí mismo.

Con este punto hemos querido marcar lo importante que es estar preparados para realizar el proyecto y el conocimiento que se debe tener sobre las implicaciones o consecuencias de ciertas acciones en la vida de un proyecto.

Servicio de soporte

Una parte importante de la inversión de una empresa en un sistema de software es el soporte de ERP (Planeación de Recursos Empresariales). Por lo general, las compañías de pequeñas a medianas no pueden darse el lujo de contar con soporte interno, pero es vital que el soporte no se pase por alto.

El soporte también es una parte importante del costo total de propiedad. Entonces, ¿qué preguntas debe hacer a un posible proveedor de ERP sobre el soporte para asegurarse de que reciba el mejor retorno de su inversión y obtenga servicios de asistencia puntuales para su empresa?

El soporte de ERP casi siempre es un tema que se omite cuando una compañía evalúa nuevos sistemas. Sin embargo, es muy importante asegurar que su compañía opere de manera continua, sin interrupciones causadas por “un problema”. El soporte le proporciona guía, asesoría y herramientas adicionales que le pueden ayudar a dirigir su empresa con mayor efectividad.

Más que una voz al otro lado de la línea

Las empresas más pequeñas en ocasiones buscan ahorrar en costos de soporte de ERP, lo que a la larga puede ser contraproducente si sus empleados tienen dudas todos los días o desean actualizar sus sistemas para aprovechar nuevas características y funciones. Además, no siempre obtienen todos los beneficios de una buena operación de soporte. No solo se trata de una línea telefónica para resolver problemas. Los expertos en soporte ofrecen guía y asesoría para hacer que el sistema opere con mayor eficiencia, mejorar los flujos de trabajo y definir reportes y otros procesos para optimizar el análisis de la empresa. Todo eso puede resultar de gran valor para las empresas de pequeñas a medianas que desean agilidad e impulso.

Todo departamento de soporte de ERP (Enterprise Resource Planning) debe ser capaz de brindar servicios completos de asistencia técnica y de aplicaciones que no solo abarquen el software de ERP, sino también el software de terceros, las bases de datos y las tecnologías compatibles.

Comparación basada en las mejores prácticas en soporte de ERP

Recomiendo a aquellos que están considerando adquirir un nuevo sistema de ERP que comparen minuciosamente los niveles de soporte que ofrecen los proveedores que hayan seleccionado. Sus servicios deben satisfacer las necesidades empresariales específicas de su empresa. Existen algunas mejores prácticas que los departamentos de soporte deben seguir —y si no lo hacen, piénselo bien antes de contratar sus servicios.

Si no está seguro sobre cuándo comienza el período de soporte de ERP, lo invitamos a leer “Garantía del Software”.
Realice las siguientes diez preguntas para formarse un criterio sobre el cual comparar los servicios en base a las mejores prácticas:

  • ¿Quién responde en el número telefónico del soporte? ¿Es una recepcionista que toma el mensaje, registra la llamada y la transfiere, o le responde directamente un analista experto en soporte
  • ¿Cuáles son las habilidades de los analistas de soporte? ¿Se capacitan conforme desempeñan su trabajo o participan en un proceso de capacitación interno antes de tomar las primeras llamadas? ¿Cuentan con títulos de otras empresas similares? ¿Reciben desarrollo profesional continuo para ayudarles a mejorar sus habilidades en software?
  • ¿Cómo motiva el proveedor a su personal de soporte? ¿Son motivados por la satisfacción del cliente o únicamente por métricas?
  • ¿Cómo mide el proveedor el éxito de su equipo de soporte? ¿Lo mide por el número de llamadas diarias, por la cantidad de llamadas que se resuelven en el primer contacto, por la satisfacción del cliente con el proceso —desde la primera llamada hasta la resolución del problema?
  • ¿Cuánto tiempo, en promedio, llevan trabajando los analistas de soporte con el proveedor? ¿Hay mucha rotación de analistas o cuentan con planes profesionales que aseguran que las habilidades y la experiencia permanezcan en la empresa?
  • ¿Cómo son los procesos de escalamiento? ¿Cómo funcionan? ¿Qué problemas pueden escalarse? ¿Cómo se abordarán los problemas escalados? ¿Quiénes participan en el proceso de escalamiento?
  • ¿Quién brinda el soporte, los empleados internos o el personal de soporte externo? ¿Quién contrata a los analistas de soporte, el proveedor o una empresa externa? ¿Qué experiencia tiene la compañía externa? ¿Con qué niveles de soporte cuentan? ¿Qué otros productos soporta su personal?
  • ¿Cuántos idiomas ofrece el equipo de soporte del proveedor? ¿Hablan todos los idiomas que usted necesita?
  • ¿Cómo se comunica con el soporte —por teléfono, por Internet, por correo electrónico, mediante conversaciones en línea? ¿El proveedor cuentan con un portal donde usted pueda consultar documentos sobre preguntas frecuentes o acceder a una base de conocimientos? ¿Puede utilizar el portal para revisar el estatus actual de las llamadas? ¿Existe un límite en cuanto a la cantidad de llamadas a soporte que puede realizar durante un periodo determinado?
  • ¿El proveedor realiza encuestas frecuentes sobre satisfacción para conocer la opinión de los clientes respecto a los niveles de servicio?

Tómese su tiempo

Para sacar el mayor provecho de su sistema de ERP (Enterprise Resource Planning) y obtener un buen retorno de la inversión, no solo tiene que contar con el software indicado, sino también tomar en cuenta los servicios y el soporte disponibles para el mismo. A menos que trabaje en sociedad con su proveedor y considere su inversión a largo plazo, corre el riesgo de no beneficiarse de un retorno máximo.

Si hace las preguntas correctas desde el principio podrá evitar errores costosos e impulsará la productividad de su software. Eso significa sentarse con sus proveedores y hablar sobre el soporte de ERP, no solo leer los materiales que le entreguen. Tómese su tiempo, investigue, hable con los clientes de sus proveedores—le aseguro que valdrá la pena—.

Actualización y versión

Una “actualización de software” o Update actualiza una versión principal (versión de referencia) del software, pero no la “mejora” a la siguiente versión principal (si existiera).

Las actualizaciones brindan correcciones que aumentan la estabilidad, la compatibilidad y la seguridad. Normalmente, una actualización de software se puede descargar gratuitamente, mientras que una nueva versión o upgrade de software, no.

Una nueva versión de software normalmente incrementa el número que va detrás del primer “punto” de un producto (por ejemplo, ERP Decade v10.7, ERP Milenium v10.6). En cambio, una actualización de software descargable normalmente incrementa el número que va después del segundo “punto” (por ejemplo, ERP Decade v10.7.4).

Tanto las actualizaciones como las versiones llevan un proceso de implementación.

Mantenimiento y actualización

El Mantenimiento de Software es un servicio de suscripción, mientras que la licencia de actualización no lo es, es un producto externo, de compra.

El Mantenimiento de Software se abona una vez al año y una vez pagado, el cliente estará cubierto por todas las actualizaciones que se publiquen, así como el poder disfrutar del servicio de apoyo prioritario vía email.

Algunos proveedores, ofrecen una Licencia de Actualización para quienes no están suscriptos al servicio de Mantenimiento. Pero no es una oferta estándar en el mercado.

La Licencia de Actualización es para los clientes que no se suscribieron al servicio de mantenimiento de software, pero quieren tener su Licencia con las últimas actualizaciones. El precio de la Licencia de Actualización depende la política comercial de cada proveedor.

Por ejemplo, un proveedor puede establecer que la Licencia de Actualización es del 50% del nuevo precio de la Licencia, mientras que para el servicio de Mantenimiento del Software, el precio es el 25% del precio de la Licencia para el primer año, del 20% para el segundo año y 10% para el tercero año.

Contenido de un SLA

Un acuerdo de nivel de servicio o Service Level Agreement, también conocido por las siglas SLA o SLA, es un contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio. El SLA es una herramienta que ayuda a ambas partes a llegar a un consenso en términos del nivel de calidad del servicio, en aspectos tales como tiempo de respuesta, disponibilidad horaria, documentación disponible, personal asignado al servicio, etc.

Las empresas pueden utilizar los SLA (Service Level Agreement) para asegurar el rendimiento y la disponibilidad.
Un Acuerdo de Nivel de Servicio contiene normalmente la siguiente información (el contenido real puede variar dependiendo del tipo de servicio):

1. Nombre del Servicio

2. Información de autorización (con fecha y lugar)

  • Gestor del Nivel de Servicio
  • Cliente

3. Duración del contrato

  • Fechas de comienzo y final
  • Reglas sobre la terminación del acuerdo

4. Descripción/ resultado deseado por cliente

  • Procesos/actividades de negocios de los clientes a los que apoya este servicio
  • Resultado deseado en términos de utilidad (por ej. “Personal de campo puede acceder a las aplicaciones xxx o yyy de la empresa sin limitaciones de lugar y hora”)
  • Resultado deseado en términos de garantía (por ej. “El acceso se facilitará en todo el mundo de manera segura y confiable”)

5. Criticalidad del servicio y de los activos

  • Identificación de activos esenciales para el negocio conectados con el servicio

A) Funciones Vitales para el Negocio (Vital Business Functions, VBF’s) apoyadas por el servicio
B) Otros activos críticos usados dentro del servicio (por ej. ciertos tipos de datos del negocio)

  • Estimación del impacto en el negocio causado por una pérdida de servicio o activos (en términos monetarios, o usando un esquema de clasificación)

6. Referencia a contratos adicionales que también se aplican (por ej. a un SLA Maestro, o en el caso de los UC’s, a contratos con importantes suministradores subcontratados)

7. Tiempo del servicio

  • Horario que estará disponible el servicio
  • Excepciones (por ej. fines de semana, días feriados)
  • Periodo de mantenimiento

8. Tipos y niveles de apoyo requeridos

  • Apoyo in situ

A) Área/ localizaciones
B) Tipos de usuarios
C) Aplicaciones y componentes de infraestructura a apoyar
D) Tiempos de reacción y resolución (según prioridades, definiciones de prioridades, por ej. para la clasificación de Incidentes)

  • Apoyo a distancia

A) Área/ localizaciones
B) Tipos de usuarios (grupos de usuarios con acceso al servicio)
C) Aplicaciones y componentes de infraestructura a apoyar
D) Tiempos de reacción y resolución (definición de las prioridades, según las mismas, por ej. para la clasificación de E) Incidentes)

9. Requisitos / metas de Nivel de Servicio

  • Metas de disponibilidad

A) Condiciones bajo las cuales se considera que el servicio no está disponible (por ej. si el servicio se ofrece en varios lugares)
B) Metas de disponibilidad (definición exacta de cómo se calcularán los niveles de disponibilidad acordados, basados en el tiempo de servicio e inactividad acordado)

C) Metas de confiabilidad (requeridas por algunos clientes, usualmente definidas como Tiempo Medio Entre
D) Fallos (MTBF) o Tiempo Medio Entre Incidentes de Servicio [MTBSI])
E) Metas de sustentabilidad (requeridas por algunos clientes, usualmente definidas como Tiempo Medio Para Restaurar el Servicio [MTRS])
F) Tiempos de inactividad para mantenimiento (cantidad de tiempos de inactividad permitidos, periodos de pre notificación)
G) Restricciones en el mantenimiento, por ej. ventanas permitidas para mantenimiento, restricciones de mantenimiento durante temporadas
H) Procedimientos para anunciar interrupciones al servicio (planificados/ sin planificar)
I) Requisitos referentes a los informes de disponibilidad

  • Metas de capacidad/ desempeño

A) Capacidad requerida (límite más bajo/ alto) para el servicio, por ej.: Números y tipos de transacciones, Números y B) tipos de usuarios, Ciclos del negocio (diario, semanal) y variaciones por temporadas
C) Tiempo de respuesta de aplicaciones
D) Requisitos de escalabilidad (suposiciones para el aumento a mediano y largo plazo en el volumen del trabajo y la utilización del servicio)
E) Requisitos referentes a los informes de capacidad y desempeño

  • Compromisos de Continuidad del Servicio (disponibilidad del servicio en caso de un desastre)

A) Tiempo en que un nivel de servicio definido debe ser restablecido
B) Tiempo en que los niveles normales de servicio deben ser restaurados

10. Estándares técnicos ordenados y la especificación de la interfaz del servicio técnico

11. Responsabilidades

  • Deberes del proveedor de servicios
  • Deberes del cliente (socio en el contrato para el servicio)
  • Responsabilidades de los usuarios del servicio (por ej. con respecto a la seguridad de TI)
  • Aspectos de la Seguridad de TI que se deben observar al usar el servicio (dado el caso, referencias a Políticas de Seguridad de TI relevantes)

12. Costos y precios

  • Costo de proveer el servicio
  • Reglas para penalidades/ reversiones

13. Historia de Cambios

14. Lista de anexos

Actividades relacionadas con la implementación de un ERP

Organización

Planificación del Proyecto

Durante esta fase en donde nos enfocamos en definir los equipos de trabajo y toda la logística del proyecto, las principales tareas a considerarse para el cumplimiento de la misma son:

  1. Ejecutar sesiones para definición de equipos de trabajo, así como también definir los días y horarios que serán asignados al proyecto.
  2. Definir Los roles y responsabilidades de cada una de las personas involucradas en el proyecto.
  3. Definir un primer alcance de la implementación.
  4. Validar los requerimientos de Hardware y Software para el correcto funcionamiento del Sistema
  5. Generar un ambiente de pruebas.
  6. Definir una planificación detallada del proceso de implementación sobre el cual se llevará el control de avance del proyecto.

Modelamiento

Entendimiento de Negocio

Definiremos a esta etapa como la más importante de la implementación considerando que es durante ésta en donde se entenderá el negocio de la empresa y es ahí donde recién se podrá definir un alcance real del proyecto.

Además es aquí en donde se podrá decidir cómo finalmente los procesos quedarán definidos en el nuevo sistema ERP. Para esto se debe cumplir con las siguientes tareas principales:

  1. Llevar a cabo sesiones de trabajo empresa/proveedor en las cuales se pueda entender el negocio de la empresa así como también todas las mejoras esperadas por la empresa o propuestas de mejora sugeridas por el implementador.
  2. Refinar el alcance y objetivos de la implementación, dejando en claro hasta dónde llegará el sistema, que podrá cubrir y que no, y en caso de ser necesario que posibles desarrollos e integraciones se deberán generar
  3. Realizar ajustes al plan de trabajo en caso de ser necesario.
  4. Modelar los procesos levantados ya como una solución dentro de la herramienta ERP. Es decir crear prototipos de solución y validarlos entre Empresa/Implementador.
  5. Documentar los modelos finales a implementarse así como las configuraciones y parametrizaciones generales que se dará al sistema
  6. Empezar con la depuración de información general requerida por el sistema como información de Clientes, Proveedores, Artículos, plan de cuentas, etc.

Siempre orientado a lo que se haya definido en los modelos de procesos.

Parametrización

Configuración y Desarrollo

Esta etapa estará orientada a la configuración como tal de la herramienta alineada a lo modelado en la etapa previa. Las tareas principales a cumplirse en esta etapa son:

  1. Configurar el sistema según lo acordado en los modelos de la etapa anterior.
  2. Migrar datos de información maestra y configuración como clientes, proveedores, plan de cuentas, etc. Esto no incluye información de saldos para la salida en vivo.
  3. Desarrollar un plan para ejecutar pruebas unitarias.
  4. Validar que no existan configuraciones pendientes.
  5. Desarrollar pruebas unitarias, es decir validar entre empresa/implementador que lo configurado en el sistema es lo acordado en las etapa previa de modelamiento.
  6. Realizar ajustes a la fase configurado posterior a la validación.
  7. La empresa deberá realizar la actualización de la documentación actual de sus procesos según los cambios que se hayan generado.
  8. Llevar a cabo pruebas de desarrollos e integraciones en caso de ser necesario.
  9. Definir un plan de capacitaciones a usuarios finales.
  10. Definir el esquema de migración de los saldos iniciales.

Preparación Final

Durante esta fase se deberá preparar todo previo a la salida en vivo, es decir tener listo el sistema así como también la infraestructura de tecnología y el personal que trabajará con la herramienta. Las principales tareas de esta etapa son:

  1. Llevar a cabo la capacitación de usuarios Finales.
  2. Llevar a cabo la capacitación técnica para el administrador del sistema.
  3. Realizar ajustes finales a la herramienta.
  4. Generar un plan de salida en vivo, considerando la carga de los saldos iniciales.
  5. Llevar a cabo pruebas integrales, estas permitirán medir el rendimiento del sistema, el nivel de preparación de los usuarios finales entre otros riesgos que puedan presentarse.
  6. Definir actividades para mitigar todo riesgo o pendiente que esté aún activo.
  7. Cargar saldos Iniciales y validarlos.
  8. Completar todas las actividades previo salida en vivo. Validar que no existan pendientes y que todo esté listo para arrancar con el sistema de producción.
  9. Definir un plan de soporte durante la salida en vivo.

Producción – Go Live

Esta etapa es aquella en la que el sistema entrará definitivamente en producción. Durante ésta las tareas que se deben cumplir son:

  1. Verificar y dar cumplimiento al Acuerdo de soporte definido en la etapa previa.
  2. Monitorear las transacciones ejecutadas en el sistema.
  3. Optimizar el desempeño en general del sistema.

Control de Proyecto

Como ya se había mencionado, más que ser una fase, es un grupo de tareas que deben cumplirse durante todas las etapas de la implementación con el fin de llevar a cabo un control de calidad en la implementación y así identificar y mitigar cualquier riesgo a tiempo.

También documentar cualquier cambio que pueda surgir con respecto al equipo, alcance o configuración de la herramienta. Las tareas recomendadas en esta fase son:

  • Control de proyecto definiendo lo siguiente:
  1. Actividades realizadas
  2. Actividades en curso
  3. Actividades con retraso
  • Análisis de Riesgos
  1. Análisis de nuevos riesgos
  2. Seguimiento de riesgos actuales
  • Control de acuerdos y pendientes
  • Control de cambios en el proyecto
  • Control y actualización de planificación del proyecto

Todas estas tareas se recomiendan ejecutarlas y monitorearlas con reuniones quincenales entre los líderes de proyecto tanto de la empresa cliente como de la empresa implementador.

Implementación de un ERP: Configurar o Customizar. El rol de los templates

Los sistemas ERP tienen que ser flexibles para satisfacer las necesidades de las empresas que los instalan. Es una verdad de perogrullo decir que no hay dos empresas que estén dirigidas exactamente iguales y por lo tanto sus ERP tampoco serán iguales. Lo cual está bien, pero ¿Es el software ERP propuesto lo suficientemente flexible? ¿Puede manejar todo lo que usted quiere que haga en la forma en que quiere hacerlo? Esa es una tarea difícil y, a veces la respuesta es “no”.

La necesidad de adaptar el ERP deja en manos del equipo de proyecto una elección básica entre:

a) Configurar el sistema en la mayor medida posible hasta que haga lo que usted necesita.
b) Desarrollar código de programación personalizado, escrito para tratar de que las cosas funcionen exactamente de la manera que usted desea.

La configuración es el equivalente de manipular interruptores y recoger los valores de listas de opciones predefinidas. Es el método básico para la implementación de un sistema. Es bien claro y definido, pero limitado en lo que le permitirá hacer. De hecho, se entrega software ERP pre configurado y sin embargo no está asegurada la gestión de procesos.

La personalización, también conocida como “customización”, por otro lado, consiste en escribir código de programa para integrarlo con el sistema ERP. Con el código personalizado se puede hacer casi cualquier cosa si se le diere a los programadores suficiente tiempo y dinero. Sin embargo, las implementaciones con mucho código personalizado tienen mala prensa. En efecto, su reputación está precedida por tre características:

  1. Se exeden del presupuesto.
  2. Nunca están listas a tiempo.
  3. No entregan toda la funcionalidad prometida

Existe un término medio: los templates o plantillas

Las plantillas, o templates, son rutinas pre-escritas que realizan diversas tareas y que simplifican la implementación de un sistema ERP. Son una forma rápida de poner a funcionar los requerimientos de la empresa. Debido a que la funcionalidad de las plantillas se ha hecho para empresas similares a la suya e, idealmente, probadas, son fácilmente conectables o ensamblables con los módulos del ERP, ofrecen muchos de los beneficios de la personalización sin el riesgo de incurrir en exceso de tiempo y presupuesto. Las plantillas ofrecen más opciones que la posibilidad de configurar un software.

Pero los templates tienen algunas limitaciones. Entiéndase bien: la probabilidad de implementar un sistema ERP completo sin al menos algún código personalizado son mínimas. Sin embargo, cuanto menor es el código que se tiene que escribir, más agradable será el proyecto. Recuerde que una implementación exitosa depende del alcance, tiempos, calidad, costos, riesgos, recursos humanos y comunicación.

Tal como sucede con la hoja de cálculo u otras aplicaciones, algunos templates están disponibles en forma gratuita. Otros tienen costos: desde unos pocos dólares hasta miles, dependiendo de su origen y de la complejidad de la plantilla. Los principales sistemas ERP tienen disponibles bibliotecas de templates. A veces son propiedad del proveedor del software y, a veces, son ofertas del ecosistema del vendedor, principalmente propiedad de algún partner especializado. En la mayoría de los casos no hay garantía de que las plantillas de un origen se acoplen bien a las demás, pero todas ellos deben trabajar con el software ERP para el que fueron diseñadas.

La calidad de las plantillas de un ERP varían, dependiendo del control de calidad practicado por el desarrollador. Algunas fueron hechas para un proyecto específico y lanzadas como un producto a último momento. Otras se desarrollaron cuidadosamente, con estándares del más alto nivel.

Tenga en cuenta que parte de estos templates no son fáciles de instalar. Es altamente probable que necesite la ayuda de consultores para configurar correctamente los que son complejos. Considere que el proveedor de ERP no podrá darle soporte si hay un problema con una plantilla hecha por un tercero. La mayoría de los vendedores ofrecen asistencia sobre templates que fueron provistos por ellos mismos, aunque es probable que no sea del mismo nivel que en el caso del producto.

En general, debe probar a fondo una plantilla antes de usarla. Preste especial atención a los límites de la plantilla. Por ejemplo, algunas están limitadas en la cantidad de usuarios que van a soportar simultáneamente. Otras pueden disminuir considerablemente la performance del sistema. Si va a comprar un template, no estaría mal contar un período de prueba para saber si va a trabajar de acuerdo a sus necesidades.

Los templates no son la solución ideal para resolver el dilema de personalización versus configuración, pero son una tercera opción que vale la pena examinar.

¿Qué Software es apto para su empresa?

Acceda a nuestros evaluadores

Share This