• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Son sólo algunos ejemplos. Para aquél que tenga bien resuelto 3 de estos puntos en un sistema integrado mi más sincera enhorabuena. El que tenga más de 3 puntos organizados es un ejemplo a seguir en los tiempos que corren.

Como decía el otro día, en mi opinión esto es más fácil de lo que parece y debería suponer un esfuerzo en tiempo y costes muy controlado. Veamos el ejemplo más sencillo y más fácil de poner en marcha: Clientes y Contactos.

De forma conceptual, explicaré cómo proponemos la gestión de clientes y contactos. Obviamente hablo de un sistema integral, apoyado en una buena base de datos relacional y centralizada y con una serie de procesos que ayudan en la gestión de esta información. Pero ahora me limitaré a definir el modelo.

Naturalmente es imprescindible contar con una tabla de clientes a la que pueda acceder todo el personal de la empresa (no me meto en políticas de permisos aunque en Ender, todo el mundo puede acceder a esta información). Esta tabla va a estar relacionada con un buen montón de entidades del sistema (las que están marcadas con *) y debe tener algo parecido a esto (principio de un modelo de datos amplio aunque no excesivamente complejo):

Clientes

• 

  Ejemplo de modelado de datos

  Nombre

• Código postal
• Ciudad
• Comunidad Autónoma *
• Provincia *
• País *
• Teléfono
• Fax
• E-Mail
• Web
• Observaciones
• CIF
• Identificador interno
• Tipo de cliente *
• Tipo de negocio *
• Tipo de IVA por defecto *
• Forma de pago por defecto *
• Cuenta financiera por defecto *
• Datos de facturación por defecto
• Contacto principal
• Dirección
• Dirección facturas por defecto
• Att facturas
• Titular de cuenta domiciliación
• Entidad domicilación
• Oficina domiciliación
• DC Domiciliación
• Nº de cuenta domiciliación
• Acciones comerciales *
• Facturas previstas *
• Planes de facturación *
• Facturas *
• Proyectos *
• Ofertas a clientes *
• Cuentas contables *
• Contactos *
• [Datos de log: Usuario que creó el registro, último usuario que lo modificó, Fecha de Creación, Fecha de Actualización... Esto y una tabla de accesos afectará a todas las tablas del sistema]

Cada cliente podrá tener asociados uno o más contactos, una propuesta de modelización:

Contactos

Esta parte del modelo es de lo más sencillo pero se traduce, al menos, en lo siguiente:

• Todos los usuarios utilizan la misma agenda de clientes y contactos. Agenda centralizada e integrable con lo que haga falta (correo, mailing…) pero no ligada a nada externo.
• Información bien organizada. Si necesito algo de un cliente (consultar datos, facturas, ofertas, cobros, localizar un contacto…) parto de la ficha del cliente, ahí tiene que estar todo.
• Se acaba el tener que tener las cosas en carpetas del equipo local o carpetas compartidas. La información se soporta en una base de datos centralizada y está accesible para todos.
• Los privilegios deberían asegurar que sólo actualizan los datos personas autorizadas.

Es básico hacer algo así, no cuesta casi y se amortiza el pequeño esfuerzo en dos días.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Hace unos meses tuve una conversación muy interesante con un amigo, gran experto en arte y que anda metido desde hace años en temas de arte digital. Claro, a él, la programación le interesa principalmente como modo de expresión, y me estuvo contando iniciativas y cosas que hace la gente para experimentar… por ejemplo, la programación de virus como arte digital, o como experimentos de vida digital.

Este tipo de conversaciones son siempre interesantes, porque te ayudan a ver tu profesión con un poco de perspectiva, y creo que también te permiten descubrir por qué haces alguna de las cosas que haces. Me explico:

Interesándose por el tipo de empresa que somos, le explicaba que nuestra forma de ver Ender no ha sido nunca la de una empresa grande…nosotros nunca hemos tenido el objetivo de convertirnos en una gran consultora, sino más bien nos hemos visto siempre como un taller de software; nos encontramos más cerca de un despacho de arquitectura que de Microsoft o de SAP.

Nos preocupa más la mejora de nuestros procesos de desarrollo, la selección de las mejores tecnologías y el ser expertos en nuestro trabajo que utilizar las tecnologías más populares o crecer en facturación de forma rápida. Por eso creo que somos un negocio, no una empresa, para nosotros son más importantes las cosas que hacemos que el dinero que ganamos.

La visión de mi amigo de la programación (o la parte de la programación que le interesa, mejor dicho) se basa en la capacidad de experimentar y expresar, de utilizar el software como un lenguaje que te ayude a explicar lo que sientes o cómo ves el mundo; es decir, la programación como arte. Desde este punto de vista, el dinero no tiene importancia… no haces las cosas para ganar dinero, sino porque lo necesitas como medio de expresión.

El punto de vista empresarial es exactamente el contrario. No te interesa especialmente lo que haces, y tu preocupación por mejorar los procesos tiene como objetivo ser más productivo y generar más negocio. Es el punto de vista de las grandes consultoras, en las que el fin justifica en mayor o menor medida los medios que se utilizan… No importa la tecnología salvo desde el punto de vista de la productividad o de lo que el cliente considere ‘lo mejor’. Esto es lo que hace que los programadores de grandes empresas trabajen una gran cantidad de horas al día, y que a veces  la calidad de los desarrollos sea algo cuestionable.

En Ender buscamos un punto de vista intermedio… sabemos que tenemos que ganar dinero para vivir, y nos encantaría hacernos ricos, como a todos (creemos que, como lo que hacemos lo hacemos bien, en algún momento llegaremos). Sin embargo, nos preocupa más hacer bien el trabajo, o más bien estar satisfechos con el trabajo que hacemos, que el importe del proyecto en el que trabajamos.

A esta situación intermedia, en la que no renunciamos al interés económico, pero poniendo por delante  el trabajo que hacemos, lo llamo artesanía. No es la definición ortodoxa, ya que no hacemos las cosas con las manos ni somos un oficio tradicional, pero a falta de una palabra mejor, es la que utilizamos… no hacemos software por amor al arte ni por el amor al dinero: hacemos software por el amor al software.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Digo lo del miedo porque parece que a uno le dicen que necesita implantar un ERP para mejorar la gestión de su empresa y

• o no sabe lo que es y le asusta por desconocido;
• o piensa en un sistema enorme para  empresas enormes que tiene un coste enorme, casi siempre, de decenas de miles de euros.

