jueves, 28 de mayo de 2009

Pasar schemas a SQL

0 comentarios
 
Como sabrán los administradores más avanzados, todos los datos de KMKey se estructuran en types, que se componen de schemas de campos para su definición + layouts de widgets para su representación (se puede ver todo eso entrando en el Zope Management Interface, o ZMI, entrando en http://url_site/manage)

El hecho de tener ZODB por debajo nos va de maravilla para tener esa flexibilidad de datos que caracteriza a KMKey, pudiendo definir patrones de trabajo con sus campos, etc. Pero en ocasiones, una vez un patrón está definido, configurado y en funcionamiento, tener los datos en SQL nos iría mejor para su explotación. Bien, pues también tenemos solución para eso: se pueden configurar los schemas para que graben sus datos en postgresql

Para ello se tiene que instalar el producto ZPsycopgDA en Zope. En Debian lo más fácil es hacer un "apt-get install python-psycopg && apt-get source python-psycopg", y cogerse el directorio ZPsycopgDA que habrá dentro del fuente, así cuadran las versiones. Una vez puesto esto en el Products de nuestro zope y reiniciado éste, se crea una conexión Psycopg a la BBDD en el site, llamémosla 'db'.

Luego te vas a un portal_schemas, por ejemplo kmkey_work, pestaña "SQL", le indicas el nombre de la conexión 'db', y le das al botoncillo que dice "Migrate To SQL". Ya tienes tus imputaciones de horas en SQL, y a partir de ahí pista libre ... repetir para cada uno de los schemas que se quiera
Leer más...
viernes, 22 de mayo de 2009

Exportación / Importación de patrones

0 comentarios
 
En la nueva versión de KMKey hemos incluido capacidades para exportar de forma completa patrones de trabajo, y para poder importarlos después desde otra instancia, todo ello desde el TAB Admin. El formato de intercambio es un simple fichero .tgz que contiene toda una serie de ficheros XML, e incluye información relativa al patrón, sus campos, su layout, sus contadores, sus vocabularios asociados, incluso los grupos de permisos necesarios para utilizarlo.

Con ello esperamos:

1) Facilitar la separación de entornos de desarrollo, pruebas y de producción, puediendo traspasar los patrones de una instancia a otra de forma sencilla, y no afectando así las configuraciones a los entornos de producción hasta que esten validadas

2) Fomentar el intercambio de patrones de trabajo entre los miembros de la comunidad KMKey. Porque, si uno dispone de un patrón de gestión comercial que le funciona, ¿ porqué no compartirlo y dejar de reinventar la rueda ? Ese es el espíritu del sofware libre que puede ayudarnos a mejorar mucho a muchas pequeñas empresas, en lugar de mejorar sólo un poco cada una. Intentaremos ubicar un repositorio de patrones de trabajo en esta misma página o en alguna vinculada
Leer más...
jueves, 21 de mayo de 2009

Darle cancha a postgresql

0 comentarios
 
Como últimamente todas las instalaciones de KMKey van totalmente sobre postgresql gracias a relstorage, es aconsejable darle más máquina a la BBDD de la que viene por defecto al instalar el paquete de postgresql.

El problema es que al intentar hacerlo nos encontramos con que da un error de máximo tamaño de buffers. La receta para solucionarlo está perfectamente explicada, aquí: http://www.postgresql-es.org/node/229 aunque lo principal, aparte de ajustar el postgresql.conf, es esto


1) Editar el fichero /etc/sysctl.conf, y añadir la linea:
kernel.shmmax = 2147483648 (para 2 GB de RAM)
268435456 (para 256 MB de RAM)
536870912 (para 512 MB de RAM)

2) Para instalar los cambios tenemos que ejecutar el comando
sysctl -p /etc/sysctl.conf

Respecto a los ajustes del postgresql.conf, para un servidor dedicado a KMKey con 2GB de RAM disponibles, podemos ajustar el shmmax a 512 MB y establecer los siguientes parámetros, a nivel orientativo:

shared_buffers = 32768
temp_buffers = 16384
work_mem = 32768
maintenance_work_mem = 16384
max_stack_depth = 2048

max_fsm_pages = 200000
max_fsm_relations = 10000

effective_cache_size = 8000
Leer más...

Extender el uso de patrones

0 comentarios
 
Aunque hasta ahora el uso de patrones se ha limitado primoridalmente a patrones de trabajo (o sea, de proyectos / expedientes), ya hace tiempo que detectamos que este modelo es muy útil por su potencia y flexibilidad, así que poco a poco lo hemos ido incorporando a otras partes de la aplicación, creando patrones de contactos, de empresas, de gastos o de ventas. En la nueva versión de KMKey vamos un pasó más allá, y vamos a abrir la posibilidad de personalizar, mediante patrones, casi todo tipo de contenido.

Se ha habilidado copiar patrones de todo tipo para poder peersonalizarlos. Así por ejemplo, podemos duplicar el patrón de gasto y crear una píldora kilometrage, en la que luego ajustemos campos y valores por defecto.

También se ha abierto la posibilidad de bloquear perfiles en la creación de dichos objetos, algo que hasta ahora sólo se aplicaba a proyectos. De esta forma, se puede configurar que las píldoras de gastos sólo sean visibles a su Propietario y al responsable del proyecto, o crear un nuevo tipo de contactos de uso exclusivo de la Dirección, por citar algunos casos
Leer más...
martes, 19 de mayo de 2009

Apuesta por el Teletrabajo

15 comentarios
 
Hará unos cinco años que teletrabajo a tiempo completo. Fundamentalmente me dedico a desarrollar e implantar software libre y, como además el software es en entorno web, nos dijimos ¿ porqué no hacerlo a distancia ? Pasado este tiempo, y en pleno debate del cambio de modelo productivo, me gustaría compartir algunas reflexiones sobre mi experiencia

1) ¿ Que sentindo tiene perder una o dos horas de tu vida cada dia iendo y viniendo, cuando puedes realizar tu trabajo a distancia? Eso es lo primero que uno aprecia cuando teletrabaja, el tiempo ganado a los trayectos. Eso si, para evitar empleados demasiado listos, las empresas tienen que disponer de algun sistema de control de los trabajos realizados (nosotros usamos KMKey, como no podía ser de otra manera).

2) Puedes mudarte a un lugar tranquilo. Pasado un tiempo, y viendo que la situación era estable, me mudé con mi familia a vivir a Menorca. Ahora que empieza el calorcillo, plantarse en una playa paradisíaca en 15 minutos no tiene precio (no pongo fotos para no dar demasiada envídia)

3) El sueldo importa, pero no es lo más importante. Mi sueldo está lejos del de muchos compañeros de promoción, pero a veces hay que saber renunciar a algo de dinero para ganar en calidad de vida. Mi rutina matutina es levantar a los niños, desayunar tranquilamente, llevarlos al colegio dando un paseo, tomarme un café con unos amigos, y aun me sobra tiempo para llegar paseando a mi “teleoficina” a las 9 de la mañana. Cuando recuerdo como era la rutina matutina en un gran ciudad y trabajando con corbata, no lo cambiaría por nada del mundo.

4) La conciliación de la vida familiar y laboral. En mi caso eso es especialmente importante, porque con 4 hijos y una esposa que también trabaja, poder combinarse los horarios y tener una solución cuando un niño se pone enfermo a las 7 de la mañana es algo que se valora, y mucho.

Bueno, esas son las cosas que más aprecido del teletrabajo yo personalmente. Otros compañeros tienen otras preferencias, y aprovechan para trabajar algunos meses desde Argentina mientras aprenden tango, o desde Brasil tumbados al sol, en lugar de cambiarse permanentemente de residencia. Cada loco con su tema, claro.

En fin, que cuando oigo hablar tanto de aumento de eficiencia y competitividad, de fomentar negocios basados en el conocimiento y las nuevas tecnologías, de conciliar vida familiar y laboral, no puedo evitar preguntarme porqué no se implanta de una vez el teletrabajo de forma extensiva en las empresas de servicios, eliminando todos esos absurdos trayectos estresantes, compensando a los empleados con otras ventajas que no sean más dinero, dispersando a la población ... saldríamos todos ganando, porque cuando uno está contento trabaja mejor, porque acepta incluso cobrar un poco menos, porque la empresa puede buscar al mejor para cada puesto viva donde viva, etc. etc. Dejemos de ver estas cosas como algo del futuro, son el presente inmediato.

