La clave de la reunión fue conocer de primera mano las novedades que ofrece la nueva versión 5.0 de su software de gestión empresarial Solmicro-eXpertis ERP, así como nuevas capacidades y módulos que impactan positivamente en la gestión del negocio de los clientes: CRM, Cuadros de mando, Sistema de Mensajería y Alarmas, TPV o Factura Electrónica…

Leer más: http://www.solmicro.com/fabricantes-software/noticias-informacion-erp/notas_de_prensa/version-erp-expertis-nueva

Roberto Andrés

Además nos encontramos con un problema humano importante. Los diseñadores de los sistemas de software se han formado habitualmente por experiencia desde puestos de desarrolladores, en ocasiones compartiendo ambas tareas hasta que en su progresión a diseñadores puros deben dedicarse por completo a esa faceta, no teniendo tiempo para programar. Nosotros hemos cambiado con el tiempo, pero invariablemente las herramientas de desarrollo y los sistemas sobre los que se implantan estos han cambiado también e incluso más rápidamente que nosotros. Por un lado habremos perdido de vista todos estos cambios tecnológicos a la vez que también la proximidad e incluso en ocasiones el respeto por aquellos que programan.

No vamos a ahondar en estas cuestiones, pero todos sabemos que están presentes y que crean tensiones dentro del equipo.

 Aun así, vamos a suponer que seremos capaces de manejar estas relaciones del equipo de trabajo (sin romperlo!), aún así tendremos el problema de los requerimientos cambiantes.

Lo más sorprendente de estos requerimientos cambiantes es que a día de hoy alguno de los miembros de casi cualquier equipo de desarrollo se sigue sorprendiendo de que surjan estos requerimientos cambiantes ya que todos sabemos que están ahí desde el comienzo de los tiempos. Hasta Dios diseño el mundo en 6 días y desde entonces no ha parado de detectarle errores y ponerle parches.

Poniéndonos de nuevo serios, estos cambios se producen por múltiples factores; una falta de comunicación o una comunicación incorrecta en el equipo de desarrollo, falta de entendimiento del problema o simplemente en la mayoría de los casos a un cambio de la lógica de negocio, cambio que se da más veces de lo prevista y a la que ninguna técnica de diseño puede anticiparse. Por otra parte, la existencia de cambios previsibles y nuestro deseo de anticiparnos a ellos, pueden devenir en mayores problemas que aquellos que queremos prevenir.

De esta manera se establecen los Métodos Ágiles como métodos orientados principalmente al equipo de trabajo y no al proceso en sí,  de manera que intentamos generar orden en el caos a la vez que no perdemos nuestro precioso y escaso tiempo en generar documentación excesiva y en ocasiones inútil.

A partir del año 2001 los miembros más destacados de este movimiento se reunieron y adoptaron el nombre de Metodologías Ágiles, a la vez que formaron la Alianza Ágil para promover estos tipos de desarrollos, creando un manifiesto y unos principios como base para la estandarización de estos tipos de diseño, que recogen la esencia de la Metodología:

Manifiesto por el Desarrollo de Software Ágil

Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación exhaustiva
• Colaboración del cliente sobre negociación de contrato
• Responder al cambio sobre seguir un plan

Esto es, mientras en los artículos de la derecha hay valor, valoramos más a los de la izquierda.

Los doce principios:

• Nuestra mayor prioridad es satisfacer al cliente con la liberación oportuna y continua de software valioso.
• Le damos la bienvenida a los requisitos cambiantes, aun ya avanzado el desarrollo. Los procesos ágiles utilizan el cambio para la ventaja competitiva del cliente.
• Liberar software funcionando frecuentemente, de un par de semanas a un par de meses, de preferencia en la escala de tiempo más corta.
• La gente de negocios y los desarrolladores deben trabajar juntos diariamente durante todo el proyecto.
• Construir proyectos con individuos motivados. Déles el ambiente y soporte necesario, y confíe en que harán su trabajo.
• La manera más efectiva de intercambiar información en el desarrollo es la conversación cara a cara.
• El software funcionando es la medida primaria de progreso.
• Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante indefinidamente.
• La atención continua a la excelencia técnica y al buen diseño mejoran la agilidad.
• La simplicidad –el arte de maximizar la cantidad de trabajo a no realizar– es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto organizados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, entonces ajusta su desarrollo acordemente.