Al final, ¿qué es un ERP? Las siglas significan Enterprise Resourse Planning, Planificación de Recursos Empresariales. Yo lo considero un conjunto de sub-sistemas de información muy relacionados entre ellos que permiten la gestión de las distintas áreas de la empresa (normalmente: producción, logística, gestión de stocks, facturación, costes, contabilidad…) y que se integran para compartir información. Toda la vida lo hemos llamado sistema de gestión, quizás así nos asustaba menos, pero el concepto ha cambiado un poco. Antes era complicado hablar de modularidad y ahora esto es una de las claves de estos sistemas: distintos módulos de gestión para distintos proceso pero con un núcleo centralizado en una base de datos común para todos.

Es muy importante un concepto: compartir información. En un sistema de información de este tipo cada departamento y cada usuario debe entender que la información que introduce en el sistema va a ser utilizada por otros usuarios de otros departamentos. Por este motivo es importante que la información esté correctamente imputada y a tiempo.

Considero que esto es lo que más debe preocuparnos a la hora de decidirnos por implantar un ERP, al margen de seleccionar al proveedor adecuado. Normalmente, poner en marcha el ERP de una empresa supone provocar cambios en las personas, en su forma de trabajar y en su forma de relacionarse con el resto de personal y los distintos departamentos. Es habitual que los departamentos o las áreas de las empresas se gestionen con sistemas independientes y sin ningún tipo de integración entre ellos. Cuando llega “alguien” o “algo”, el ERP, que cambia esta situación y que hace a las personas tener en cuenta que sus datos son compartidos y que pueden ser utilizados o consultados en cualquier momento pueden surgir ciertas resistencias. Además el usuario ha de abandonar sus procesos, sus herramientas (muchas veces construidas por él mismo) y cambiarlas por sistemas nuevos que, aunque se adapten, no van a ser nunca iguales a los anteriores. Esto, como digo, es lo que puede hacer que instalar un software de gestión empresarial integral se convierta en una hecatombe.

El mismo aspecto que puede hacer engorroso el arranque de un ERP es el que, realmente, marca la diferencia con otros modelos de gestión: base de datos centralizada, información compartida. Esto, en términos de gestión y, sobre todo, a la hora de obtener información es un avance muy importante. Obtener un informe de producción, o balances analíticos, seguimientos presupuestarios, datos de cash-flow e informes de este tipo se obtienen, o así debería ser, pulsando un botón e introduciendo algún parámetro. Sin un sistema de información de este tipo obtener este tipo de informes, normalmente, se convierte en una tarea bastante más complicada y no siempre muy segura.

En general, pasaremos de que hacer facturas en MS Excel (o en soluciones cerradas) a hacerlas en el sistema integrado, lo mismo con las ofertas y presupuestos, los pedidos, la gestión del cobro y otros muchos aspectos de la gestión diaria que pasan a un sistema unido y mucho más eficiente.

En definitiva, el único miedo debería estar en la posibilidad de descubrir que nuestro equipo no está bien cohesionado de raíz, por lo demás, un sistema de gestión no es más que eso, un sistema de gestión, lo importante son las personas que lo manejan. No debería asustar sino ayudar a hacer las cosas un poco mejor y a aprovechar mejor el tiempo.

Seguiré hablando del ERP: de los distintos módulos y peculiaridades; y de la forma en la que desde Ender conseguimos construirlos de forma natural, progresiva y con costes muy ajustados, como siempre, únicamente facturando las horas necesarias para adaptar, formar, implantar, migrar…

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

El ejercicio 2010, presenta nuevos retos a las organizaciones que han conseguido sobrevivir a la crisis iniciada en el ejercicio 2008.

Como dice el aforismo, “lo que no nos mata nos hace más fuerte” o traducido a la terminología DAFO “la estrategia de la empresa debe ir encaminada a convertir las amenazas en oportunidades y las debilidades en fortalezas”

Para acertar en su estrategia, las empresas que están inmersas en la crisis, han comenzado a apostar por el Cuadro de Mando Integral como un sistema de gestión adecuado a la consecución del objetivo prioritario actual: la supervivencia en un entorno macroeconómico complejo.

De las muchas definiciones que se han dado desde que los profesores D.P.Norton y R.S.Kaplan plantearon la filosofía gerencial Balanced Scorecard o CMI, reproducimos la que a nuestro juicio recoge todos los elementos fundamentales de esta estrategia de gestión empresarial:

“El Cuadro de Mando Integral es un modelo de gestión que traduce la estrategia de la compañía en objetivos interrelacionados, medidos a través de indicadores y ligados a unos planes de acción (iniciativas), que permiten alinear el comportamiento y acciones de todos los miembros de la organización.Además, permite tomar decisiones rápidas y acertadaspara alcanzar los objetivos fijados”

La metodología CMI engloba en cuatro perspectivas la totalidad de las variables que repercuten en la cuenta de resultados de la compañía:

• Perspectiva Financiera; ¿Qué hacer para satisfacer las expectativas de nuestros accionistas?
• Perspectiva Clientes: ¿Cómo satisfacer las necesidades de nuestros clientes?
• Perspectiva de Procesos Internos: ¿En qué procesos debemos ser excelentes para satisfacer esas necesidades?
• Perspectiva de Aprendizaje y Crecimiento, da respuesta a la pregunta ¿Cómo conseguir que la plantilla este alineada con estrategia definida por la Dirección y mejorar mi Organización?

Ender en colaboración con  Gramaudit, con el espíritu de tratar los problemas existentes aportando soluciones, ha desarrollado el Cuadro de Mando Integral personalizado para cada empresa, y presenta como solución a la crisis esta filosofía gerencial que optimiza la consecución de la estrategia definida por la Dirección.

Una vez más, se demuestra que la unión de dos equipos y conocimientos distintos se pueden traducir en buenos resultados.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Posicionamiento web

Hoy en día ya no es suficiente con tener una página web, ahora más que nunca, es vital mantenerse a la vanguardia en todo lo que a nuevas tecnologías se refiere, y esto, ya no pasa por tener un site web llamativo, ya no hace falta contratar al diseñador más creativo, hay que estar en Internet… Porque de qué sirve invertir todo ese dinero si nadie puede encontrarme .