Ah ¿ que donde trabajo ? En Earcon S.L., una empresa 2.0, como lo han definido algunos de nuestros propios clientes :-)
Leer más...
viernes, 15 de mayo de 2009

Configuración Básica de Permisos

2 comentarios
 
Configuración permisos KMKey

Por defecto KMKey viene con los siguientes grupos de permisos asociados a roles de CPS, y configurados como Perfiles de Aplicación:

- Lector Aplicación (WorkspaceReader)--> Ver Contenido (y Listar)
- Usuario Aplicación (WorkspaceMember)--> Ver, Crear y Modificar
- Responsable Aplicación (WorkspaceManager) -->Ver,Crear,Modificar,Gestionar equipo y Planificar

Estos permisos se pueden configurar desde la gestión de grupos, pero respetando la coherencia de cada uno de los grupos. Por ejemplo, por comodidad, podemos tener la tentación de dar permiso de escritura al 'Lector de Aplicación' , pero lo correcto es agregar los usuarios al grupo 'Usuario Aplicación'.

Por defecto, Lector Aplicación está asociado a authenticated (vía ZMI), a nivel de site, de tal forma que cualquier usuario que se logine , podrá entrar al KM (pero no podrá ver expedientes, ya que por defecto, en los patrones, se bloquea Lector y Usuario)
Opcionalmente, También podemos asociar authenticated a Usuario Aplicación si queremos que todo el mundo pueda crear expedientes.

Por otro lado tenemos los siguientes grupos de permisos asociados a roles, pero no activados como Perfil de Aplicación, si no que serán perfiles de Expediente (sólo actuarán a nivel de expediente)

- Lector Expediente (Reader) --> Ver Contenido
- Propietario (Owner) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar
- Responsable Expediente (Responsable) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar

Por defecto, cuando se crea un objeto dentro de KM, se asigna automáticamente el usuario que lo crea como Owner (si no, una vez creado, no podría acceder a él)
Para dar acceso a un usuario dentro de un expediente, podemos agregarlo como 'Lector Expediente' y en este momento podrá verlo
Para dar permisos de Modificación u otros a un usuario dentro de un expediente, crearemos los nuevos perfiles de expediente necesitemos (Técnico, Secretaria, etc...) intentando unificar y utilizar el menor número de perfiles posibles

Con esta configuración mínima, ya podemos gestionar los siguientes casos:

- Todo usuario podrá entrar a la aplicación y ver expediente, contactos y grupos
- Todo el mundo que pertenezca a 'Usuario Aplicación' podrá crear cualquier tipo de expediente (ya pertenezca al grupo de forma implicita o vía asignación a authenticated)
- Todo el mundo verá únicamente los expedientes donde esté asignado (Como creador , lector u otro)

Esta configuración contempla la mayoría de casos que necesitaremos

Configuraciones avanzadas:

Como hemos comentado antes, creando nuevos perfiles de expediente determinaremos qué podrá hacer cada usuario dentro de cada expediente (Técnico podrá añadir, pero no planificar, Responsable Delegación podrá planificar, etc... )

En la configuración de patrones, tenemos las dos utilidades siguientes:

1- Qué perfiles pueden participar y qué perfiles se bloquean (Opción 'Modificar') en los expedientes creados a partir de este patrón
2- Qué perfiles pueden ver o no el propio patrón (Acción 'Bloquear Perfiles')

La opción 1 nos permite configurar, por ejemplo (viene por defecto en todo nuevo patrón) que 'Usuario Aplicación' y 'Lector Aplicación' NO puedan ver los expedientes creados con este patrón.

La opción 2 nos permite bloquear el propio patrón, o sea, podemos bloquear el 'Usuario Aplicación' para que NO pueda crear expedientes de determinado tipo

Estas configuraciones también son aplicables a los patrones de Píldoras, permitiendo seleccionar qué perfiles podrán o no crear ventas, horas, etc...

Ejemplos:

Caso: Queremos que TODO usuario loginado vea los expedientes de determinado tipo:
Configuración : Patrón --> Modificar --> Roles Bloqueados --> Desactivar 'Lector Aplicación' (Esto lo podemos hacer también a nivel de un expediente, en gestionar contactos, desactivando el perfil bloqueado)

Caso : Queremos que únicamente el 'Responsable Aplicación' pueda crear expedientes con el patrón 'Oferta'
Configuración : Patrón --> Bloquear Perfiles --> Columna de perfiles bloqueados --> activarlos TODOS menos el de 'Responsable de Aplicación'. (Nota : Esta configuración tiene el 'problema' que, cuado añadamos un nuevo perfil de aplicación, deberemos revisar los patrones para bloquear este nuevo perfil, si es necesario, ya que no se hace de forma automática)

La definición de los permisos se puede llegar a complicar bastante, así que és muy recomendable definirla bien desde el principio.

El caso más 'problemático' sería la creación o cambios de configuración en los Perfiles de Aplicación una vez ya se hayan introducido expedientes, lo que requiere, por un lado, revisar la configuración de los patrones, y por otro, reindexar todos los expedientes para que se apliquen los nuevos cambios (sólo en caso de modificación de un perfil existente)

La recomendación es NO CREAR NINGÚN perfil de aplicación, utilizar únicamente los 3 que ya viene por defecto (Lector Aplicación, Usuario Aplicación y Responsable Aplicación) y gestionar los accesos a los patrones mediante los bloqueos de grupos de sistema, siguiendo la misma técnica q hemos comentado antes, ya que se puede aplicar a cualquier perfil, y solucionamos la problemática antes comentada

finalmente tendríamos el caso de de que queramos dar acceso a un grupo determinado a los expedientes de determinado patrón. Esto la haremos creando un campo del tipo 'KM Relation' en el schema, con un default value y un write expression string:docid_de_grupo, y asociado al role Reader, de tal forma q se asignará automáticamente al crear el expediente, una asoación entre el grupo y el perfil Reader, lo que dará acceso al expediente.

De esta forma se pueden ir añadiendo funcionalidades y cada uno sigue
viendo lo suyo, y solucionamos el problema que produce añadir un nuevo
perfil de aplicación con respecto a los expedientes existentes de
otros departamentos.






Leer más...
miércoles, 13 de mayo de 2009

Mejoras de velocidad (II)

1 comentarios
 
Siguiendo con el tema de las mejoras de velocidad del programa para volúmenes elevados de datos, hemos dado con un fallo heredado de Nuxeo CPS (gestor de contenidos sobre el que se basa KMKey). El fallo estaba relacionado con la gestión de árboles de navegación, y afectaba especialmente el navtree de proyectos y tareas.

Día y medio después de la puesta en funcionamiento de la correción en entorno beta, podemos decir que ha sido un de los mayores avances en el rendimiento de KMKey. En conjunto, desde que se empezaron las mejoras en este sentido, el consumo de RAM se ha dividido por 5, el consumo de CPU ha pasado de un 100% frecuente a no superar el 40% prácticamente nunca, y la velocidad en uso de los usuarios ha mejora espectacularmente.

A falta de mejoras en puntos específicos del programa (no ya de carácter general), podemos asegurar que la nueva versión de KMKey 3 responderá bien en empresas grandes, independientemente del volumen de datos, usando simplemente un servidor de gama media, y teniendo la tranquilidad de disponer de una arquitectura totalmente escalable.
Leer más...

Cambiar formato de un campo contador

0 comentarios
 
Cuando a través de KMKey añadimos un campo a un patrón de trabajo del tipo "Contador", los expedientes creados a partir de ese patrón de trabajo tienen un formato por defecto (PM-00000), pero con frecuencia queremos que ese formato cambie en función del patrón.