En el próximo artículo profundizaremos en las principales características de las Metodologías Ágiles.

Mario Garcimartín

El título de este capítulo puede inducir a error. Que nadie piense que estoy preparando las normas de comportamiento de una ONG. Lo que pretendo, modestamente, es establecer pautas de conducta.

Los otros no son sólo los próximos: hijos y pareja, padres y hermanos, amigos y vecinos; pueden ser también rivales y competidores, colegas y jefes, clientes y proveedores. Estamos obligados a tratar con todos, y probablemente nuestra educación nos permita hacerlo dentro de estilos generalmente aceptados.

Pienso, que no hay soluciones exactas para mejorar nuestras relaciones personales, pero hay una premisa: “es imprescindible que nos preocupemos de los demás”.  La famosa frase “hola, que tal estás”, encubre siempre una obligatoria dosis de hipocresía, que tarde o temprano se delata a si misma. No debemos renunciar a las cortesías habituales, pero debemos exigirnos diariamente un mínimo de sinceridad cuando sentimos las desgracias de otros o nos alegramos del éxito ajeno. Hay que tomar conciencia de que nuestras felicitaciones y nuestros pésames no sean meramente protocolarios.

Una de las habilidades mas difíciles de encontrar (al menos para mí) es la “Empatía”.  Igual que otras muchas, forma parte de la propia personalidad. Se es o no empático de la misma forma que se es moreno o rubio, pero con voluntad puede y debe adquirirse y perfeccionarse. La empatía es la capacidad de ver los asuntos como los ve el otro, desde su posición y circunstancia. No es preciso asumir su punto de vista, pero si comprender por qué piensa así. En cualquier negociación, las personas empáticas tienen ventaja, han recorrido un largo camino antes de que la parte contraria haya terminado de defender sus posiciones.

Para perfeccionar nuestra empatía, (sea ésta mucha o poca)  debemos interesarnos por la persona que tenemos enfrente; conocer sus aficiones, entender sus necesidades y objetivos. Pongámonos realmente en el lugar del otro o intentémoslo, al menos, con “sinceridad”. Pienso, que con este gesto generoso, estaremos ocupando su terreno, jugando sus cartas, viendo el problema desde más ángulos. En definitiva, siendo más eficientes.

Quiero aquí hacer una observación, la empatía no debe confundirse con la “identificación”  ni, menos aún, con la “imitación”. Hay quien por hacerse perdonar el hecho de ser diferente, adopta sin darse cuenta gestos y entonaciones del interlocutor. De hecho, un par de veces durante mi vida profesional, he visto la metamorfosis realizada en la persona; adoptando las mismas posturas, voces y gestos. El empático no pierde su personalidad, simplemente entiende a la persona y valora el porqué de sus reacciones para poderle contestar adecuadamente.

Al interesarnos por los demás estamos procurando nuestro propio beneficio. No es altruismo lo que hace progresar al mundo; gracias al deseo de obtener un beneficio por parte del panadero y del lechero, gracias a su egoísmo, podemos contar todas las mañanas con leche y pan, a tiempo y en un lugar accesible.

En cualquier caso, cuidado con pretender ganarlo todo en la transacción, porque podemos quedarnos sin interlocutor. El “da y recibirás”, debería ser una norma permanente de las personas. Hay que dar algo a cambio, en toda transacción, y no solamente en las negociaciones mercantiles o políticas. La norma del “da y recibirás” es aplicable siempre, y muy especialmente cuando se trata de relaciones personales.