Podemos tener una web espectacular, pero posicionarse en Internet no es algo que pueda comprarse… hay que ganárselo… ¿Y cómo?  Generando contenido que interese y permitiendo que los demás lo juzguen, lo amplíen y de paso, lo publiciten.

La Wikipedia es un muy buen ejemplo: Busca lo que quieras… un famoso, una película, una canción, una palabra……..  Apuesto a que en la mayoría de los casos, el artículo de “la wiki” estará entre las cinco primeras entradas.

En mi opinión, hay tres cosas que tienen que tener ya todas las empresas que quieran ser visibles, una web fácil de encontrar, WordPress es una herramienta para conseguirlo estupenda, un perfil en Facebook del que la gente pueda hacerse fan y siempre que el tipo de negocio lo permita, una cuenta de Twitter. Voy a centrarme en la primera, cómo convertir un blog en una web corporativa , ya que tocando las teclas necesarias, las otras dos quedan resueltas, porque lo mejor cuando te introduces en el desarrollo y la creación colectiva, es que casi siempre, alguien tuvo la idea antes que tú y resolvió la papeleta.

Creando una web corporativa con WordPress

Lo que más sorprende la primera vez que te pones a hacer un sitio web con esta herramienta, es lo fácil que resulta todo: Desde su página de inicio puedes descargarte un paquete que te permitirá siguiendo un sencillo asistente y cuatro instrucciones muy fáciles, montar tu blog en menos de cinco minutos. Cualquiera puede tener un blog, y se han esforzado en que así sea, si eso es lo que te interesa, ya lo tienes, puedes ponerte a publicar entradas en tu blog, es así de fácil, en serio, no necesitas nada más.

Pero a mí, lo que realmente me ha interesado estos días trabajando con WordPress para nuestros clientes, es lo extremedamente  sencillo que es reutilizarlo para crear una potencial herramienta de venta dándole una pequeña vuelta de tuerca:

Un tema atractivo (los temas dan el aspecto al sitio), un menú funcional, unos cuantos plugins (pequeñas herramientas que dan funcionalidad extra, por ejemplo, una galería de fotos) cambiamos cuatro comas en el código… et voilà!

Como he dicho antes, unir con nuestro perfil de Facebook o Twitter esta web es muy muy fácil utilizando los plugins oportunos, por tanto, si alimentas de contenido “tu blog” estarás automáticamente generando tweets y entradas en el muro de tu perfil.

La parte fácil está terminada, queda lo más tedioso, mantener la atención de tus visitas, conseguir que la gente se interese por tu web, y no sólo los que están buscando tus productos, sino todo el mundo, para ello, tienes que crear entradas con cierta frecuencia, y si tienes un negocio, seguro que tienes mucho que contar sobre él, nosotros hemos abierto las puertas de nuestra particular fábrica al mundo exterior, y no nos va nada mal…

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Últimamente en Ender nos estamos planteando la posibilidad de comenzar a desarrollar aplicaciones para dispositivos móviles relacionadas con nuestros sistemas. Cada vez los usuarios están más acostumbrados a migrar las funciones que tradicionalmente realizaba un ordenador hacia sus teléfonos, netbooks u otros dispositivos de menor capacidad de proceso. Y en el mundo empresarial, hacia el que nos orientamos, las extranets cada vez realizan un mayor número de funciones en sustitución del software ‘tradicional’. Es fácil ver que ambas tendencias se combinarán en el futuro, y si bien los terminales móviles de gama alta no deberían tener ningún problema en utilizar una extranet básica, siempre será mucho más eficiente utilizar una aplicación específica.

Por tanto, allá vamos, a explorar las posibles opciones. Desarrollar para dispositivos móviles no es como desarrollar para ordenadores. En los ordenadores, la opción es clara: IBM PC compatible con alguna de las distintas versiones de windows acumula el noventa y pico por ciento del mercado. Salvo que controles la infrastructura sobre la que va a correr la aplicación, no queda otra opción que programarla para windows, por pura estadística. En el mundo móvil el panorama es muy distinto… No hay, ni de lejos, un claro dominador del mercado de los sistemas operativos para móviles: Android (5% en 2009), Blackberry (21%), Windows Mobile (9%), iPhone OS (15%), Symbian (49%), Palm (>3%)… Además, los propios porcentajes son engañosos: Los mayores porcentajes los poseen sistemas operativos que llevan más (bastante más) tiempo en el mercado, y por tanto han tenido tiempo para que un mayor número de dispositivos de varias generaciones funcionen sobre ellos… lo que no significa que en el futuro sigan haciéndolo.

De hecho, tanto Symbian como Blackberry parecen sistemas destinados a morir. Cada día son menos los nuevos terminales que corren sobre estos SOs, siendo sustituidos por Android, Windows Phone (antiguo Mobile) o versiones nativas de linux. Por tanto no parecen una buena opción como elección, hoy por hoy.

Windows Phone está siendo adaptado como sistema por bastantes terminales, cuenta con la ventaja de tener una gran integración con los PC que corren sobre windows, pero no parece terminar de convencer a los usuarios. Sin duda, si hoy por hoy hay dos sistemas operativos para móviles estrella son Android y iPhone OS. Son con diferencia los más avanzados técnicamente, y ambos están “en pañales”, mostrando sólo el comienzo de su potencial, por lo que todo el mundo apuesta por uno o por otro para convertirse en el “Windows” de los teléfonos móbiles.

Android es hijo de Google. Es un sistema operativo libre y abierto, que permite que cualquier fabricante lo incluya en su dispositivo. Así, no sólo existen en el mercado teléfonos móviles que lo lleven, también hay toda una gama de otros dispositivos (tablets, netbooks, etc) que funcionan sobre él.

Iphone OS, a su vez, es propiedad de Apple y es el sistema sobre el que corren tanto los iphone como los nuevos ipods. Ningún otro fabricante puede utilizarlo, pero el golpe que apple dio al mercado de los smart phones con el iphone (acaparando un buen porcentaje del mercado en muy poco tiempo), y el hecho de que el dispositivo estrella de apple (iPod, lider indiscutible de otro mercado casi tan grande como el de los terminales móviles) también lo emplee hacen que sea una opción muy atractiva para los desarrolladores de aplicaciones.

En resumen: Se trata de elegir desarrollar para iPhone o para Android. Y no se trata sólo de elegir la opción que te lleve a un mayor número de clientes, o la que tenga mejor perspectiva de futuro. Como vamos a ver, el problema es mucho más profundo.