Por ejemplo, si queremos que nuestras No Conformidades tengan contadores del tipo NC0000, tenemos que entrar al ZMI (http://url_kmkey/manage), e irnos al objeto portal_uid. Allí encontraremos diversos contadores, con el nombre idpatron_idcampo. Pinchamos en el que nos interesa, y nos vamos a la pestaña "Properties". En el campo "Generation Expression" ponemos el formato que deseamos, en este ejemplo "python:'NC%04i' % number"
Leer más...
martes, 12 de mayo de 2009

Reconstruir un portal_repository

0 comentarios
 
Esta es una de las cosas en que nadie desea encontrarse: una corrupción de ZODB. De hecho es la primera que se ha producido desde que KMKey existe, y ha sido debida a una conjunción de uso de BLOGS en postgresql (cosa que no debería hacerse nunca, porque existe la alternativa de gestionarlos como ficheros locales) + errores de conexión a postgresql (que se encontraba en otra máquina y ha dado diversos problemas de conexión por DNS y máximo de conexiones permitidas). El hecho es que nos hemos encontrado con una corrupción de 11 objetos del portal_repository, que no había forma ni de borrar. Finalmente todo se ha solucionado recuperando copias de seguridad, exportando los objetos afectados del portal_repository no corrupto, y reconstruyendo el BTree. Después de eso, se han importado los objectos correspondientes el la BBDD de producción, y todo solucionado. La parte realmente dificil ha sido reconstruir el BTree, así que pego aquí el script para que quede para la posteridad:


repo = km.portal_repository
from BTrees.OOBTree import OOBTree
repo._tree_old = repo._tree
repo._tree = OOBTree()
i = 0
no_procesados = []
for mt in repo._mt_index.keys():
for id in repo._mt_index[mt]:
try:
ob = repo._tree_old[id]
repo._tree[id] = ob
except KeyError:
print "No se procesa %s" % id
no_procesados.append(id)
Leer más...
lunes, 11 de mayo de 2009

Formación KMKey HelpDesk

2 comentarios
 
KMKey HelpDesk

En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.

Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de incidencias, servicios de mantenimiento, sistemas de ayuda al usuario, servicios de atención al cliente, servicios de gestión de averías, o Tickets I*net, etc.

Conceptos principales:
  • Entorno colaborativo.
  • Los participantes en KMKey HelpDesk (permisos y accesos) pueden estar definidos desde el operador que recibe la incidencia, hasta el gerente, pasando por los técnicos o miembros de los departamentos involucrados en la solución de la incidencia.
  • Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
  • Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
  • Interface gráfico para la "visualización" de la evolución de cada incidencia/averia/ticket/queja, etc..
  • Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de incidencias, de actividad de los técnicos, de estado de las incidencias por categoria, etc.
Las acciones propias a todos estos servicios se pueden sistematizar y automatizar como distintos patrones de KMKey HelpDesk.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.

Más que en Project y en Quality, los efectos que "causan" en KMKey HelpDesk:
  1. la posibilidad de la sistematización de toda la secuencia de acciones en patrones de trabajo...
  2. el hecho que estos patrones de trabajo puedan incluir un flujo de la información bien definido...
  3. entre un número de participantes con
  4. pocos roles intercambiables y perfiles de intervención, también, muy bién definidos
facilitan extraordinariamente las tareas de recogida de requerimientos y las labores de formación, en todo lo que respecta a las partes básicas de funcionamiento de la aplicación.

Prácticas de funcionamiento
Conceptos Previos:
Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.
  • Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
  • Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
  • Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
  • En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
  • Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
    - quién lo inicia,
    - a quién lo envia,
    - a quién se notifica,
    - qué decisiones se toman,
    - cómo y cuando se supervisan,
    - quiénes son sus responsables, etc.
Así en KMKey Help Desk tenemos a disposición un sólo patrón para la demostración.

Práctica 1
  • Iniciamos un patrón de Ticket I*net.
  • Utilizamos el usuario (eva).
  • Recogemos los datos.
  • Decidimos un Revisor de la Incidencia (raúl).
TAB DEFINICIÓN
  • Mostramos que se ha inciado un expediente en el NAVTREE y lo abrimos mostrando la tarea asociada.
  • Salimos del usuario eva.
Práctica 2
  • Entramos como raúl.
  • Mediante el sistema de Mensajes, mostramos como que da notificado de su afectación a ese expediente.
  • Mostramos que existen una serie de nuevos datos listos para ser recogidos a través de DEFINICIÓN > Modificar.
  • Raúl rellena la parte que le corresponde y la envia al receptor rafa.
  • Salimos del usuario raúl.
Práctica 3
  • Entramos con el usuario rafa.
  • Volvemos a mostrar como nuevos campos se añaden al TAB DEFINICIÓN.
  • Entramos en el expediente mediante el sistema de notificaciones que también habrá funcionado en este caso.
  • Rafa rellena la parte de información restante.
Prácica 4
TAB EQUIPO
  • Podemos asignar un usuario al expediente y darle permisos mediante un rol.
  • Explicar que el usuario podrá definir los roles que necesite.
  • Mostrar un grupo que sea de Técnicos.
  • Asignar un grupo de técnicos al expediente.
Práctica 5
TAB PLANIFICAR
  • Podemos mostrar la posibilidad de que en otros patrones (mostrar ejemplos de Project o Quality) se puede modificar la planificación de la tareas y/o sus responsables.
  • No hace falta insistir demasiado en ese aspecto, aunque si en el siguiente.
  • Mostrar como podemos realizar (para patrones en los cuales el flujo no este tan definido internamente como en el de Ticket I*net) asignaciones en fecha, (día y hora) para un técnico concreto del equipo añadido anteriormente.
TAB GESTIÓN
  • Introducción a la filosofía de los 4 ejes de desarrollo, aunque, en la mayoría de casos no se utilizen los 4 ejes.
  • Insistir en el eje conocimiento/información.
Práctica 6
Añadir Documento
  • Mostrar la posibilidad del gestor documental y/o gestor de versiones. Sin insistir.
  • Añadir un documento generado a través de plantilla. Resumen de Incidencia.
Práctica 7
  • Añadir Nota a uno o varios participantes.
Práctica 8
  • Enviar un e-mail desde el expediente.
  • Enviar un e-mail al expediente o tarea.
Práctica 9
  • Añadir una imputación de horas.
  • Hacerla coincidir con la asignación realizada anteriormente.
  • Mostrar el resultado en Historia.
Práctica 10
  • Añadir un gasto personal o una venta sucedidos durante la solución de la incidencia.
TAB CONTROL
  • Mostrar los recursos gráficos obtenidos con la pantala específica de HelpDesk.
  • Mostrar la pantalla de fechas.
  • Mostrar las posibiliadades de obtener Listados de Tickets, Tareas no finalizadas, Gastos, etc.
Leer más...

Cerrando el círculo

1 comentarios
 
Objetivo: modificar las planificaciones de economía y esfuerzo al desplazar la planificación temporal.

Problemática actual
Dentro de las evoluciones previstas para KMKey Project está la de guardar versiones de la planificación. Esto nos ha de permitir ir modificando las fechas previstas sin perder el historial y poder recuperar versiones anteriores para poder ver la evolución de la planificación.
En la actualidad estas modificaciones no tienen ningún efecto sobre las previsiones económicas y de esfuerzo que permanecen igual, aunque las fechas planificadas para la ejecución de la tarea cambien.

Evolución propuesta:
Ligar las previsiones de esfuerzo y económicas a la planificación temporal.

Modificaciones necesarias:

Esfuerzo:
Horas previstas por tarea.
Hasta ahora, cada tarea tiene unas horas previstas para completar su realización. Lo lógico es que para calcular el esfuerzo necesario, lo hagamos entre las fechas de inicio y fin previstas de la tarea. Si estas cambian en el tiempo. Los días de aplicación del esfuerzo también. La versión actual de KMKey así lo contempla
Recursos reservados.
Sin embargo, cuando reservamos un recursos en unas fechas determinadas, las horas de esfuerzo previstas pierden la relación con la planificación de la tarea. Si esta cambia, la reserva del recurso no se ve afectado. Esto es lo que seria lógico cambiar. Lo ideal es que proponga "las fechas previstas de realización de la tarea han cambiado. ¿Quiere aplicar el mismo cambio a los recursos reservados?". En caso afirmativo, ofrecer la pantalla de planificación de recursos para poder realizar la nueva asignación en el periodo previsto.

Economía:

Actualmente se puede escoger las fechas previstas para las entradas económicas, tanto si se trata de un día como de un periodo. También pueden asignarse a todo el proyecto o una fase o tarea. Pero sin relación entre ambos.
El cambio propuesto es sencillo. Por defecto, las líneas de entrada de conceptos económicos previstos, deberían tener las fechas de inicio y fin previstas en la planificación del momento. De nuevo, si estas cambian, hay que preguntar si se quieren actualizar las fechas previstas a las de la tarea.
Leer más...

Formación KMKey Quality

4 comentarios
 
En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.

Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de sistemas de calidad de cualquier norma ISO y otras.

Conceptos principales:
  • Entorno colaborativo.
  • Los participantes en el SGC (permisos y accesos) pueden estar definidos desde el operario de planta, hasta el gerente, pasando por el propio Dpto. de Calidad y el resto de los mismos.
  • Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
  • Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
  • Interface gráfico para la "visualización" de la evolución de cada expediente.
  • Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de calidad, listados de documentos, informes, resúmenes de actividad, de acciones abiertas, cerradas, en trámite, etc.
KMKey Quality incorpora un Gestor documental que contempla el Ciclo: Edición, Revisión, Aprobación y un sistema de gestión de versiones (revisiones) que lo hace idóneo para demostrar la trazabilidad, accesibilidad, actualización y validación de todos los documentos propios de la normativa:
tales como:
  • Procedimientos Documentados (Obligatorios o no).
  • Manual y Política de Calidad.
  • Objetivos e indicadores del sistema.
  • Organigramas.
  • Mapas de Procesos.
  • Instrucciones y hojas de trabajo
  • Formatos.
Las acciones propias a todo SGC (obligatorias por la norma o no) se pueden sistematizar y automatizar como distintos patrones de KMKey Quality.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.
asi como:
Todo tipo de registros (obligatorios por la norma o no).
  • Gestión completa de No Conformidades.
  • Acciones Correctivas/Preventivas.
  • Revisiones del Sistema.
  • Planes de Auditoría.
  • Planes de Mejora.
  • Planes y registro de Formaciones.
  • Seguimiento y Evaluación de Proveedores.
  • Gestión y Control de Indicadores.
  • y otros
Prácticas de funcionamiento
Conceptos Previos
  • Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.
  • Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
  • Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
  • Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
  • En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
  • Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
    - quien lo incia,
    - a quien lo envia,
    - a quién se notifica,
    - que decisiones se toman,
    - como y cuando se supervisan,
    - quiénes son sus responsables,
    - etc.
Práctica 1
Iniciamos (usuario santi) una NC de Proveedor para concentrar las explicaciones de patrón, campos, flujo de trabajo y equipo.

TAB DEFINICIÓN
  • Vemos los datos rellenados.
  • Hacemos observación que NO TODOS los datos de la NC se han rellenado en ese paso, pues puede que el que incia la NC no los conozca o no tenga porqué conocerlos.
  • Avismos que los campos para la captura de los datos que todavía faltan, irán apareciendo en función del usuario y paso en el que se encuentre la acción.
TAB EQUIPO
  • Vemos los participantes incorporados con perfiles de Creador y Receptor
  • Damos a entender que este flujo podría completarse todavía con un aprovador/revisor o enlazarlo con otra acción del sistema como podría ser una AC/AP.
  • Salimos del usuario santi y entramos como Albert, o el que hayamos elegido como receptor.
TAB DEFINICIÓN (2º participante)
  • Selecionamos el objeto en el NAVTREE y el TAB DEFINICIÓN > MODIFICAR.
  • Rellenamos parte de los datos en los nuevos campos que aparecen.
  • Mostramos como podemos iniciar en esa parte del flujo (o en cualquier otra que definiese el cliente) una AC/AP.
  • Realizamos la práctica de vincular una y otra.
  • Mostramos el nuevo expediente de AC/AP incorporado al NAVTREE.
  • Si no se tiene preparado, montar un filtro en el que se muestren la NC (de proveedor) y las AC/AP.
  • Mostrar como podemos pasar de una a la otra NC > AC/AP y de esta a la NC que la originó.
  • Mostrar como el flujo y los responsables/fechas/verificaciones/cierres se pueden adaptar a las necesidades de cada organización.
  • Mostrar como, además, con KMKey Quality tendremos la posibilidad de visualizar en cada momento el estado de cada "acción".
  • Mostrar como podemos dividir tanto la NC, como la AC/AP en tareas que aparecen en el NAVTREE.
En este punto hay que recordar que las explicaciones de Quality no deben hacer "demasiada" insistencia en las partes "fuertes" de KMProject que no se utilizan con el mismo "espiritu" en Quality.
Así, por ejemplo, la división de una acción en distintas tareas, con desarrollo espaciado y secuenciado en el tiempo, con responsables de cada acción queda más evidente si elegimos iniciar una patrón de Auditoría Interna, aunque sólo sea como ejemplo.
Eso es así, debido a que la mayoría de los otros patrones de Quality no dependen tanto de la división en tareas y su desarrollo "al modo" de un proyecto, como de un "flujo de trabajo y orden de intervenciónes" que sumado a unos roles bien definidos configuran toda la acción.

Práctica 2
Por tanto, iniciamos un patrón de Auditoría Interna, más como un ejemplo para LOS TABS EQUIPO y PLANIFICAR, que como otra cosa.
  • Mostramos mediante la apertura del nuevo expediente su división en tareas, con fechas y responsables.

TAB PLANIFICAR

  • Mostramos, mediante la elección de una escala de visualización apropiada, el histograma GANTT del desarrollo de las tareas.
  • Mostramos como mediante "Editar Planificación" o mediante "Modificar" podríamos variar a voluntad las fechas de incio y final de tarea y adaptarlas a nuestras necesidades.
TAB EQUIPO
  • Mostramos como podemos crear un supuesto equipo de Auditores, como Grupo de Recursos/Permisos.
  • Añadimos integrantes a este equipo.
  • Añadimos el equipo creado al expediente nuevo de Auditoria.
  • Volvemos al TAB PLANIFICAR.
  • Mostramos como podemos variar el responsable de las tareas.
  • Mostramos (PLANIFICAR-RECURSOS) y como en un momento dado podríamos llegar a planificar: qué auditor hace qué en una tarea y dia concreto.
Práctica 3
  • Realizamos una asignación y la mostramos en el TAB GESTIÓN > Historia.
  • Advertimos de la posibilidad de que ciertos patrones tengan como opción que las tareas se incien automáticamente con la inclusión de un item de información o que por el contrario se abarn manualmente.
TAB GESTIÓN
Aprovechando la anterior explicación y el expediente de Auditoria recien creado, pasamos al ámbito del TAB GESTIÓN
  • Mostramos los 4 tipos de elementos de información pertenecientes a los 4 ejes de desarrollo de todo proyecto/expediente. (INFORMACIÓN, TIEMPO, ECONOMÍA y ESFUERZO.
  • En este punto hay que advertir que permanecen a la vista los elementos temporales, económicos y de esfuerzo que aunque no sean demasiado "vitales" para los SGC, los mantemos a la vista como posibilidad. (Otros lientes nos los han solicitado)
  • Insistir en los elementos pertenecientes al eje conocimiento/información.
  • Volver a mencionar las prestaciones de KMKey en cuanto al mantenimiento de un sistema de gestión de documental, incorporando un ciclo (Edición, Revisión, Aprobación) totalmente nomativizado.
Práctica 4
Por tanto, iniciamos un ejercicio de "Añadir documento" y advertimos que lo someteremos por completo al ciclo mencionado.
Inciamos la práctica con el usuario santi, como editor.
  • Sube un documento, genera una versión y la envia a revisión.
  • Mostrar los cambios que se producen en la visión de Historia. (Documento -copia- Bloqueada, y copia en "Revisión".
  • Salir de santi y entrar como albert. Mencionar los cambios en la cantidad de patrones que puede o no iniciar y que en ese momento están a la vista.
  • Mostrar el sistema de mensajería y de como queda avisado (notificado) de la necesidad de intervenir en ese expediente con una tarea en concreto: revisar el documento.
  • Acceder al documento desde Mensajes.
  • Visualizar el documento y enviarlo a aprobación.
  • Comentar que el revisor NO DEBE editar el documento por si mismo y que si encuentra algo anormal debe "rechazar" la versión.
  • Explicar que entonces volvería (con notificación incluída al editor.
  • Salir de albert y entrar como joan.
  • Acceso al expediente mediante Mensajes (Notificaiones).
  • Aprobar el documento.
  • Mencionar la "consolidación" en una sóla copia de trabajo.
  • Mostrar (con un usuario con suficientes permisos) todo el login de actividad del documento y el sistema de gestión de versiones.
Práctica 5
Modificar un documento.
Con el fin de que este tipo de acciones que luego se convertirán en actividades frecuentes se repite la práctica anterior, pero ahora simulando que el documento ha sufrido una modificación (puede ser un logo, o un párrafo distinto)
  • Tener preparadas 2 versiones del documento. Mostrar las diferencias entre la que ya está incorporada y la que vamos a "subir".
  • Reemprender la práctica desde el momento en que el editor solicita generar una nueva versión.
  • Modificar ese borrador cargando el documento con el logo o el párrafo cambiado.
  • Enviarlo a Revisión.
  • Entrar como revisor
  • Revisarlo y enviarlo a aprobación.
  • Entrar como aprobador.
  • Aprobarlo y desde un usuario con permisos acceder mostrar el nuevo login de actividad y el cambio en el numeral de la versión/revisión.
  • Acceder a la versión anterior.
Práctica 6
Añadimos una nota.
Cualquier usuario redacta y envia una nota.
  • Mostrar el resultado en Historia.
  • Mostrar el filtro de información propia de la opción.
Práctica 7
Añadimos un e-mail.
Cualquier usuario (santi, albert, joan), aprovechando que ya hay documentos incorporados en el expediente de práctica:
  • Enviar un e-mail a otro participante o a otro contacto.
  • Enviar un e-mail a un expediente o a una tarea KMKey.
Práctica 8
Añadir un documento generado mediante plantilla.
  • Recordamos que ademas de conservar los registros en formato digital, con la información de los mismos podremos generar documentos mediante plantilla y que se pueden incorporar al expediente.
  • Mostrar una NC y generar un Informe/resumen de la misma.
  • Comentar las diferencias entre la información recogida en KMKey y la introducida mediante "Subir Dcocumento".
  • Comentar la posibilidad de generar el informe en distintos formatos.
  • Diferenciar este tipo de documentos de lo que son propiamente los Informes o Listados que obtenemos en el TAB CONTROL
TAB CONTROL
  • Mostrar visualizaciones de Fechas.
  • Informes. Extraer algún ejemplo de informe.
Leer más...
viernes, 8 de mayo de 2009

Mejoras de velocidad (I)

1 comentarios
 
A raiz del planteamiento de migración de instalaciones grandes de KMKey 2 hacia KMKey 3, se detectaron serios problemas de rendimiento de la versión 3 de KMKey cuando se trabaja con elevados volúmenes de datos.

Hemos estado trabajando intensamente para acotar y solucionar estos problemas, y los avances ya son notables, aunque quedan algunos puntos por resolver. Entre las actuaciones más destacadas, y que se verán incorporadas en la próxima versión estable de KMKey 3, se incluyen:

1) La adaptación e integración del ZSQLCatalog de ERP 5, desarrollado por Nexedi. Este catálogo permite reemplazar el catálogo standard de CMF por uno basado en SQL. Se ha tenido que adaptar para que soporte postgresql y para que se integre con AdvancedQuery. Finalmente se ha conseguido implantar en versión beta, y ya son pocos los efectos colaterales que quedan por solucionar. El cambio de rendimiento general es muy notable, y los efectos no desados pocos, teniendo en cuenta que se ha reemplazado parte del núcleo principal de la aplicación

2) Disminución en el consumo de RAM. Había ciertos puntos, como la gestión de documentos, la generación de informes, o las relaciones entre objetos, que elevaban desmesuradamente el consumo de RAM. Estos casos se han ido acotando y corrigiendo, y ahora la RAM disponible puede dedicarse a gestionar cachés de objetos o portlets, con la consiguiente mejora en velocidad

3) Cambio de campos calculados por campos pre grabados. Este punto todavía no se ha abordado, pero se perfila como el siguiente caballo de batalla para conseguir un rendimiento óptimo en instalaciones de elevado volumen de datos. Se trata de cambiar la gestión de campos calculados en ciertos objetos por campos pregrabados, en especial de esos objetos que son consulados constantemente, como tareas o proyectos, porque cuando el volumen de datos aumenta suponen un problema importante

Después de eso vendrán mejoras de rendimiento en pantallas y funcionalidades concretas, pero eso lo dejamos para un segundo capítulo
Leer más...

Introducción a KMKey PROJECT

1 comentarios
 
KMKey PROJECT
Introducción
  • Se supone que el hilo de la explicación/exposición, se reprende de distinta forma si explicamos Project, Quality o HelpDesk.
  • Creación de un expediente/proyecto nuevo.
TAB DEFINICIÓN
  • Rellenar campos. Campos obligatorios.
  • Mostrar el expediente/proyecto creado.
  • Desplegar las agrupaciones.
  • Uso de Modificar.
  • Ver Datos. Borrar.
TAB EQUIPO
  • Explicar diferencia entre contacto y usuario.
  • Alta de Contacto.
  • Mostrar lista de contactos.
  • Gestionar Contactos.
  • Explicar Perfiles de aplicación y roles de usuario.
  • Incorporar un usuario al nuevo proyecto.
  • Asignarle Rol.
  • Mostrar Grupos.
  • Explicar distinta naturaleza de Grupos: Clientes, Proveedores, Empresa, Departamento.
  • Grupo de Recursos. Grupo de Permisos.
  • Mostrar los distintos permisos y la posible combinatoria.
  • Explicar las diferencias entre permisos de aplicación, permisos de patrón y permisos de expediente.
TAB PLANIFICAR
Opciones (Acciones)
Añadir Tarea.
  • Seleccionar cualquier agrupación del proyecto creado y añadir una tarea.
  • Explicar las diferencias entre crear tareas o agrupaciones.
  • Buenas prácticas para encadenar Tareas nuevas correctamente numeradas y ordenadas.
Editar Planificación.
  • Seleccionar una agrupación del proyecto recien creado.
  • Mostrar como podemos modificar los datos que se han generado a partir del patrón en sus conceptos básicos:
  • Nombre de Tarea.
  • Orden. Concepto WBS.
  • Responsable.
  • Fecha de Inicio.
  • Fecha de Final.
  • Duración.
  • Esfuerzo.
  • Explicar la edición directa en esta pantalla.
  • Mover Tareas.
  • Desplazamientos positivos.
  • Desplazamientos Negativos.
  • Limitaciones.
Modificar.
Explicar la diferencia (ventajas e inconvenientes) entre editar/modificar las tareas generadas mediante esta opción o mediante “Editar Planificación”. Acceso a Calendario.

Visualizaciones:
Gantt.
  • Explicar el funcionamiento de las “opciones de visualización”.
  • Escala de visualización.
  • Fecha de Inicio.
  • Mostrar para el proyecto recien creado visiones de los histogramas con distintas escalas de visualización.
Fechas.
  • Mostrar la correspondencia de esta pantalla con los datos “patronables” del proyecto. Añadir a la explicación el concepto de: Estado (Activo, Inactivo, etc)
Recursos.
  • Comentar que esta es una de las pocas pantallas de la aplicación donde dentro de una “visualización” podemos interactuar con la aplicación de forma directa.
  • Diferenciar entre el esfuerzo planificado en la definición del patrón, con la Planificación de recursos y la asignación de horas a recursos por tarea.
  • Recordar la importancia de contar con Grupos de recursos y su adscripción a proyectos/expedientes (Equipo).
  • Mostrar las columnas resumen: Periodo / Tarea / Esfuerzo.
  • Explicar los recursos gráficos de alerta (rojo-Verde-Intermitencia) de las desviaciones registradas.
  • Mostrar la diferencia entre la Planificación con vistas por dias (semana) o por semanas (meses).
  • Comentar verbalmente la posibilidad de efectuar asignaciones periódicas.
  • Efectuar una asignación a Cristina (o Enric) en un día planificado (fondo azul).
  • Explicar las diferencias entre la asignación: “Lo antes posible” ó “Durante todo el periodo”.
  • Efectuar una asignación de 20 horas durante toda una semana.
  • Mostrar la distribución.
  • Mostrar los indicadores de sobreasignación de horas por recurso.
Previsiones.
  • Añadir Previsión.
  • Explicar brevemente los Conceptos Contables definibles.
  • Salir de usuario y entrar como manager para mostrarlos.
  • Explicar que son totalmente definibles por el usuario.
  • Explicar que podremos tener más de una previsión ecnonómica para poder realizar comparaciones.
  • Mostrar una Previsión ya efectuada.
  • Insitir en la posibilidad de diferenciar la previsión o en general para todo el proyecto o para tareas en concreto.
  • Editar Previsión.
  • Añadir una linea como ejemplo en la previsión mostrada.
TAB GESTIÓN
Opciones (Acciones)
Iniciar Tarea
  • Recordar la posibilidad de que por patrón, las tareas se inicien automáticamente con el añadido de cualquier píldora o bien, “manualmente”, mediante esta opción. Recordar que las tareas se tienen que abrir, en la fecha que se inician.
Reabrir Tarea
  • Explicar esta posibilidad.
Añadir
Introducir la filosofía de los 4 ejes de desarrollo de todo proyecto:
  • Eje Información
  • Eje Temporal
  • Eje Económico
  • Eje Esfuerzo.
Añadir Documento.
  • Ejemplo de subida de un documento.
  • Explicar la diferencia entre elementos de información que incorporamos con datos externos (documentos externos) y aquellos que podemos generar, con datos recogidos en KMKey, a través de plantillas.
  • Ejemplo de generación de un documento mediante plantilla (mostrar alguna ya efectuado).
  • Explicar el sistema de gestión documental y gestión de versiones incorporado.
  • Hacer un ejercicio de generación de versión. Modificación. Validación de versión.
  • Explicar los estados: bloqueado, borrador, en trabajo.
  • Mostrar el registro de versiones.
Añadir e-mail.
  • Mostrar la posibilidad de enviar e-mails directamente a los participantes incorporados como equipo al proyecto, y de la no necesidad de volver a tener que subir documentos ya incorporados a KMKey si queremos incorporarlos como adjuntos.
  • Mostrar también como enviar e-mails a tareas o proyectos de KMKey. Código de e-mail en DEFINICIÓN.
Añadir Nota.
  • Si no se ha comentado anteriormente insistir entre la vinculación de añadir una nota y notificar (o no) a varios participantes del proyecto.
Añadir Progreso.
  • Explicar el concepto de progreso. Su estimación porcentual y su valoración subjetiva para el gestor del proyecto.
  • Diferenciar entre tarea cerrada (completada y cerrada) o aquellas que pueden estar completadas pero aún no cerradas. (Progreso al 100%)
Añadir Compra.
  • Realizar un ejemplo.
  • Mostrar vinculación con conceptos contables.
Añadir Gasto Personal.
  • Realizar un ejemplo.
Añadir Venta.
  • Realizar un ejemplo.
  • Mostrar vinculación con conceptos contables.
Añadir Imputación de horas.
  • Si estamos con el usuario (enric) y anteriormente en la opción Recursos del TAB Planificar hemos realizado una asignación de esfuerzo a la usuario (cristina) para un dia concreto, es bueno salir de ese usuario, entrar como (cristina), entrar por Mensajes, o Agenda, localizar una asignación en concreto y realizar esa imputación de horas.
  • Mostrar el resultado final en la visualización Historia del TAB Gestión.
  • Mostrar el resultado en Agenda.
Visualizaciones
Historia.
  • Mostrar una tarea que contenga “pildoras” de todo tipo.
  • Mostrar el filtro de píldoras.
  • Efectuar alguna selección y devolver el filtro a su estado anterior.
  • Explicar el significado de los distintos colores utilizados.
  • Ejemplos de “sort” por columnas (ascendente/descendente).
Agenda.
  • Mostrar un día pasado, con el registro de varias actividades, o un día futuro, con la planificación de varias asignaciones.
Documentos.
  • Mostrar la pantalla y su utilidad.
Info Items.
  • Mostrar la pantalla y escoger algún documento, nota o e-mail registrado en la tarea.
Por categoría.
  • Comentar que las categorías son definibles por el usuario.
Mensajes.
  • Recordar el sistema de mensajería interna explicado en sesiones anteriores. Mostrar ejemplos del funcionamiento.

TAB CONTROL
Opciones (Acciones)
Listados
  • Mostrar ejemplos de Listados.

Visualizaciones
Fechas
  • Explicar los códigos de colores y alertas gráficas.
Gantt
  • Explicar las diferencias con la visualización que obtenemos en PLANIFICAR.
Esfuerzo
  • Explicar el funcionamiento del filtro de opciones de visualización. Mostrar ejemplos y alguna comparación Planificado vs. Real.
Economía
  • Explicar el funcionamiento del filtro de opciones de visualización. Mostrar ejemplos y alguna comparación planificado vs. Real.
Semáforos
  • Explicación de los códigos gráficos (Verde, Ámbar y Rojo) y de los tres apartados o visiones del proyecto desde el punto de vista de progreso, esfuerzo y economía.
Leer más...

Formación General en la Aplicación

0 comentarios
 
Introducción al Interface.

Loggin
Explicación de:
  • Usuario
  • Password

Comentarios breves sobre conceptos tales como:
  • Aplicación desarrollada en software libre. 100% web.
  • Usuarios ilimitados y distribuidos.
  • Multiproyecto, multiempresa, multidioma.
  • El nombre de usuario condicionado por los permisos otorgados dispondrá la aplicación para responder de una forma adaptativa.
  • Misma plataforma distintas funcionalidades y accesos.
  • Se avisa que en transcurso de la sesión podremos observar como, entrando a la misma url, con distintos usuarios, la aplicación responderá con más o menos funciones.
Primera Pantalla KMKey
Explicación de la división de la pantalla en tres áreas reconocibles.
  • Cabecera.
  • Navtree.
  • Body.
CABECERA
Parte izquierda
  • Nombre de Usuario y nº de Roles.
  • Comentario sobre concepto de “rol” y la posibilidad para el mismo usuario de intervenir con distintas funcionalidades en diferentes expedientes/proyectos (perfiles).
Parte Central (1)
Mensajes: (Nuevos Mensajes).
  • Comentario sobre el sistema de mensajería interno de KMKey y la posibilidad de que cualquier acción que realizemos no sólo quedará registrada, sino que además podremos notificar a una o varias de las personas de las que intervienen en el expediente/proyecto de la realización de la misma.
  • Comentario sobre la posibilidad que estás notificaciones se realicen, para según que acciones y en función del proyecto/expediente, de forma automatizada.
  • Acceso a la lista de mensajes recibidos. (Disponer de alguno que funcione o no esté desactualizado y mostrar su funcionamiento).
  • Comentario breve sobre los tres sistemas de “notificaciones de KM (e-mail, internas y sms).
Parte Central (2)
SALIR
  • Comentario sobre la buena práctica que representa “terminar” la sesión, al acabar nuestro trabajo con KMKey.
  • Verbalizar la ausencia de temor a perder cualquier tipo de dato.
Parte Derecha
Línea para introducir “BUSQUEDAS” indexadas.
  • Comentario sobre este sistema de búsqueda rápida de información.
  • Mostrar mediante ejemplo su funcionamiento y acceder a las piezas encontradas.
Indicador de Selección(Ojo)
  • Explicar que esta línea siempre nos describirá el objeto que tenemos seleccionado en el navtree.
  • Mostrar algún ejemplo abriendo un expediente/proyecto y seleccionar el raíz o cualquiera de sus tareas o agrupaciones. Sin profundizar en esos conceptos, sólo para ver como la línea cambia el descriptor.
Área de TABS
  • Explicación sobre la división de las funcionalidades de la aplicación mediante su estructuración en 5 + 1 TABS.
  • Si no hemos entrado como manager avisar que existe un sexto TAB (ADMIN).

Introducción a la “metodología” 5 pasos.
Explicación de la división de las funcionalidades de cada TAB en:
  • Opciones de visualización de la información (enmarcadas).
  • Acciones para interactuar con la aplicación.
  • Pasar brevemente por cada uno de los TABS y mostrar visiones y opciones.
  • Insistir en la importancia de la representación en pantalla de la información seleccionada, para preparar el concepto de Body.
Nuevo:
  • Breve introducción al concepto de “patrón de trabajo”.
  • Mostramos que con está acción INICIAMOS uno de esos patrones de trabajo. Cualquiera de los que estén a la vista. Sin profundizar en ese momento.
Filtros:
  • Explicación de la relación entre “patrones en uso” y filtros automáticos por tipo de “patrón”.
  • Mostrar ejemplos de selección sobre expedientes/proyectos ya creados, para preparar la introducción el concepto de “Navtree”.
  • Mostrar la ventana de edición del Filtro.
  • Explicar las funcionalidades y la importancia de acostrumbrarse a las selecciones mediante filtros ad-hoc, y el uso avanzado (potencial) del mismo.
  • Filtro doble; Filtro Proyecto + Filtro Tareas.
  • Usar un filtro que muestre un solo proyecto (como ejemplo mínimo).

NAVTREE
Después de haber seleccionado un solo proyecto, introducir el concepto “Seleccionar Todo” y propiamente el de NAVTREE.
  • Flechas de desplazamiento y ayudas para la navegación.
  • Símbolos “+”, “-” y “­>”.
  • Introducción de la división de los proyectos/expedientes en Tareas y/o Agrupaciones de las mismas.
  • Volver a seleccionar tareas o agrupaciones o cabeceras de expediente/proyecto y mostrar las diferencias de color en el ámbito de lo que está seleccionado y lo que no.Recordar Indicador de Selección (Ojo)
  • Volver a utilizar algún filtro.

BODY
  • Introducción al concepto cartesiano.
  • Reafirmar la explicación con el concepto de fila y columna de una “hoja de cálculo”, siendo el contenido de la fusión (“celda”) equivalente al de BODY.
  • Repasar el cambio de contenido del BODY habiendo dejado seleccionado un sólo objeto y seleccionando primero diferentes TABS, y a continuación (sin cambiar de selección), diferentes opciones de un TAB.
  • Dejar fijada esa selección de opción y TAB, para pasar a seleccionar diferentes objetos y mostrar como la información contenida en el BODY varia en función del objeto, pero no en su naturaleza.

PATRONES
Conceptos Básicos
Definición de patrón
  • Introducción del concepto “patrón” como: “Conjunto de tareas, recursos, sus planificaciones, elementos de información, y flujos de circulación de la misma, susceptibles de ser repetidas, ante cualquier acción que emprendamos en el ámbito de la organización donde queramos aplicar KMKey”.
  • Mostrar ejemplos utilizando los diversos patrones de KMKey Quality o Project.
Conceptos
  • Nombre de Tarea.
  • Responsable.
  • Esfuerzo previsto.
  • Fecha de Inicio, Fecha de Final de tarea.
  • Campos.
  • Mostrar distintos campos de distintos patrones, necesarios para definir el mismo.
  • Enlazarlo con TAB DEFINICIÓN y mostrar un proyecto/expediente con estos datos rellenados.
  • Aprovechar la ocasión para demostrar que los campos de ese patrón pasarán a fromar parte de los criterios seleccionables para la generación de nuevos filtros de usuario.
TAB ADMIN
En este punto, sea cual sea el nivel o la plataforma que interese para la sesión, abandonamos el usuario en el que estemos y entramos en la misma “url” como manager.
  • Mostrar la aparición del nuevo TAB ADMIN.
  • Mostrar la lista de patrones.
  • Mostrar brevemente la estructura XML de la composición de un patrón.
  • Mostrar brevemente cómo se realiza la introducción de los conceptos principales: Nombre de tarea, orden de la secuencia (WBS), fecha de inicio prevista, fecha de fin prevista, duración, esfuerzo previsto y responsable.
  • Mostrar brevemente la composición y distinta naturaleza de los campos que componen la pantalla de DEFINICIÓN.
  • Extender la explicación de aquellas acciones (en general) que son susceptibles de ser “patroneadas” y poder así ganar tiempo en su generación.
  • Mostrar el ejemplo contrario (tareas que tenemos que acondicionar y crear ad-hoc) mediante el uso de un patrón del tipo “Configurable”.
  • Salir del usuario manager y volver a entrar como (santi, enric, eva).
  • En este punto si el propósito de la sesión sigue siendo una visión general, podemos generar un proyecto/expediente con el patrón configurable y seguir con él la explicación básica del funcionamiento de los TABS.
  • Si por el contrario la sesión se va a dedicar a Project, lanzamos un patrón “Contrato” en Project, si es en Quality, elegimos una “NC de Proveedor”, si es en HelpDesk un “Ticket” (Incidencia).
Leer más...
jueves, 7 de mayo de 2009

Mis proyectos bajo control. La solución: KMKey Project

0 comentarios
 

1)La necesidad:

Quedan atrás los momentos en que era suficiente una estructura de “carpetas electrónicas” y una hoja de cálculo para ordenar la información de nuestra empresa. Con la aparición de las redes y de la red de redes el trabajo en entorno colaborativo no solo es una posibilidad si no una necesidad. Si entendemos como “conocimiento” toda la información que nuestra empresa necesita, produce, transmite y almacena para ayudarnos a alcanzar los objetivos previstos, su gestión se convierte en una tarea primordial. Diversas soluciones van apareciendo en el mercado para dar satisfacción a esta necesidad. Nos inundan con siglas y jerga, algunas de ellas se hacen un lugar en el diccionario de los informáticos. ¿Quien no ha oído hablar de ERP, CMS, CRM o de las mas modernas BI, Cloud computing o knowledege management?.

Pero nosotros trabajamos con PROYECTOS y lo que realmente nos importa es: COMO VAN NUESTROS PROYECTOS. Nótese que hablamos en plural: PROYECTOS.


2)La realidad:

¿Cuales son nuestros PROYECTOS?¿La construcción de un edificio?¿Investigación en biología molecular?¿El diseño de un submarino?¿O simplemente, la solicitud de una subvención?

A simple vista se pueden intuir las enormes diferencias a la hora de abordarlos, aunque también podemos vislumbrar que tendrán trazos en común.