Es difícil obtener la distancia existente entre nuestras aspiraciones y lo que realmente podemos conseguir, y aún más entre lo que querríamos alcanzar y lo que, en justicia, debería alcanzar la parte contraria. Entran aquí en conflicto nuestra ambición y nuestra capacidad de empatía. Yo pienso que una buena táctica sería: “Conceder primero, plantarse, y esperar la contrapartida para dar una nueva concesión, o replegarme a una posición previa hasta que el contrario abandone la posición de fuerza”.

Al hablar anteriormente de la empatía, se me ha olvidado comentar algo que considero muy importante: “La ética profesional”. Interpretar las emociones ajenas sin ninguna referencia moral, sólo puede serle útil a un tahúr durante una partida de póquer.

Cuando al ver a una persona en una situación ridícula sentimos la desagradable sensación de la tan famosa  y tan malinterpretada “vergüenza ajena”, sólo estamos evidenciando que sentimos por el otro, que su dolor también es el nuestro. Nada de esto sería posible si no sintiéramos afecto por nuestros semejantes. Por consiguiente, pienso que es muy importante utilizar la ética desde la misma empatía.

Y ya para finalizar, me gustaría dar un último repaso a uno de los aspectos que conformarían (bajo mi punto de vista) el “todo para el interés hacia los otros”, junto con la empatía y la ética: la verdad. ¡ Señores !, “la mentira no paga”. Me viene a la mente la educación que recibían los jóvenes persas; eran ejercitados en tres artes: montar a caballo, disparar con el arco y ….. no mentir. La mentira y la traición, siempre son acompañadas por el desprecio. Si las personas con las que trabajamos son de nuestro interés, “la mentira no tiene objeto”, ni siquiera para bromear. Puede que, debido a determinadas circunstancias, nos veamos obligados a ocultar la verdad, pero nunca, nunca debemos mentir. Desde luego, para mí, prefiero negarme a contestar. No seamos como los políticos: que cuando son entrevistados, “dicen brillantemente  lo que están dispuestos a decir, con absoluta independencia del contenido e intención de la pregunta”.

Saludos

Roberto Andrés

Evidentemente y atendiendo a estos puntos de partida casi todos, sobre todo los programadores, se podrán ver interesados o atraídos por ciertas características de estos métodos. En este artículo no se pretenden exponer las virtudes, pros o contras de estas metodologías ágiles, ni tampoco justificar o explicar los posibles problemas encontrados a lo largo de la implantación de proyectos pasados o futuros, sino simplemente realizar una recopilación de la existente literatura al respecto de estos métodos menos conocidos, a la vez que desde mi doble punto de vista como diseñador y desarrollador, exponer alternativas a los métodos que se llevan usando desde hace ya más de 30 años. No nos engañemos, Ken Beck, uno de sus creadores y principales valedores lo puso en marcha para rescatar el proyecto C3 de Chrysler a finales de los 90 y este proyecto tuvo que ser finalmente cancelado, luego podemos casi asegurar que no se trata de la panacea que arregle todos nuestros problemas, pero evidentemente encontraremos algunos puntos que nos serán fácilmente identificables como útiles para su aplicación en nuestros proyectos.

Como ya comentábamos, estos métodos suponen principalmente un choque entre dos estilos; el diseño evolutivo/adaptativo y el diseño planeado/predictivo.

Esencialmente, evolutivo significa que el diseño del sistema crece conforme se implanta el sistema; el diseño es parte del proceso de programación y conforme el programa evoluciona el diseño cambia. Habitualmente esto se convertirá en un desastre; el diseño en estos casos se reduce a una serie de decisiones puntuales tomadas sobre la marcha que irán inevitablemente complicando la posibilidad de mantenimiento del código a medio y largo plazo. Conforme el diseño se deteriora, igualmente se deteriora la capacidad de cambio y con él se facilita la generación exponencial de errores que cada vez serán más difíciles (y costosos) de eliminar. Estas son principalmente las complicaciones del típico “codifica y corrige” al que en gran parte nos hemos acostumbrado los programadores. Los teóricos de la metodología denominan a este fenómeno como la Entropía del Software.