Mucha gente no conoce como funciona el proceso de desarrollo de una aplicación, así que vamos a explicar un par de conceptos claves. Para desarollar software existe una gran variedad de lenguajes… El “lenguaje” original de los procesadores de los ordenadores, como casi todo el mundo sabe, es un lenguaje binario. Largas cadenas de ceros y unos que hacen que el procesador haga una cosa u haga otra. Obviamente, “hablarle” directamente al procesador es casi imposible por lo extremadamente complejo, para eso existen los lenguajes de programación. Los lenguajes son abstracciones de este lenguaje binario. Es decir, si quieres que el ordenador imprima en la pantalla “hola mundo” no es necesario que te aprendas cómo ordenárselo en binario, sino que según el lenguaje que escojas escribiras algo parecido a write(‘hola mundo’) o print(‘hola mundo’). A partir de ahí, ese lenguaje se traducirá automáticamente al lenguaje del procesador para que el ordenador entienda lo que quieres que haga.

La cuestión es que hay cientos, miles de lenguajes. Muchos son similares, todos hacen más o menos lo mismo, pero sigue habiendo cientos. Algunos son más apropiados para unas tareas y otros para otras, pero al final, casi cualquier cosa se puede hacer con cualquier lenguaje y es sólo una opción personal. A su vez, cada lenguaje tiene un gran número de “librerias”. Las librerías son packs de código que te permiten realizar alguna acción complicada sin tener que programarla una y otra vez. Por ejemplo, para calcular una raiz cuadrada no haremos todos los pasos que serían necesarios cuando la resolvemos “a mano”: Le indicaremos al ordenador que vamos a usar la librería “matemáticas.lib” y con ella podremos simplemente usar la llamada “raizcuadrada(25)”. Es un concepto un poco extraño para alguien que no ha programado nunca, pero en realidad es la base de la programación profesional. Un programa normalmente usa un número bastante grande de estos componentes, conteniendo al final tanto o más código importado y ensamblado  como código propio y original.

¿Por qué explicar todo este rollo? Porque sino no es fácil explicar por qué la opción de desarrollar para iPhone es tan mala. La razón: La licencia de desarrollo de Apple. Apple tiene una concepción de sus productos que intenta dejarlo todo atado y bien atado. Pretenden controlar todo, desde la fabricación de los componentes hasta el software que corre en ellos. Y lo han llevado un paso más allá con el desarrollo para iphone. En desarrollo de software no es habitual tener que pagar una licencia para desarrollar programas para una plataforma. Pagar por poder usar ciertos programas o componentes sí, pero no por “el derecho” de desarrollar software. Pero Apple, en su intento por controlar qué se desarrolla y que no para sus sistemas, la ha introducido. Cien dólares de licencia anual para ser un desarrollador certificado por Apple. Sin esta certificación, tus programas no estarán en la tienda iphone, y por tanto no podrán funcionar en ningún teléfono ni ipod (Ya que no se puede instalar software en estos dispositivos de ninguna otra manera). La licencia no es costosa, pero tiene problemas mucho más profundos que el dinero: Apple se reserva el derecho de echar por tierra todo tu trabajo. Puedes  desarrollar una aplicación y que al final Apple decida no aprobarla, tirando abajo meses de trabajo. Y lo que es aún peor, se reservan el derecho de cambiar las condiciones que rigen qué es aceptable o qué no. En su última revisión de la licencia incluyeron una nueva cláusula que restringe los lenguajes en los que se puede programar a los tres o cuatro elegidos por ellos, y prohibe, directamente, el uso de librerías externas que no hayan proporcionado ellos mismos. En el mundo de la programación, esto es como decirle a un mecánico que no puede utilizar ninguna herramienta, excepto un destornillador de un modelo y tamaño específicos, para hacer cualquier cosa.

Android, por el contrario, es un sistema operativo libre. Su código fuente está disponible para cualquiera que quiera verlo. Cualquiera puede desarrollar aplicaciones sin tener que pagar nada, sin que nadie pueda decirte que no, sin que nadie tire por tierra tu trabajo. No hay prohibiciones en Android. En ese sentido, es muy parecido a lo que ocurre en el mundo del PC: Cualquiera puede hacer cualquier cosa, de la manera quiera hacerla. Las opciones son infinitas. Todo esto se ve claramente en el hecho de que el número de aplicaciones disponibles para android crece exponencialmente, y que cada vez más fabricantes de terminales lo ofrecen como base de sus dispositivos.

Durante todo el año pasado, el crecimiento del iPhone parecía imparable. Su tecnología era mucho más avanzada que la de los sistemas operativos rivales y el usuario lo notaba y elegía. El lanzamiento de Android y su generalización en los últimos meses parece enfrentarse directamente a esta tendencia. Android rivaliza (o supera) al iPhone OS en tecnología, y los teléfonos que lo incluyen suelen ser de una gama tan alta como el iphone.

La diferencia, para nosotros, es que Apple, en su intento por controlarlo todo, ahoga a los desarrolladores. Las condiciones que impone son draconianas, prácticamente nunca vistas en el mundo del desarrollo del software. No tienes derechos sobre tu propio producto, te limita las herramientas que puedes utilizar para desarrollarlo, te arriesgas a que sus propias condiciones cambien unilateralmente. Y esto no son condiciones en las que queramos desarrollar.

Android, para nosotros, es el futuro.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En mi último artículo hacía una introducción al proceso de modelado de una base de datos relacional, utilizando como ejemplo el proceso de matriculación de un centro de enseñanza. Siguiendo con esa línea, en este artículo voy a describir cómo hacemos el modelo de datos en Bravo, uno de nuestros sistemas, en este caso uno especializado en centros de enseñanzas de idiomas. Para una introducción más teórica, podéis echar un vistazo al artículo de la wikipedia.

Caso de uso

Como en el artículo anterior, lo primero es hacer la descripción de un caso de uso que nos meta en materia, y nos ayude a entender cuál es la funcionalidad que tenemos que proporcionar (o, en este caso, una descripción de los procesos que tenemos que modelizar). Bueno, en realidad la descripción que hago es más parecida a una historia de usuario de eXtreme Programming que al caso de uso típico de UML, pero nos entendemos…