Tenemos una primera variable a ponderar: de que tipo de proyectos estamos hablando.

Si se terminará ahí la problemática sería relativamente sencillo dar con una solución que de satisfacción a las diferentes posibilidades. Pero las dificultades en el escenario no han hecho mas que empezar.

¿Lo vas a trabajar solo o en equipo?¿Están los miembros de tu equipo en el mismo lugar físico o distribuidos geográficamente?¿Pertenecen a la misma empresa o a varias?¿Todos utilizan el mismo idioma?¿Van a tener la misma relación con el proyecto o van a jugar diferentes roles?¿Y la frecuencia?¿Trabajaran siempre en el proyecto o muy de vez en cuando?¿Disponen todos de las mismas herramientas informáticas (SO, programarlo etc..)? ¿Nos relacionaremos con otros sistemas?

Nos a surgido otra variable, o para ser mas exactos: diferentes variables que podemos agrupar en una: el entorno y no me refiero al que mentaba Cruyff.

El tema se va volviendo mas complejo. ¿Y si además este entorno no es estable?¿Cambian las condiciones, los participantes, los lugares ..?

¿Con este escenario, seria cuerdo pensar que un solo programa puede dar la mejor respuesta a todas las necesidades?

La respuesta es NO.

Cada caso tiene su mejor respuesta.