El diseño planeado al contrario, se basa en prácticas extraídas de la ingeniería. Si queremos construir por ejemplo un edificio, no podemos empezar a poner ladrillos a lo loco sino que realizaremos ciertos estudios, esquemas, códigos y diagramas utilizando diversas técnicas matemáticas y de estructuras, tras lo cual podremos abordar su construcción o encargársela a otra empresa para que lo construya.

En software todo debería funcionar de manera similar. Los diseñadores no pensamos en programar ya que solo lo estamos planeando, se piensa en los problemas con anticipación, y por ello utilizamos diferentes técnicas que dejan de lado los detalles de programación de bajo nivel para dedicarnos a un nivel más abstracto. Al igual que en el edificio estamos convencidos de poder diseñar un software a imagen y semejanza de una lógica de negocio y que podemos pasarlo después a los programadores o bien a otra compañía para que construya dicho software.

Así llevamos ya cerca de 30 años y aunque a priori parece mejor que el sistema de codificar y corregir, nuestra experiencia sabe que esto no siempre es así.

Sabemos que es totalmente imposible en un sistema de una complejidad media el haber pensado en todos los problemas que se necesitan tratar al programar y que aparecerán inevitablemente problemas que pondrán al diseño en entredicho, además no contaremos ni con un plazo suficientemente amplio para la realización del proyecto a la vez que tendremos unos márgenes comerciales más ajustados.

Normalmente en estos casos se realizará un cambio rápido en el diseño por la presión de tiempo a la que casi seguro estaremos sometidos, provocando con esto de nuevo el crecimiento de nuestra famosa Entropía, siendo en ocasiones obligados a lanzar el software incluso con un conjunto en teoría conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque el valor del software en un determinado nivel de calidad (teóricamente) compensa el impacto de los defectos y deficiencias conocidas.

Roberto Andrés

Las Metodologías de Diseño fueron creadas para imponer un proceso disciplinado en el de por sí caótico proceso de desarrollo de software con el fin de hacerlo más predecible y eficiente. De esta manera, a lo largo de los años se han venido diseñando métodos de diseño, en donde los últimos exponentes han sido UML, RUP, Métrica, etc,… 

Aún así y como ya sabemos, todas estas metodologías conllevan una ingente cantidad de pasos, etapas, documentación y ‘burocracia’ asociada, que retrasan considerablemente el proceso de desarrollo, siendo en ocasiones muy difícil de seguir escrupulosamente todos estos pasos consiguiendo en ocasiones su abandono o su seguimiento con laxitud a lo largo del proceso, siendo este mayor cuanto más crítico debería de ser su seguimiento. 

En este punto surgen los Métodos Ágiles, dentro de los cuales encontramos entre otros XP (Xtremme Programming) , SCRUM, Agile Unified Process y FDD (Feature Driven Development), intentando ser un punto medio entre las metodologías altamente burocratizadas y la ausencia total de método que nos podría abocar a un caos absoluto. Estas metodologías suponen grandes cambios  en los métodos habituales siendo alguno de los más controvertidos el rechazo a un esfuerzo significativo en el diseño previo, en favor de un estilo más evolutivo en el que sin disminuir la calidad si reduzcamos la documentación, pasos, procesos y tiempo de desarrollo necesarios para la consecución del proyecto. 

En próximas entregas analizaremos estas metodologías, como comienzo para su posible evaluación y su integración total o parcial dentro de la gestión de proyectos.

Mario Garcimartín

Durante toda mi carrera profesional y prácticamente en casi todas las empresas donde he desarrollado mi profesión, siempre he recibido, en mayor o menor grado, seminarios sobre el buen hacer profesional. Dan vueltas alrededor de los grandes conceptos y vuelven a aparecer con periodicidad matemática. Expongo algunos ejemplos: 

-         Dentro de cada individuo hay un potencial sin explotar.

-         Ante los problemas se debe tener una actitud positiva.

-         No dudes de la valía de otros porque su opinión difiera de la tuya.

-         Hay que jugar el juego que realmente nos interesa.

-         Para cambiar mi entorno, primero debo analizar mi comportamiento.

-         Etc.., etc….