Si en el artículo anterior el actor principial del caso de uso es un alumno que acude a la escuela, en este caso es el responsable formativo o Director of studies (aquí hay una buena descripción del puesto). Es la persona, en un centro de formación, encargada de la elaboración de los horarios, la gestión de las incidencias (que ahora veremos) y la asignación de profesores y aulas a los grupos que se formen.

Su necesidad es la de tener controlados todos los horarios del centro de formación. Es decir, tiene que poder saber dónde está cada profesor en todo momento, qué clases no se han impartido y por qué y saber qué profesores hay disponibles y qué aulas están libres en un momento determinado.

También necesita saber cuántas horas ha trabajado cada profesor en un mes y cuántas horas un profesor tenía que haber trabajado, y el motivo de las cancelaciones.

Así, el director de estudios (DOS, de aquí en adelante) recibe la petición de formar un grupo nuevo para uno de los cursos definidos en el ejemplo anterior, porque se han matriculado muchos alumnos y no hay plazas suficientes. El DOS entonces primero decide el horario que tendrá el grupo. En el caso de este ejemplo, el curso para el que hay que crear el grupo define 3 horas por semana (es lo que se llama un curso extensivo), que se impartirán Lunes, Miércoles y Viernes de 19:00 a 20:00. Con esta información definida, el DOS necesita buscar un profesor que esté disponible en ese horario, y un aula que también lo esté. Una vez localizada toda la información necesaria para montar el horario, hay dejar anotado el nombre de los alumnos que asistirán a este grupo.

Con toda esta información definida, el grupo puede empezar. Normalmente, se le proporciona al profesor a principio de mes una hoja de asistencia, que es un informe en el que se detallan el horario de cada grupo con sus alumnos, para que el profesor pueda hacer un seguimiento de la asistencia de los alumnos y de las incidencias que puedan aparecer.

Una vez el grupo ha comenzado, y los alumnos están asistiendo a clase, al director de estudios se le pueden presentar varias situaciones que tiene que manejar:

1. El grupo cambia de profesor, de horario o de aula. Quizá porque el profesor se vaya de la empresa o por la razón que sea, de vez en cuando hay que cambiar el profesor de un grupo. Sin embargo, a la hora de aplicar este cambio es importante tener en cuenta que debemos mantener la información histórica. Es decir, cuando haya un cambio de horario debemos saber qué profesor había antes y cuál hay ahora, y cuándo se produjo el cambio. Para el cálculo de total de horas trabajadas, es imprescindible.
2. Entran alumnos nuevos, u otros dejan el grupo, cuando los alumnos se dan de alta y se incorporan al grupo, o quizá cuando un alumno cambia de grupo porque el horario le viene mejor. Como en el caso anterior, tendríamos que saber por qué grupos ha pasado el alumnos y cuándo se ha incorporado a cada grupo.
3. Una clase no se imparte, por ejemplo porque el profesor se ha puesto enfermo y no se ha encontrado sustituto a tiempo, o porque el centro estaba cerrado. En este caso, tenemos que saberlo, porque el nº de horas trabajadas por el profesor tendrá que cambiar, y hay algunos casos (cuando se ha contratado un nº de horas de formación concreto) en los que esa clase debe recuperarse en otro momento, ya sea otro día de la semana o quizá alargando la duración del grupo un poco.
4. Un profesor sustituye a otro. Es el caso en el que un profesor se pone enfermo, o se ha cogido un día libre, y otro profesor le sustituye. En este caso tenemos que saber quién tenía que dar la clase (ha impartido una hora menos) y quién ha dado la clase en realidad (hay impartido una hora más).
5. Un grupo se cierra. Se dan de baja todos los alumnos o (lo que es más común), se dan de baja tantos alumnos que no compensa mantener el grupo abierto, así que se reúnen dos grupos con pocos alumnos y se crea un grupo con un nº de alumnos más acorde con las necesidades tanto del centro como de los propios alumnos.

Descripción de las entidades

Después de la descripción del proceso, detallo las entidades (tablas) que utilizamos para m0delizarlo:

• Cursos: podéis ver la descripción en el artículo anterior.
• Profesores: el personal que imparte las clases.
• Grupos: La oferta de horarios y días entre los que los alumnos pueden elegir para asistir a clase, dentro de cada curso.
• Horarios: Dentro de cada grupo, tenemos que almacenar su horario (que puede tener una estructura compleja, por ejemplo: Lunes y Miércoles de 19:00 a 20:00 y Viernes de 13:00 a 14:00, es más común de lo que parece). Además, hay que almacenar el historial de horarios por los que ha pasado el grupo, incluyendo los profesores.
• Clases: Cada uno de los días de clase dentro del horario del grupo. Por ejemplo, si tenemos un horario Lunes de 19:00 a 20:00, entre el 1 y el 30 de Abril, tendrá que haber un registro para cada Lunes entre esas dos fechas, para que después podamos gestionar si las clases se han impartido o no, cada una por separado.
• Tipos de tarea: Hay situaciones en las que es conveniente diferenciar qué se hace en los horarios del grupo. Podemos tener grupos de formación, como los que se describen en todo el artículo, pero también podemos tener grupos que gestionen las tareas administrativas de los profesores (preparación de clases, etc.) o incluso la agenda del personal no docente, simplemente diferenciando por tipo de tarea.
• Tipos de cancelación: Necesitamos saber cuando una clase no se imparte, así que nos hará falta una gestión de motivos de cancelación, y por tanto una entidad que los defina.
• Alumnos: ya la vimos en el artículo anterior.
• Alumnos en grupos: Tenemos que almacenar la información de qué alumnos están apuntados a qué grupos y, además, nos hace falta saber, según el caso de uso, cuándo entró y cuándo salió cada alumno de su grupo.
• Asistencia: Para cada una de las clases, tenemos que saber qué alumnos estaban apuntados a ella, y para cada uno de ellos, si asistió a clase o no.

Gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla.

Campos

Como siempre, sólo pongo los campos que considero más relevantes para la descripción del modelo de datos, y no repito los campos de clave ajena para las relaciones, que ya están descritos en el gráfico. La definición de cursos y grupos es la misma que en la que hay en el artículo de matriculación:

Cursos

• nombre: varchar(100)
• descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
• fecha_inicio: date
• fecha_fin: date

Profesores