3)La solución: KMKey

Conscientes de ello, desde el inicio del proyecto KMKey decidimos centrarnos en dar respuesta a un universo de empresas que pudieran necesitar un Software de Gestión de Proyectos que diera soluciones a necesidades reales. Cuando la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de los E.E.U.U., como parte del proyecto, Polaris creo el sistema PERT, seguro que le fue de mucha utilidad. Probablemente a una empresa que quiera gestionar una promoción de viviendas unifamiliares no le sirva para nada.

Mas allá de como trabajan los programas que pretenden convertirse en standards, definimos las características que debía ofrecer nuestra solución:


3.1)Características principales:

  • Libre

    Tanto KMKey com el software base utilizado en su instalación siguen los preceptos del software libre (Open Source Software). Se distribuye bajo licencia GPL. En resumen, estamos hablando de una aplicación cuyas fuentes se entregan al cliente, no se cobra por licencia y se puede modificar el código siempre que no se revenda cobrando. Esto nos garantiza el total acceso al programa y nos da independencia del proveedor ya que en caso necesario podemos actuar modificando hasta la última linea del programa.

  • Adaptable

    Exceptuando los principios básicos de usabilidad con los que funciona KMKey, la solución se puede adaptar a las necesidades del cliente mediante configuración. Los proyectos pueden seguir una metodología de trabajo pre-configurada en tantos Patrones de trabajo como sea necesario. Entendemos como Patrón de trabajo el procedimiento que utilizaremos para abordar un tipo de proyecto. Pero no solo la distribución de tareas, sino los perfiles que lo trabajaran con sus permisos, los conceptos contables a utilizar, los documentos que podremos generar desde el expediente, las notificaciones y avisos etc..
    Es decir, una vez decidido como vamos a enfocar la gestión de un tipo de proyectos de terminados lo reflejamos en un patrón que utilizaremos cada vez que nos enfrentemos a un proyecto de este tipo.
    Obviamente, una vez generado el expediente del proyecto si este no responde exactamente a como se ha diseñado el patrón, se pueden introducir cambios para adaptarlo a la realidad.

  • Integrable

    Es muy probable que KMKey no sea el único programa o sistema que use la empresa. Posiblemente puede darse la necesidad de compartir datos con otras aplicaciones. KMKey se puede enlazar de diferentes formas para compartir la información y en la actualidad lo está realizando con ERPs, CRMs sistemas de autentificación, BBDD etc..

    También es posible intercambiar información con otras soluciones de gestión de proyectos como MS Project.

  • Usuarios ilimitados

    KMKey no tiene restricciones en cuanto al número de usuarios. Ni usuarios contratados, ni concurrentes, ni módulos, ni nada.. Sencillamente lo pueden utilizar tantas personas como les facilitemos un usuario. Las únicas restricciones vienen por la capacidad del servidor de dar respuesta a las peticiones, sean estas de pocos usuarios muy activos o de muchos que lo utilizan de vez en cuando.

  • Multiproyecto

    La realidad nos indica que son pocas las empresas que acometen un solo proyecto. Lo normal es que tanto empresas como usuarios estén involucrados en muchos proyectos que deben ser gestionados al mismo tiempo. KMKey asume en sus funcionalidades esta premisa y está pensado para dar respuesta a la gestión y control de multitud de proyectos simultáneos.

  • Multiempresa

    Multigrupo, sería la palabra correcta. Las personas se asocian en grupos. Estos pueden ser empresas, sedes, departamentos etc.. los componentes de uno de ellos pueden ver una serie de proyectos y los de otro grupo, otra serie totalmente diferente. La información está compartimentada según los permisos que se otorguen.

  • Multi idioma

    Cada usuario puede escoger el idioma de trabajo en KMKey. También, configurando correctamente, se puede escoger el idioma de trabajo de un proyecto en concreto incluyendo documentos generados automáticamente e informes.

  • 100% Web

    KMKey está pensado desde el primer momento y la primera línea para ser una aplicación totalmente Web. Es decir, se puede utilizar desde cualquier punto del globo que tenga un acceso a Internet y un navegador (Firefox o Iexplorer). Esto nos permite trabajar de una misma forma independientemente de donde nos encontremos, tanto el director de proyecto com el administrador del sistema, el técnico o el comercial.