Todos estos consejos, y otros cientos parecidos, figuran siempre en los seminarios y que suelo denominarlos afectuosamente “cursos doctrinales”. Tienen una gran virtud: ninguno es discutible, pero tienen tanta influencia práctica como el efecto placebo; no tienen contraindicaciones, pero raramente curan algo. Aunque cada día estoy más convencido de que el éxito es consecuencia del trabajo bien hecho, todas las recomendaciones que posteriormente enumeraré son un intento de aproximarme, desde distintas perspectivas, a la única verdad que una vez leí y guarde en mi memoria como un tesoro. Y que dice así: 

-         ¿Cómo puede uno conocerse a sí mismo?

-         Nunca por la contemplación: solo por el obrar.

-         ¿Pero cuál es mi deber?

-         Lo que pida el momento.

Después de horas pensando en fines de semana, he pergeñado una serie de normas, que creo de aconsejable seguimiento para todos aquellos que en alguna medida pretendemos alcanzar un alto rango en eficacia. La empatía y el interés por los que nos rodean, o por los que nos encontramos en el largo camino de la actividad profesional, la ética y la proximidad en el trato, son virtudes que siempre suelen terminar por tener su premio. Mantener siempre un elevado nivel de autoexigencia, de curiosidad por los avances, la búsqueda de la perfección sin despilfarros, el aprovechamiento óptimo del tiempo, la programación de objetivos alcanzables, la comunicación eficiente y la capacidad de innovar son factores importantes en la consecución del éxito.

Sin olvidar nuestra salud, nuestra apariencia y nuestros modales, porque como dijo una vez Quevedo es su “Buscón”: Te reciben como te presentas y te despiden como te comportas.

Y sin más dilación, a continuación expongo los principios que considero fundamentales para alcanzar un nivel óptimo de excelencia y que he dejado entrever en párrafos previos: 

-         Interesarse por los demás.

-         Cultivar la autoexigencia.

-         Controlar el entorno.

-         Marcarse objetivos.

-         Programar las acciones.

-         Comunicar con eficiencia

-         Trabajar en equipo.

-         Tomar decisiones.

-         Ser creativo.

-         Ocuparse de uno mismo.

 En días sucesivos intentaré desarrollar cada uno de los puntos expuestos.

 Saludos.

El EPM Forum es una cita obligada para los responsables de gestionar la información para la dirección, de planificar, de definir estrategias, así como los profesionales de TI que dan soporte a las funciones financieras.

Para recibir información detallada o inscribirte en este evento, puedes enviar un mail a Almudena.sanz@ios.es o llamar al 916587656 y quedarás registrado.

La inscripción es gratuita y el aforo limitado así que INSCRÍBETE YA!

Miguel Angel Hernández

En primer lugar, decir que el presente artículo ha sido redactado desde el punto de vista del mercado español y teniendo en cuenta el mercado de las soluciones ERP, foco principal de IOS. No se ha tenido en cuenta otros países, que pudieran tener otras características, ni tampoco el software libre, el cual se escapa de nuestro alcance.

Con el paso de los años, el mercado de las soluciones ERP ha sufrido notables cambios. Entre otros aspectos, hemos pasado de un escenario con dos estratos claramente diferenciables y que a continuación clasificamos, a otro escenario mucho más disperso y entremezclado. De forma muy general, los dos grandes bloques a los que hago referencia son:

• “Grandes” soluciones ERP para “grandes” empresas: Son soluciones generalistas que previa adaptación y “parametrización” tienen cabida en todos los sectores. Generalmente atienden a proyectos de gran alcance, alta componente tecnológica, altos plazos de implantación (más de 1 año). Provienen de grandes fabricantes como Oracle , SAP, Microsoft, etc.
• “Pequeñas” soluciones para “pequeñas” empresas: Soluciones de carácter mucho más específico, con funcionalidad más reducida, menos capacidad de adaptación, baja componente tecnológica y reducido tiempo de implantación (varios meses o incluso semanas). Para compensar sus carencias funcionales, presentan muchos procesos desarrollados exclusivamente para atender a la necesidad del cliente, convirtiéndolas en soluciones perfectamente verticalizadas. Normalmente son distribuidas por “pequeños” fabricantes de software, muchas veces nacionales.