• nombre, primer_apellido, segundo_apellido: varchar(100)
• nombre_completo: es una costumbre crear un campo calculado que almacene el nombre completo del profesor. Así, las búsquedas se hacen sobre este campo y es más fácil encontrar al profesor en cuestión.
• dirección: Memo
• telefono, telefono_movil: varchar(50). No os quedéis cortos con el tamaño de los campos, más vale pasarse que dejarlo con 9 dígitos y descubrir que tienes que poner el +34 delante para poder mandar SMS después.
• NIF_NIE, Pasaporte: en campos separados

Grupos

• nombre: varchar(100)
• codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
• fecha_inicio: date
• fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
• lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo.
• notas: memo, del grupo
• horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
• maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
• numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Horarios

• fecha_inicio, fechafin : date. Por defecto, serán las del grupo con el que estamos trabajando, pero si cambiamos de horario a mitad del grupo, habrá que cerrar el horario anterior (cambiar fecha_fin) y crear un horario nuevo.
• L,M,X,J,V: Boolean. Aquí hay dos formas de hacerlo… puedes poner campos booleanos para cada día de la semana, y si el horario tiene L = sí y X = sí, entonces el horario es Lunes y Miércoles, o poner un campo “día” de tipo entero y tener un registro de horario para cada día de la semana. Me inclino por la primera solución, que hemos utilizado en nuestro sistema Atenea que por la segunda, que es la que utilizamos en Bravo. Los días de la semana no son algo que vaya a cambiar, y el interface y la forma de mostrar el horario es más fácil de implementar y más intuitivo para el usuario cuando usas una sóla fila que cuando tienes 3 para el mismo horario.
• hora_inicio, hora_fin: Time
• id_profesor: por defecto, es el profesor definido como profesor del grupo, pero podemos tener la situación en la que haya dos profesores en el mismo grupo (como pasa muy a menudo con los seminarios y los cursos intensivos).
• id_tipo_tarea: Integer. Es el tipo de tarea por defecto que tendrán todas las clases del horario. También existe la posibilidad de poner un tipo de cancelación por defecto, como hemos hecho en Atenea. Lo vemos más abajo, en las clases.

Clases

• fecha: Date. A estas alturas, ya no tenemos fecha de inicio y fecha de fin… esto es ya cada uno de los días de clase individuales, y por tanto lo que hay es una fecha
• hora_inicio, hora_fin: Time. Por defecto serán las del horario al que pertenece la clase. Están también en la tabla de clases porque eso te permite gestionar excepciones, del tipo que la clase de hoy dura media hora más para recuperar parte de una clase anterior que se canceló, cosas así.
• id_tipo_tarea: el tipo de tarea del horario, por defecto. Igual que antes, está replicado en esta tabla para permitir excepciones.
• id_tipo_cancelacion: Tenemos dos formas de proceder… podemos definir un tipo de cancelación por defecto, que será el que tengan todas las clases (nosotros utilizamos “clase impartida”, para indicar que no ha habido cancelación), o también podemos poner el tipo de cancelación en el horario, de forma que todas las clases de ese horario tendrán ese tipo de cancelación y luego nosotros cambiamos el tipo de cancelación para las clases que no se imparten.
• Notas pedagógicas: Memo. Suele ser buena idea poner un campo de notas pedagógicas que, el profesor, al rellenar la asistencia (lo vemos más abajo) puede completar. Esto hace que, cuando un profesor tiene que hacerse cargo de un grupo que ya ha empezado, puede leer las notas que dejó el otro profesor (lo que se llama el Class Record) y saber por dónde van y qué es lo siguiente que hay que hacer.

Tipos de Tarea

• nombre: varchar(100)
• lectiva, transporte, administrativa : boolean. Con estos campos podemos sumar después fácilmente las horas según los tipos de tarea. Por ejemplo, podemos tener un tipo de tarea “Horas lectivas” y otra “Horas lectivas en Sábado”, que se pagan de distinta forma y queremos tener controladas, pero sin embargo todas son horas lectivas, y a la hora calcular totales de horas, las queremos agrupadas.

Tipos de cancelación

• Nombre : varchar(100)
• clase_impartida: boolean. Así podemos tener distintos tipos de cancelación que indican que la clase no se ha impartido, y luego sumar todas juntas para saber cuántas horas se han impartido y cuántas no.
• implica_pago_profesor: Según el tipo de cancelación y el convenio, hay tipos de cancelación que, aunque no cuenten como clase impartida, sí que se van a pagar al profesor.
• implica_cobo_cliente: En el caso de los grupos para empresa o en los individuales, normalmente se factura por horas (lo veremos en el artículo sobre facturación), y en estos casos se da la circunstancia de que las cancelaciones no son sólo por parte del profesor o del centro de formación: en estos casos, es posible (de hecho, es lo más común) que sea el cliente el que cancele la clase. Normalmente, se definen en este caso dos tipos de cancelación: Cancelación en plazo, que es cuando el cliente ha avisado de que no va a darse la clase, y entonces no se le factura, o Cancelación fuera de plazo, que es el caso tan típico en el que el profesor se presenta y no hay nadie a quién darle clase. En este caso, normalmente, la clase se factura aunque no haya sido impartida, pero es importante para el DOS saber qué clases han sido canceladas de esta manera. A final de curso, cuando se evalúa el avance del alumno, es importante tener en cuenta a cuántas clases el alumno ha acudido realmente, no cuántas se le ha facturado al cliente.

Alumnos

• nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300):
• etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos en grupos

• fecha_inicio: date
• fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto).

Asistencia

• asiste: boolean. Normalmente, cuando se crean los registros de asistencia (que se crean automáticamente cuando se crean las clases), el campo asiste está inicializado a NULL, para que así sepamos que esta información todavía no está disponible. Será el profesor cuando introduzca la asistencia el que indique si el alumno asiste o no. Mientras tanto… no se sabe.
• falta_justificada: boolean. Todo el proceso que está definido en este artículo se basa en la idea de que la asistencia de los alumnos y la cancelación de una clase son cosas separadas, porque la gestionan personas separadas. La información de cancelación de clases implica que se indique el motivo de dicha cancelación, y dicha información va a afecta a la facturación al cliente y al pago a los profesores, y por tanto es responsabilidad del DOS. La información de asistencia de los alumnos tiene valor desde el punto de vista académico (para calcular los porcentajes de asistencia de los alumnos a la hora de evaluar el rendimiento) y se usa en conjunción con la información de calificaciones. Como actualizar esta información es muy trabajoso por el volumen de datos que representa, los sistemas en general están pensados para que sean los profesores los que introduzcan esta información. Como la información de cancelaciones puede afectar directamente a sus pagos, los profesores no la introducen directamente en el sistema. Por tanto, que todos los alumnos tengan asiste = NO no implica que la clase esté cancelada… es lo tendrá que introducir el DOS, incluyendo el motivo.