3.2)Ejes de trabajo:

La características anteriormente expuestas nos garantizan el adecuado entorno de trabajo. Por si solo no sería suficiente si la aplicación no estuviera correctamente estructurada y fuera intuitiva y de fácil uso. De las multiples teorías de gestión de proyectos escogemos y adaptamos varios conceptos para ordenar la información de una forma lógica y comprensible. Esto nos permite planificar, gestionar y controlar los proyectos en sus cuatro ejes principales: tiempo, esfuerzo, economía e información.

  • -Tiempo

    El proyecto, subdividido en tareas y agrupaciones de tareas se puede planificar en el tiempo. Asignar fechas previstas de inicio y fin, duraciones, contingencias etc... Una vez en marcha el proyecto se introducirán las fechas reales en las que se realizan las tareas. La comparativa entre ambas nos darán idea de la marcha del proyecto, sus posibles retrasos etc.. Podremos visualizar el avance cronológico mediante gráficos Gantt, tablas de fechas, agendas..

  • -Esfuerzo

    A cada tarea se puede asignar un esfuerzo previsto en horas/hombre. Los diferentes usuarios a medida que van trabajando, introducen las horas que han invertido en sus intervenciones. Estas horas, que pueden ser de diferentes tipos, nos sirven para valorar los recursos empleados en el proyecto y su coste asociado.

  • -Economía

    KMKey permite definir unos conceptos contables donde estructurar la economía de los proyectos. Establecer unas previsiones según estas estructuras y una vez imputadas las entradas económicas reales establecer comparativas. También dispone de facilidades para la generación de ofertas, facturas, gastos personales etc.

  • -Información

    Los tres primeros conceptos son los habituales en las teorías, nosotros añadimos uno nuevo: relacionar una base de datos del conocimiento al proyecto. Lo diseñamos mediante la facilidad de añadir “píldoras de información” en las tareas. Entendemos como píldoras unidades de información en cualquier formato: archivos, documentos, correos electrónicos, notas, mensajes .. La información que contienen es indexada de tal manera que se puede consultar con una búsqueda tipo “Google”.