La línea de separación entre estos dos grandes bloques siempre ha estado claramente diferenciada hasta el punto de que simplemente por el tamaño de la compañía ya estabas condicionado a una solución u otra. Atendiendo a dicho tamaño así como al de la solución, podemos establecer la siguiente clasificación y su relación con la solución ERP implantada:

Grandes Compañías, empresas con más de 250 empleados y un volumen de negocio superior a los 50 M€. Por lo general ya tienen implantada una “gran” solución.

Mediana empresa: Entre 20 y 250 empleados y con una facturación comprendida entre los 3 M€ y los 50M€. Por lo general, o bien tienen una gran solución muy adaptada (que no verticalizada) a sus necesidades, o bien tienen una solución de las “pequeñas” perfectamente verticalizada, de nueva adquisición o con la que llevan trabajando desde que eran una pequeña compañía, o bien, un desarrollo a medida con grandes limitaciones.

Pequeñas empresas: Menos de 20 empleados y facturación inferior a los 3 M€. Estas compañías por lo general, o bien tienen una solución de nicho totalmente sectorizada y limitada, o un desarrollo a medida, o no tienen solución ERP.

Nos centraremos principalmente en el caso de las Grandes compañías y el de las Medianas empresas, al ser en este entorno, donde se produce la mezcla de intereses.

Desde mi punto de vista, y dejando al margen el posible efecto de la situación económica, existen varios factores que han motivado el cambio de escenario, o quizás mejor decir, la mezcla o choque de escenarios:

• La notable disminución de grandes compañías o multinacionales demandantes de nuevos productos y/o soluciones ERP, ya que no sale una gran compañía todos los días, y las existentes ya poseen una gran solución ERP.
• Como consecuencia del punto anterior, los grandes fabricantes de software se han visto obligados a “mirar” hacia abajo en la pirámide empresarial y más concretamente en el caso español, al estar compuesto en su mayoría por Pymes.
• Las “pequeñas” soluciones que trabajando en el marco de la pequeña y mediana empresa, al ofrecer productos de reducida funcionalidad, comparado con las grandes soluciones, se han visto obligadas a desarrollar en sus proyectos, funcionalidades demandadas por sus clientes. Estas funcionalidades han hecho de estos “pequeños” productos, unos sistemas perfectamente adaptados a la problemática de sus clientes, es decir, se han verticalizado. Esta verticalización ha dado como resultado un notable aporte de valor añadido a sus soluciones, lo que les ha empujado a mirar hacia arriba en la pirámide empresarial.

¿Serán capaces los grandes fabricantes de software de adaptar completamente sus estrategias a este mercado intermedio? ¿Es la verticalización el camino para estas grandes soluciones? ¿Será rentable esta verticalización para el gran fabricante teniendo en cuenta el alto coste de licencias, expertis, complejidad tecnológica, etc? ¿pondrán estos fabricantes toda su experiencia en la realización de estos verticales o serán sus Partners los que tengan que asumir el reto? ¿Están las Pymes en situación de abordar proyectos de verticalización con grandes soluciones? ¿Podrán competir en precio con las experimentadas “pequeñas” soluciones ya verticalizadas? ¿Hasta que altura de la pirámide llegarán los pequeños fabricantes? ¿o hasta donde bajarán los grandes? ¿prefieren los clientes una solución que se les de una pronta y sencilla salida a sus problemas o invertirán en soluciones de más largo recorrido?

Todas estas cuestiones y muchas otras son motivos suficientes que nos llevarán a escribir otros artículos.

En este artículo he intentado dar mi opinión en unas pequeñas pinceladas sobre el mercado de ERP. Tan amplio y complejo es este sector que hasta el orden de los conceptos es difícil de conseguir. Espero de vuestros comentarios para entre todos ponerlos en consonancia.

Un saludo