Triggers y procedimientos almacenados

Este proceso, como hemos visto por la definición de las tablas, tiene muchos procesos ‘automáticos’, propios de la base de datos. Principalmente:

• Al crear un horario, tiene que haber un trigger que inserte en la base de datos todas las clases de ese horario, teniendo en cuenta la fecha de inicio y de fin y los días de clase, e incluyendo la gestión de días no lectivos si la hemos hecho.
• De la misma forma, necesitamos un trigger que al crear clases o incluir alumnos en grupos inserte en la base de datos los registros de asistencia de los alumnos y las clases a los que pertenecen.

Es muy importante que estos dos procesos estén incluidos en la base de datos… El trabajo principal de los DOS, y la fuente principal de información de producción en la empresa es esta parte, y por tanto es muy importante que estos procesos sean ágiles. En las primeras versiones de Bravo, este proceso sea hacía en el lado cliente del sistema, y el rendimiento dejaba muchísimo que desear.

Consideraciones finales

Creo que más o menos es todo… es muy importante que seamos conscientes de que esta gestión de horarios es muy detallada, y que por tanto implica mucha gestión para mantenerla al día: además de dar de alta los grupos, hay que mantener los cambios de profesor y ser muy preciso con las fechas de modificación, hay que introducir las cancelaciones, la asistencia de los alumnos… implica muchas horas de trabajo mantenerlo al día. A la hora de hacer una implementación como esta, hay que valorar los beneficios que reporta. Al principio del artículo he hablado que este modelo está pensado para centros de enseñanza de idiomas, lo cual no es del todo exacto. Este modelo está pensado para organizaciones que necesitan saber el número exacto de horas que se han trabajado en un periodo de tiempo dado, ya sea para facturar al cliente (como ocurre en los centros de idioma, en los departamentos de enseñanza para empresas) como para pagar al personal.

No he hablado de la gestión de los contratos de los profesores, o del proceso de facturación mismo, que incluiré en otros artículos, ni he descrito la manera de obtener informes de totales de horas (que se basa simplemente en sumar la duración de las clases en base a los criterios de fechas, tipos de cancelación, tareas, profesores, etc. que se necesiten).

Intentaré, en mi siguiente artículo, hacer un descripción de un proceso de facturación en el que se tengan que cobrar horas, y de cómo dejarlo lo suficientemente abierto como para facturar cualquier otra cosa.

Saludos a todos,

d

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Unos meses llevo ya bastante metido en grupos de networking profesional. Sí, el término da un poco de repelús pero reconozco que funciona, el topicazo aquel de “… en tiempos de crisis hay que unir fuerzas y blablabla …” debería ser “Hay que unir fuerzas”, sin más, cuando se acabe la crisis: también.

Networking empresarial

El concepto de networking profesional es sencillo: coordinados, a poder ser, por una empresa o institución con conocimiento sobre el tema se juntan empresarios, profesionales independientes o representantes de las empresas con la única intención de darse a conocer y conocer a los otros.

Sí, parece lo mismo que los sitios para conocer gente. Es, en mi opinión, muy parecido con la salvedad de que entre empresas puedes repetir sesiones semana tras semana con el mismo grupo de gente y cada día surgen nuevas posibilidades de alianza, recomendaciones y amigos. No pasa nada si una relación no llega a buen puerto, puedes seguir intentándolo incluso con la misma empresa.

En mi opinión, hay que tener claro lo siguiente cuando se llega a uno de estos grupos:

• No se trata de vender todo lo que se pueda a todos los del grupo, lo más probable es no vender nada a los del grupo.
• Paciencia, paciencia, paciencia. Disfruta del rato contando lo que ofrece tu empresa, lo que buscas.
• No todo es vender, puedes descubrir que tu discurso es mejorable, que puedes adaptar tus servicios a sectores que ni habías imaginado.
• No desestimes ningún contacto. Por distantes que te parezcan algunas empresas o sectores, nunca se sabe.
• Sé organizado con los contactos que hagas.
• Sobre todo: no dejes de hacer este tipo de cosas cuando tu empresa supere el bache.

Como ya he dicho, ni es magia, ni sustituye al resto del marketing ni nada pero es una forma, razonablemente nueva y buena de hacer contactos empresariales, buscar sinergias y, por qué no, realizar ventas o conseguir nuevos proveedores. Si te lo montas bien, como poco, aprenderás cosas y harás amigos.

Suerte!

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En el desarrollo de software para empresas, el almacenamiento de la información de un modo organizado es fundamental… la mayoría de los casos en los que el programador contesta “no se puede hacer” a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicación. En este artículo voy a intentar explicar, con un ejemplo práctico, un buen modelado de datos.

Como, de alguna forma, estamos especializados en el software de gestión de empresas de enseñanza, voy a utilizar un ejemplo de uno de esos modelos: la gestión de matriculación de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Voy a explicar en este artículo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementación), las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. De paso, daré una idea de los índices, procedimientos almacenados y triggers que nos pueden resultar útiles para que el rendimiento de la base de datos sea bueno.

Descripción del proceso de matriculación (el caso de uso)

Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman “grupos abiertos”, es decir, grupos en los que cualquiera se puede matricular (en oposición a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente).

Cuando llegamos a la academia, se nos ofrece un folleto o catálogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que más nos conviene, el horario al que vamos a asistir, y con esta información nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a través de nuestra cuenta bancaria.

En la academia, llegado este punto, introducen en su sistema de información nuestros datos y nos imprimen el contrato de prestación de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequeña cantidad del primer recibo.

En el siguiente día de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo… nos da la bienvenida, y empezamos a estudiar.

El modelo de datos

A partir de aquí haré una descripción de la estructura de tablas y columnas para almacenar la información de este proceso. Primero, algunas generalidades sobre cómo crear los campos.

Generalidades

Hay algunas cosas básicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas así). Por ejemplo:

1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen así un identificador interno, mantenido por el sistema. Así, las claves ajenas son más fáciles de mantener.
2. En general, nosotros no solemos poner campos requeridos… preferimos hacer la gestión dentro de la lógica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estábamos completamente seguros que eran requeridos y hemos tenido que quitar la marca.
3. No se duplica información. Es decir, una de las reglas básica es que la misma información no puede estar en dos sitios, salvo…
4. En muchos casos, creamos campos calculados, que permiten acceder de forma rápida a información… por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales… como hacer este cálculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automáticamente (en nuestro caso, a través de Triggers de la base de datos). La información está duplicada en dos sitios, sí, pero por motivos de rendimiento (y siempre está sincronizada).
5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dónde vas a tener que acceder.

Descripción de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Según el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos):

• Cursos: almacena la oferta formativa del centro. Representa el catálogo o folleto que te dan al llegar al centro.
• Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto también). Trimestral, mensual, anual, etc.
• Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante más complejo que el que voy a describir aquí… en un artículo posterior lo describiré en detalle.
• Clientes: el que paga… puede ser el mismo que el alumno, pero también puede que no.
• Medios de pago: Contiene los diferentes métodos que los clientes pueden usar para pagar (contado, domicilación bancaria, etc), incluyendo las cuentas bancarias del cliente.
• Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurídicas), los alumnos son personas físicas. Un mismo cliente puede tener múltiples alumnos.
• Matrículas: Refleja en qué curso nos matriculamos, las fechas, la forma de pago, etc. De forma física, se refleja en el contrato que te dan para firmar.
• Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro.
• Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestión de recibos y pagos que hacemos en realidad es más compleja de lo que voy a describir aquí. En otro artículo haré una descripción más completa.
• Alumnos en grupos: refleja los alumnos que están asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa información histórica, así que necesitamos una tabla para gestionarlo.

Aquí podéis ver el modelo gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla.

Campos para las entidades

Sólo describiré los campos más importantes, y no incluiré los campos de clave primaria y ajena que se describen en el gráfico.

Cursos

• nombre: varchar(100)
• descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
• fecha_inicio: date
• fecha_fin: date

Formas de pago

• nombre: varchar(100)
• importe: float. Es el importe de cada recibo que se cobrará
• numero_meses: integer. El número de meses de cada recibo. Si es 1, se creará un recibo cada mes mientras dure la matriculación, si es 3, uno cada tres meses, etc. En algún sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite más flexibilidad y más control, pero el modelo es bastante más complejo.
• numero_orden: integer. A la hora de presentárselo al cliente, poder mostrar primero las que más nos interesen.
• importe_matricula: float. Si además del importe del curso hay un importe de matrícula, se marca aquí.
• concepto_matricula. El concepto del recibo de matrícula, si creamos uno.

Grupos

• nombre: varchar(100)
• codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
• fecha_inicio: date
• fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
• lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo.
• notas: memo, del grupo
• horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
• maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
• numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Clientes

• nombre: varchar(100). En nuestros sistemas, normalmente, este es el único campo requerido (por código, no en la base) que tenemos. Así, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver después.
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para poder coger de forma rápida el conjunto Nombre+’ ‘+primer_apellido+’ ‘+segundo_apellido
• direccion: memo
• codigo_postal: varchar(20): no hay que ser tacaño… de vez en cuando hay que meter una dirección extranjera y el código postal puede ser más grande.
• poblacion: varchar(50)
• notas_internas: memo
• etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos

• nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300):
• etc. de datos personales (profesión, teléfonos, email, etc.)

Medios de pago

• tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que suelen ser: Sin Pago, Contado, Banco
• nombre_titular: varchar(100)
• direccion_titular: memo
• entidad: varchar(4)
• oficina: varchar(4)
• dc: varchar(2)
• numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la información bancaria del cliente.
• por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se crea un medio de pago “contado”, y se le pone por defecto.

Matrículas

Además de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto último puede parece redundante, pero no lo es… podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar, digamos, inglés y francés… el inglés lo paga el padre y el francés la madre. Así, es necesario que cada matrícula esté asociada con el alumno, y también con el cliente), necesitamos los siguientes campos:

• fecha_inicio: date.
• fecha_fin: date.  Por defecto, las del curso, pero hay gente que puede matricularse después o terminar antes (si se da de baja, por ejemplo).
• importe: real. Por defecto, el de la forma de pago escogida, pero puede ser también distinto… descuentos por familiares, cosas así. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda cambiar.
• motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego poder obtener estadísticas de número de bajas por tipo, cosas así.

Recibos

• fecha_emision: date
• fecha_cobro_completo: date
• numero_recibo: varchar(20)
• concepto: varchar(50)
• importe_recibo: float.
• importe_pendiente: float. Es un campo de sólo lectura, actualizado a través de triggers, que permite acceder a la información sin tener que sumar.

Pagos

• fecha: date
• importe: real
• forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja. Puede ser: contado, transferencia, tarjeta, talón, etc.

Alumnos en grupos

• fecha_inicio: date
• fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto).

Triggers y procedimientos almacenados

El modelo de datos y la lógica del negocio están muy estrechamente relacionados. Los sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados, lo que es muy conveniente para dejar trozos de la lógica de negocio asociados con la base de datos, tanto por motivos de organización del código como por motivos de rendimiento (un procedimiento almacenado es varios órdenes de magnitud más rápido que hacer el mismo proceso a través de un lenguaje de programación).

En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan:

• Actualización de los campos “NombreCompleto” de alumnos y clientes: normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al contenido del nombre y los apellidos.
• Actualización del campo “ImportePagado” de recibos, AFTER INSERT, UPDATE y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo.
• Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso de creación de la matrícula (o un trigger AFTER INSERT), que crea los recibos de la matrícula en base al importe y forma de pago seleccionadas.

En las próximas semanas continuaré esta serie de artículos, describiendo otros submodelos de sistemas que hemos desarrollado… algunas ideas que tengo:

1. Gestión de horarios y citas
2. Facturación
3. Gestión de horas trabajadas
4. Stock

Cualquier otra idea será bienvenida…

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Hace un par de días que se ha aprobado el Plan Avanza 2 para este año.

Cada vez más se potencia el tema de las TIC además del I+D puro, este año permiten financiar proyectos de software de varios tipos. Pueden llegar a financiar el 100% de la inversión (excepto el IVA).

Las inversiones posibles incluyen productos electrónicos, informáticos y de telecomunicaciones, incluyendo hardware, software, aplicaciones, servicios y contenidos para:

Más información en mi correo y mucha más información en la web del Plan Avanza 2.