3.3)Modelos:

¿Como podremos disponer de KMKey? Teniendo claro que su uso es siempre a través de un navegador, su instalación se puede realizar mediante tres vías principales.

  • -Juan Palomo

    Si somos usuarios avezados en programador libre o nos gusta la informática “bricolaje” nos podemos arremangar las mangas de la camisa y visitar www.kmkey.org para hacer nuestra propia instalación. Apoyados por usuarios con mas experiencia en listas de correo, podremos paso a paso disponer de KMKey en el servidor que hayamos escogido a tal efecto.

  • -SaaS

    El Software as a Service (software como servicio, alias ASP, alias Cloud Computing) se impone día a día como una solución válida en las empresas. Sobretodo en aquellas distribuidas, con usuarios móviles, colaboradores externos etc. De forma muy resumida, podemos definirla como: alquilamos un proveedor (típicamente un ISP) que se encargue de todo (espacio en disco, comunicaciones, seguridad, copias..) y nosotros pagamos una mensualidad y nos olvidamos del tema

  • -Home

    Para aquellas empresas con gerentes mas “tradicionales”, la instalación se puede realizar en un servidor en las dependencias del cliente. Ya sea Linux o Windows, en este caso, aplicación y datos residen en la propia empresa. Su acceso externo a través de Internet puede ser activado a conveniencia según la configuración de los dispositivos de comunicación.


Hemos presentado, de forma my somera, una solución que puede ser útil a la mayoría de empresas que gestionan proyectos en un entorno colaborativo de trabajo. Es la combinación de todas las características presentadas lo que dan una ventaja competitiva frente a otras soluciones enfocadas de una forma mas sectorial o pensadas para un solo individuo o proyecto. El objetivo principal es dotar de una herramienta útil y eficaz. Dar la posibilidad de tener una rápida respuesta a mano cuando nos pregunten: ¿como van los proyectos?


Leer más...