miércoles, 12 de diciembre de 2012

Saving Money with Software Quality Assurance (SQA) Part 2

This is the second part of an article written by Hernan Gil


cost analysis


Implementing some or all of the activities described in the previous article, takes time, effort and undoubtedly money. For that reason, it is necessary to analyze the ROI of this deployment, for which we will base on a study that analyzes the traditional stages of a project, and introduced defects , found defects and the cost of repair. As can be seen, the introduction of 85% of the defects of the application occurs at the beginning of the construction phase, but these defects are encountered gradually in subsequent stages.

The longer it takes to find a mistake, the more costly repair. Therefore it is proposed to establish activities that accompany the development process (instead of control points) to maximize the detection of defects in each stage, and to minimize the number and impact of the defects found in the final stages. It is important to try to estimate the cost of a defect found during testing versus find after putting into production, as the cost associated with the latter not only occurs to generate a new version, but also adds the regression test, the new production start and the time the system is offline.

¿where do we start?

Implementing all SQA activities simultaneously is costly and impractical. It is best to start with the activities in which they see results more quickly and effectively.
In addition, a phased implementation and fed help make the process smoother and more easily accepted. If you are in the initial stages of the project, should begin with the requirements verification and validation of architecture, while if it is already advanced, it is better to revise the design or directly take a look at the code.


UP Phases and disciplines: relation with SQA Activities.


Quality metrics

The only way to show what are the benefits of SQA activities is through metrics that reflect the evolution of the development process. If we can not measure improvements, we can not evaluate the effectiveness of SQA process and will not be possible to be improved. Examples of such metrics may include:

  • Number of incidents reported in production.
  • Number of incidents reported in testing.
  • Number of cycles of testing / rework required.
  • Time to make a change (categorized by impact).



SQA is a set of activities that aim to lower the cost of development to meet the established quality parameters.
It is feasible to achieve certain quality and cost, but you must know that it is possible to insert desired quality at the end of the development process, but must be created throughout the process. The sooner you start with SQA activities, the greater the benefits.


At Baufest we use to apply such practices using , on different phases, tools like:

  • Rational Quality Manager
  • Rational Functional Tester
  • Rational Performance Tester
  • Microsoft Visual Studio Team Foundation Server
  • Microsoft Project Server and Nintex workflows for Microsoft Project Server
  • Microsoft Sharepoint

Thanks to Nadia Cavalleri for collaboration in this article.

martes, 11 de diciembre de 2012

Productos & Innovaciones para SharePoint 2013


¿Cuáles son los planes de Nintex 2013?

Más que tener planes, ya están listos ahora. En la Conferencia de SharePoint se presentaron las versiones para 2013 de Nintex Workflow, Nintex Foms y Nintex Workflow para Project Server. Los clientes con planes iniciales para la transición a SharePoint 2013 pueden seguir adelante con sus inversiones en productos Nintex-ahora. Van a seguir una cadencia regular de mejoras e innovaciones continuas a lo largo de 2013, con inversiones avanzados en mobile, social, y en la nube.

¿Cómo aprovechará Nintex mobile, social, y la nube?

La generación 2013 de productos Nintex facultará a las organizaciones extender la automatización de procesos de negocio a más personas, lugares y dispositivos, continuando con la visión de ofrecer Nintex "para todo el mundo". Puede extender los workflows para la fuerza de trabajo mobile, utilizar las herramientas sociales para reinventar los procesos de negocio y de apoyo alojados en la nube de servicios.

¿Cómo se trabaja con Nintex y Yammer?

Se estan haciendo workflows sociales ya está integrado con Yammer, Twitter y Facebook, la plataforma de workflows Nintex seguirá añadiendo conectividad y capacidades de aprovisionamiento a las herramientas y servicios sociales. Extendemos los procesos a donde las personas trabajan realmente. Los usuarios pueden descubrir procesos y participar en tareas directamente en canales de medios sociales y feeds sociales de Sharepoint.

¿Cuáles son los plazos para desarrollar este primer lanzamiento para el 2013?

Para primera versión son:
 Nintex Workflow 2013 estará disponible a la venta en diciembre de 2012
 Nintex Forms 2013 estará disponible a la venta en enero de 2013
 Nintex Workflow para Project Server estará disponible en Q1 CY 2013
 Aplicaciones Nintex para Windows 8, iPhone y iPad estará disponible en Q1 CY 2013

¿Que es Nintex Workflow Online (Preview)?

Se trata de una aplicación para SharePoint Online, en la tienda de Office. Nintex Workflow Online (Preview) ofrece a los usuarios la capacidad de diseñar y ejecutar flujos de trabajo en SharePoint Online, arrastrar y soltar las acciones nativas de SharePoint y la conexión a los servicios de nube a través de Nintex Live. Esto da una idea de cómo Nintex Workflow en línea se hará que Office 365 sea más productivo, automatizando todo, desde las revisiones y aprobaciones, a los procesos de negocio complejos.

Si necesitas una demo de este producto contactanos en Baufest

viernes, 30 de noviembre de 2012

Saving Money with Software Quality Assurance (SQA)

This is the first part of an article written by Hernan Gil

In this article we will see what is Software Quality Assurance (SQA), what are the economic benefits of its implementation and how it takes part on the early stages of the development process.
The main objective of implementations of the SQA discipline is to increase the quality of deliverables throughout the development process. Many quality requirements, especially those having to do with the performance, usability, load, availability, etc.. - Can be treated as hazards. That is, the fact that one of them is not met implies a risk.
Then, ensuring quality of software during its process, reduce risks and increase the predictability of software development. This brings with it a wide range of benefits of visibility. Among those that stand out, we can name:

  • Reduced development time, mainly generated rework time in the testing phase.
  • Optimizing the use of resources, reducing the cost of the infrastructure required to support the application.
  • Maintenance cost reduction, as they generate more stable and secure applications.
  • Increased change permeability and ease to measure its impact.
  • Compliance requirements, both functional as quality.
  • Tracking the defined standards.
  • Provides information about the quality of the project to the stake holders who have less technical knowledge.
  • Developments become more predictable, which makes estimates easier.
SQA activities in the development process
SQA is a discipline which is composed of a number of activities accompanying development process. The objective of this work is to enhance, manage, and monitor the quality of the built deliverables.
UP phases and disciplines

To identify these activities and the right time to perform them , it is necessary to review the life cycle of a project. For this we rely on the analysis of phases / disciplines / effort in UP, it is a process widely used in the market, however, the same analysis can be applied to other development processes. Analyzing the Phases diagram, we realize that the effort of each discipline varies by project phase.
From this it follows that the time to control the quality of each discipline is when more effort is devoted.
In healthy SQA initiatives, the impact of this should be reflected in all the artifacts that are generated in the development process. It should not be limited to testing or functional verification, which is a fairly widespread sense of SQA function, but diametrically misguided.
In a broader perspective SQA synergistic role in a development project, we find, among others, the following activities:
  • Requirements verification:  Aims to demonstrate that the definition of the requirements actually define the system that the user needs or the customer wants.
  • Validation and verification of requirements: They aim to show that the specification of the requirements actually define the application that user needs or the customer wants and that the system meets these needs.
  • Evaluate the architecture: It 's a very important activity to assess the feasibility of meeting non-functional requirements and early detection of the major risks associated with the project.
  • Design Control: It focuses on validate the logical design of the components, their distribution and interaction, to identify components which may be reusable, and the scope of the defined quality requirements of each.
  • Source Control: It is divided into two activities:
    • Static Control Code: The validation of the code against a set of rules, best practices and predefined standards.
    • Dynamic control code: Control focuses on the use of resources and the application does the coverage of code making unit tests.
  • Functional Testing: This is done near the end of the development stage, and is responsible for monitoring compliance with the functional requirements of the system and to detect errors more visible to the user.
  • Stress Test: Focuses on assessing the performance of the application for the simulation of peak activity times.
Previous Tasks

It is necessary to note that, for some of these activities, you first have to perform other, such as:
- Definition of standards and best practices development.
- Choice of tools to document and develop.
- Other
Performing these tasks is justified by the mere fact that, in order to validate the quality of any process, it is necessary to have, previously, the definition, requirement or standard against which to validate.

In the second article we explore the following topics: Analysis of costs, where do we start?, Quality metrics and Conclusions

Fernando Hunth

Economizar con Software Quality Assurance: Parte II

Parte II, por Hernan Gil

Análisis de costos
Implementar alguna o todas las actividades descriptas en la entrega anterior, implica tiempo, esfuerzo y, sin dudas, dinero. Por esa razón, es necesario analizar el ROI de esta implementación, para lo cual nos basaremos en un estudio que analiza las etapas de un proyecto tradicional, y los defectos introducidos, los encontrados y el costo de su reparación. Como se puede apreciar, la introducción del 85% de los defectos de la aplicación se produce al inicio de la etapa de construcción, pero estos defectos se van encontrando paulatinamente, en etapas posteriores.
Mientras más se demore en encontrar un error, más costoso será repararlo. Por eso se propone establecer actividades que acompañen al proceso de desarrollo (en vez de puntos de control), para maximizar la detección de defectos en cada etapa, y minimizar la cantidad y el impacto de los defectos que se encuentran en las etapas finales. Es importante tratar de calcular el costo de un defecto encontrado durante el testing versus encontrarlo luego de la puesta en producción, ya que el costo asociado a este último no es sólo el que se produce al generar una nueva versión, sino que también se le suma el del test de regresión, la nueva puesta en producción y el tiempo que esté bajo el sistema.

¿Por dónde empezamos?
Implementar todas las actividades de SQA al mismo tiempo es costoso e impráctico. Es mejor empezar por las actividades en las que se vean resultados de forma más rápida y efectiva.
Además, una implementación paulatina y retroalimentada ayudará a que el proceso sea más armonioso y fácilmente aceptado. Si se está en las etapas iniciales del proyecto, conviene empezar por la verificación de requerimientos y la validación de arquitectura, mientras que si ya se está avanzado, es mejor revisar el diseño o, directamente, el código.

Fases y disciplinas de UP: relación con las actividades de SQA.

Métricas de calidad
La única manera de mostrar cuáles son los beneficios que aportan las actividades de SQA es a través de métricas que reflejen la evolución del proceso de desarrollo. Si no podemos medir las mejoras, no podremos evaluar la efectividad del proceso de SQA y tampoco será posible mejorarlo. Ejemplos de este tipo de métricas podrían ser:

  • Número de incidencias reportadas en producción.
  • Número de incidencias reportadas en testing.
  • Cantidad de ciclos de testing/retrabajo necesarios.
  • Tiempo necesario para realizar un cambio (categorizado por impacto).

SQA es un conjunto de actividades que tienen como objetivo bajar el costo de desarrollo para alcanzar los parámetros de calidad establecidos.
Es factible alcanzar calidades y costos determinados, pero es necesario saber que no es posible insertar calidad deseada al final del proceso de desarrollo, sino que se debe crear a lo largo de todo el proceso. Cuanto antes se comience con las actividades de SQA, mayores serán los beneficios obtenidos.

viernes, 23 de noviembre de 2012

Economizar con Software Quality Assurance: Parte I

Economizar con Software Quality Assurance: Parte I, por Hernan Gil

En el presente artículo veremos qué es Software Quality Assurance (SQA), cuáles son los beneficios económicos de su implementación y cómo interviene en las etapas del proceso de desarrollo.

La implementación de una disciplina de SQA tiene como principal objetivo aumentar la calidad de los entregables durante todo el proceso de desarrollo. Muchos requerimientos de calidad –sobre todo, aquellos que tienen que ver con la performance, la usabilidad, la carga, la disponibilidad, etc. – pueden ser tratados como riesgos. Es decir que el hecho de que uno de ellos no se cumpla implica un peligro.
Entonces, al asegurar la calidad del software durante su proceso, se disminuyen los riesgos asociados y se aumenta la predictibilidad del desarrollo de software. Esto trae aparejada una serie de beneficios de variada visibilidad. Entre los que más se destacan, podemos nombrar:

  • Reducción de los tiempos de desarrollo, principalmente, el tiempo de retrabajo generado en la fase de testing.
  • Optimización del uso de los recursos, que disminuye el costo de la infraestructura necesaria para soportar la aplicación.
  • Disminución del costo de mantenimiento, ya que se generan aplicaciones más seguras y estables.
  • Aumento de la permeabilidad al cambio y facilidad para medir su impacto.
  • Cumplimiento de los requerimientos, tanto los funcionales como los de calidad.
  • Seguimiento de los estándares definidos.
  • Provee información sobre la calidad del proyecto a los stake holders que tienen menor conocimiento técnico.
  • Los desarrollos se vuelven más predecibles, lo cual facilita las estimaciones.

Actividades de SQA en el proceso de desarrollo

SQA es una disciplina que está compuesta por una serie de actividades que acompañan al proceso de desarrollo. El objetivo de estas tareas es aumentar, administrar y monitorizar la calidad de los entregables producidos.

Fases y disciplinas de UP

Para identificar estas actividades y el momento oportuno para realizarlas, es necesario revisar el ciclo de vida de un proyecto. Para esto nos basamos en el análisis de fases/disciplinas/esfuerzo realizado en UP, porque es un proceso muy difundido en el mercado; sin embargo, el mismo análisis puede aplicarse a otros procesos de desarrollo. Analizando el diagrama de Fases, notamos que el esfuerzo de cada disciplina varía según la fase del proyecto.
De aquí se deriva que el momento para controlar la calidad de cada disciplina es cuando mayor esfuerzo se le dedica.
En iniciativas de SQA saludables, el impacto de ésta debería verse reflejado en todos los artefactos que se generan en el proceso de desarrollo. No debería limitarse sólo al testing o verificación funcional, lo cual es una acepción bastante difundida de la función de SQA, pero diametralmente desacertada.

En una perspectiva más amplia del rol sinérgico de SQA en un proyecto de desarrollo, podemos encontrar, entre otras, las siguientes actividades:

  • Verificación de requerimientos: Tiene como objetivo demostrar que la definición de los requerimientos definen realmente el sistema que el usuario necesita o el cliente desea.
  • Validación y verificación de requerimientos: Tienen como objetivo demostrar que la especificación de los requerimientos definen realmente el sistema que el usuario necesita o el cliente desea y que el sistema satisface dichas necesidades.
  • Evaluar la arquitectura: Es una actividad muy importante para evaluar la factibilidad de cumplir con los requerimientos no funcionales y detectar de forma temprana los principales riesgos asociados al proyecto.
  • Control de diseño: Se enfoca en validar el diseño lógico de los componentes, su distribución e interacción; en identificar componentes que puedan ser reutilizables, y en el alcance de los requerimientos de calidad definidos por parte de cada uno de ellos.
  • Control de código: Se subdivide en dos actividades:
    • Control estático del código: Es la validación del código contra un conjunto de reglas, best practices y estándares predefinidos.
    • Control dinámico del código: El control se focaliza en el uso de los recursos que hace la aplicación y la cobertura del código que hacen los tests unitarios.
  • Testing Funcional: Se realiza cerca del final de la etapa de desarrollo, y se encarga de controlar el cumplimiento de los requerimientos funcionales de sistema y de detectar los errores de mayor visibilidad para el usuario.
  • Test de stress: Se enfoca en evaluar el desempeño de la aplicación durante la simulación de momentos pico de actividad.

Tareas previas
Es necesario tener en cuenta que, para realizar algunas de estas actividades, primero hay que realizar otras, como las siguientes:
- Definición de estándares y best practices de desarrollo.
- Elección de herramientas para documentar y desarrollar.
- Otras
La realización de estas tareas se justifica por el solo hecho de que, para poder validar la calidad de cualquier proceso, es necesario contar, previamente, con la definición, requerimiento o estándar contra el cual validar.
En la segunda entrega veremos los siguientes temas: Análisis de costos, ¿Por dónde empezamos?, Métricas de calidad y Conclusiones

lunes, 15 de octubre de 2012

Formularios de SharePoint para todos y en cualquier dispositivo



Formularios de SharePoint para todos y en cualquier dispositivo

Nintex Forms 2010 es un diseñador basado en la web que permite crear formularios en SharePoint de forma rápida y sencilla. Después puede emplear dichos formularios en la mayor parte de los dispositivos móviles a través de internet, esté donde esté y en cualquier momento. Nintex Forms se integra a la perfección con Nintex Workflow con el fin de automatizar los procesos comerciales y de proporcionar sofisticadas aplicaciones de SharePoint.





  • Es accesible para los usuarios
    comerciales y potente para los
  • Diseñador basado en navegadores
    de internet incorporado a
  • Intuitiva y fácil interfaz de arrastrar
    y colocar
  • Realice un solo diseño y aplíquelo
    a muchos dispositivos



  • Facilita el acceso móvil a formularios
    de SharePoint
  • Optimizado para los dispositivos
    móviles más comunes
  • Soporte tanto para formularios
    autenticados como anónimos
  • Publique formularios en internet
    de un solo clic


Se integra plenamente con Nintex Workflow y SharePoint
 Transforme formularios en sofisticadas aplicaciones comerciales
 Combine un formulario y un flujo de trabajo para crear un paquete distribuible
 Conecte formularios a los servicios de la nube, incluido Office 365*
* Requiere Nintex Live y Nintex Workflow

Descargue una versión de prueba gratuita en www.nintex.com/forms
Más información en: www.nintex.com | Consultas: sales@nintex.com
© Copyright 2011 Nintex USA LLC. Todos los nombres de productos y empresas aquí mencionados pueden ser marcas de sus respectivos propietarios registrados.



Nintex Forms 2010 está basado en navegadores de internet, y plenamente incorporado a los SharePoint ribbons , sin que sea necesario instalar ni obtener licencias de otros software clientes. Puede diseñar estéticos formularios con imágenes de fondo, botones personalizados y formato
HTML enriquecido.
Sírvase de diseños de dispositivos predeterminados, o cree sus propios diseños para el tamaño de pantalla que sea; antes de publicar el formulario podrá visualizarlo en distintos dispositivos.



Combine Nintex Forms con Nintex Workflow 2010 para transformar los flujos de trabajo en sofisticadas aplicaciones comerciales. Nintex Forms genera de forma automática los elementos necesarios para crear formularios de Nintex Workflow, y permite utilizar las variables de flujo
de trabajo como si fuesen datos del formulario.
Para obtener más información sobre Nintex Workflow, visite www.nintex.com/workflow



Publique formularios en la nube de un solo clic, sin tener que disponer de otros hardwares, softwares ni configurar infraestructuras.
Después, cualquier persona con conexión a internet que esté fuera de la red corporativa podrá acceder a los formularios.


Descargue una versión de prueba gratuita en www.nintex.com/forms o solicite una demo del producto a marketing@baufest.com

martes, 9 de octubre de 2012

Mi editor de contenidos Sharepoint dejó la compañía


clip_image001Es importante mantener el contenido actualizado. Pero ¿qué sucede cuando se va un gestor de contenidos? Se debe pensar como si la persona, a la mañana siguiente hace una llamada y dice que nunca volverá a la compañía y que ayer fue su último día. Adiós!

El contenido siempre es importante, por lo que la gestión de la misma debe insertarse en los procesos cotidianos, y ser parte del traspaso. Pero la realidad a veces es diferente, por ejemplo, un lapso de tiempo entre la persona que se fue y otra que va a venir.



Algunas sugerencias

Aquí hay algunas sugerencias:

· Siempre nombrar una persona “backup” para cualquier gestor de contenidos, para cubrir vacaciones, enfermedad, maternidad o paternidad, períodos ocupados, etc.. Lo ideal sería que un gestor de contenidos tenga un asistente que conozca todas las tareas de administración de contenido.

· Escribir las tareas delimitadas para un gestor de contenidos para crear instrucciones para administrar el contenido. Esto le ayudará a obtener rápidamente en poco tiempo y aliviar su equipo de la intranet/sitio o aplicación. Mientras su equipo de Gestión del Conocimiento fácilmente puede entrenar a una nueva persona en administración de contenido general, no sabrán los procesos específicos o acuerdos o acceso etc.

Como cualquier sitio donde se está administrando contenido, tienes un sponsor para ese sitio y que conoce a metas y objetivos para ello. En ese sitio debe existir una buena guía, archivos de ayuda, formación guías, preguntas frecuentes, referentes, políticas, etc..

También es esencial un plan de comunicación, cada mes o el período que se utiliza , para publicar cambios en su sitio.

Los puntos siguientes mitigarán el riesgo. Especialmente, teniendo en cuenta el período de publicación, necesitaras que en ese periodo, el contenido listo para mantener el flujo de trabajo que ejecutan y adoptar medidas.


etapas tempranas

Todos estos elementos son fundamentales a nuestra vista en las primeras fases.

Un plan es necesario para que el contenido esté listo para su publicación, así como tener una idea de quién debe ser responsable de ciertas partes de su contenido.
Es ideal que cuando el nuevo usuario inicia su trabajo, pueda tener asignada la función/rol automáticamente obteniendo los mismos derechos, como su predecesor. La idea es que el gestor de contenidos sea un rol específico y no específico al empleado.
Esto podría ser construido como detalles en los contratos de trabajo (si su organización le gustan los contratos detallados), o de otra manera formalmente documentar, en un sitio de Content Management, "Roles y Responsabilidades de gestión de contenidos" o un sitio de Gestión del Conocimiento avanzado. Si lo hace, podría asignar, a nivel organizativo, a qué contenido pertenece a cada función, que tiene beneficios más allá de simplemente saber qué usuario hace que cosa.
Sería ideal contar con un mapa de los contenidos y la jerarquía de roles.


Ejemplo de la vida real

Trabajé con áreas de normas y procedimientos para delinear responsabilidades de contenido para trabajos específicos en las diferentes áreas hace algún tiempo. Sólo sabían de las responsabilidades sobre sus zonas conocidas. Se sabe que las personas se adaptan mejor (con una mentalidad técnica o más comprometida...) que otros, así que era también necesario crear un documento de 'roles y responsabilidades' para quienes deseen convertirse en un editor.

Por lo tanto, cuando aparece un nuevo equipo o futuro 'editor' que desarrollará el contenido, reciben una respuesta inicial, incluyendo a su manager, indicando lo que se espera en ese papel, que se examinará en un año, nuestro proceso de revisión de contenido y las tareas se incluirán, en su evaluación anual del desempeño, como sus objetivos. Es necesario asegurarse que cubrirá el papel como editor y posteriormente se entrenará para usar el sitio de administración de contenido. Es un buen procedimiento a seguir, porque todo el mundo tiene claro lo que se espera sin sorpresas.}

A veces es una tarea costosa pero muy fructífera al final.



Una vez que este esquema comienza a trabajar podrías coordinar una auditoría de contenido cada algunos meses como respuesta a la mejora continua. Ese proceso podría implicar cada página del sitio que es confirmado como precisa y actualizada, registrando las páginas sin atención. El registro de los resultados también son buenas notas para futuros editores.

En ese proceso podrías utilizar un flujo de trabajo cuando se inicia la revisión. Puede asignar un montón de páginas o sitios (según el tamaño del contenido) a distintos editores.

A cada uno de ellos se les presenta resultados identificando su contenido. También al lado de cada contenido se podría confirmar, que cada uno de ellos ha revisado y aprobado o no aprobado o delegado la tarea a un administrador o las funcionalidades que necesitas.

Finalmente se notifica a un manager que se ha producido la auditoría. El avance de la auditoría también forma parte de mis informes trimestrales a la Junta de Gobierno del sitio Web /aplicación o proceso bajo el título de «Fiabilidad de contenido».

Finalmente se podría hacer un montón de informes y estadísticas con información recopilada durante el proceso.

Además el administrador podría recibir una alerta cuando Recursos Humanos actualiza el perfil del usuario perfil cuando la persona se va y comenzar con un proceso de reasignación para el contenido que quedó huérfano de revisores. Con el fin de mantener el contenido actualizado, es posible agregar metatags a cada contenido de la página con un máximo (el periodo que desees) desde fecha de creación de la página. Cada mes/semana todos los propietarios de contenido reciben una notificación automatizada con todo el contenido debido a punto de caducar próximamente, y cualquiera que ha vencido en la última semana.

Además el flujo de trabajo podría presentar una página con el titulo del contenido del título para darle una comprobación rápida para realizar una actualización masiva, o si debe ser retirado. Finalmente podría crear un informe de páginas caducadas y actualizadas. Esto tiende a mantener nuestro contenido actualizado, pero también ayuda a ver si alguien no se mantiene al día con sus responsabilidades.


ESTADISTICAS, ANALYTICS , reportes y Business Intelligence

Un paquete de Reporting/BI debe cubrir esa inteligencia de flujo de trabajo. La presentación de informes debe decir qué contenidos han caducado y dar un desglose de quién es el propietario. También debe obtener contenido huérfano y administrar el nuevo propietario. De esos informes, podrá obtener stats en una hoja de cálculo de contenidos y administradores.


un sitio de gestion del conocimiento

Con el fin de tener objetivos y metas definidas para funciones de administración de contenido, es necesario tener claro un Roadmap de los roles de gestión del contenido. También se necesita, por ejemplo en un sitio de procesos digitales, una página con buenos manuales para usuarios, documentación de procesos, formularios, proyectos, tareas, entregas y un blog donde personas podrían hablar de esos temas para mejoras continuas. Por lo tanto cualquier usuario que reemplaza a otro usuario podría tener toda la información.

Si esto es implementado en toda la empresa evitará la resistencia de los primeros usuarios y esas situaciones podrían ser administradas y supervisadas. Ese tipo de información es clave no sólo para trabajar en proyectos de entrega sino también para las operaciones diarias. Un empleado debe ser evaluado en lo bien que administra esa responsabilidad. Su fundamental transferir conocimientos y también es muy útil para una persona dejando vacíos en una organización después de su salida.

Para cada tema cubierto en las secciones de este articulo se puede escribir un mondo de cosas, pero estoy seguro que ayudarán a comenzar a revisar como se esta manejando el contenido en tu compañía.

plataformas recomendadas

En Baufest solemos construir algunas soluciones para estos problemas basándonos en:

  • Sharepoint
  • Nintex Workflows
  • Nintex Analytics o Reporting Services



Si te gustaría ver una demo de alguno de estos productos contáctanos.

Nos vemos.

Fernando Hunth

viernes, 5 de octubre de 2012

Sabemos como hacer que Dynamics brinde mayores beneficios


Baufest Dynamics CRM

Baufest Dynamics CRMBaufest Dynamics CRM

Conozca más acerca de
Nuestros servicios.

Click el icono para descargar el brochure.

Bajar brochure

Le ofrecemos 8 horas de consultoría para que conozca nuevos beneficios de la plataforma Dynamics CRM. Evaluamos su situación actual y le proponemos acciones concretas. Ingrese aquí.

Business Services for Dynamics CRM

Servicio de Consultoría

Sabemos cual es la información necesaria para desarrollar un Business Case.

Servicio de Implementación ágil

Contamos con una metodología propia que asegura la adopción exitosa de la plataforma en su organización.

Servicio de Mantenimiento y Operación

Ayudamos la continuidad de los procesos comerciales de su negocio, resolviendo las necesidades de los usuarios y asegurando la disponibilidad de la plataforma Dynamics CRM.

El índice de satisfacción de nuestros Clientes es superior al 91%. Te invitamos a conocer como lo hacemos posible

Web Baufest

martes, 25 de septiembre de 2012

My Sharepoint content manager has left the company




ContentManagerIt's important to keep content up-to-date. But what does it happen when a content manager leaves?

It should be thought as if the person working in the company tomorow makes a call and says that he/she will never come to company, and that yesterday was his/her last day. Goodbye!

Content is always important, so the management of it should be embedded in day-to-day processes, and be part of hand-over. But reality is sometimes different, e.g. a gap between one person leaving and the next one coming.



Some suggestions

Here you have a few suggestions:

  • Always appoint a back-up for any content manager, to cover holidays, illness, maternity or paternity leave, busy periods, etc. Ideally a content manager should have an assistant that know all tasks involving content management.

  • Write delimited tasks for a content manager to create instructions for managing the content. This will help to get up-to-speed in a short time and relieve your intranet team. While your KM team can easily train a new person in general content management, they will not know the specific processes or agreements or access etc.

As any site where you are managing content, you have a sponsor for that site and he/she knows goals and objectives for it.

On that site should exist a good user guide, help files, training guides, FAQs, referral people,policies,etc.

Also it’s essential a communication plan, monthly or the period you use to publish changes on your site .

Following those items will mitigate the risk. Especially, considering the publishing period, you will that period content ready to keep the workflow running and to take appropriate measures



Early Phases

All those items are fundamental to be on our sight on early phases

A plan is needed of when the content should be ready for publishing and also have an idea of who should be responsible for certain parts of the contents.
It ‘d be ideal that when the new user starts his/her work could be assigned the leaving role and automatically gets the same rights, as the predecessor. The idea being that the content manager is role specific rather than employee specific.

This could be built as details into job contracts (if your organization likes detailed contracts), or otherwise formally document it, In a central "Content Management Roles & Responsibilities" Site or an advanced Knowledge Management Site . Doing so you could map, at an organizational level,  to what content belongs to which role, which has benefits beyond simply knowing what user what.

It’d be ideal to have a map of contents and hierarchy of roles.



Real world sample

I worked with Policies & Procedures Area to add site content responsibilities on specific job descriptions on different areas some time ago. They only knew the responsibilities on their known areas. It’s known that people are better suited (technically minded or more engaged...) than others, so was also needed to create a 'role and responsibilities' document for those staff and wishing to become an editor.
So, when appears a new team or future 'editor' that will develop content,  they receive an initial response back, including their manager, stating what is expected in that role, that they will be reviewed in a year, our content review process and those tasks will be included, on his/her annual performance evaluation, as his/her objectives. It is needed to be sure that he/she will cover the role as editor and subsequently trained to use the Content Management Site. That‘s a good procedure to follow because everyone is clear on what is expected without surprises.

Sometimes it‘s a jumbo task but it’s actually fruitful.




Once this schema begins to work you could coordinate a content audit every some months as a response to the issue of continuity. On that process you could involve every page of the site being confirmed as accurate and up-to-date, picking up any unattended pages.
Result records also make great handover notes for next editors.

On that process could be used a workflow when the revision starts. You could assign a bunch of pages or sites (depending the size of contents) to different editors.
Each of them submits results identifying their content. They also confirm beside each content, that each of them had checked and approved or not approved or delegate the task to a manager or the outcome you need.
Finally a manager is notified that the audit has occurred.
The progress/status of the audit also makes up part of my quarterly reporting to the Web Governance Board under the title of 'Reliability of content'.
Finally a bunch of reports and statistics could be done with information gathered during the process.

Additionally manager could be alerted when HR update the user’s profile when he/she leaves, and begin with a reassignment process for the content that got orphan of reviewers.


    So as to keep content up to date, It could be added metatags to each content/page with a maximum (the period you want) from page creation date . Each month/week all content owners receive an automated notification with all content due to expire nextly , and any that has expired within the last week.

    Additionally the workflow could present a page with title contents so as to give it a quick check to make a massive update, or if it must be removed .

    Finally could be createa a report of expired and updated pages .
    This tends to keep our content up to date, but also helps me to see if anyone is not keeping up with their responsibilities.



      Statistics and Site Analytics and Reporting and Business Intelligence

      A Reporting/BI package should cover those workflow intelligence. Reporting should tell you which contents have expired and give a breakdown of who is the owner.
      You should also get orphan contents and manage the new owner.
      From those reports you should be able to get stat on a spreadsheet of contents and managers.



      A Knowledge management site

      So as to have clear defined goals and objectives for Content Management Roles, it is needed to have clear Content Management Roles Roadmap. Also it’s needed for example in a Digital Processes site a page with good manuals for users documenting processes, forms, projects, tasks, deliverables, and a blog where people could talk about those subjects for continuous enhancements. So any user replacing another user could have all information.

      If it is implemented enterprise wide you will avoid the first users‘s resistance and those situations could be managed and monitored. That kind of information is a key deliverable - not only for project work but for day-to-day operations. An employee must be evaluated on how well he/she manages that responsibility. Its foundational to transfer knowledge and also is very useful for one person leaving gaps in an organization after their departure.



      For each of the topics covered in the sections of this article you can write a world of things, but I'm sure this will help you to begin to review how they are managing the content on your company.


      Recommended Platform

      At Baufest we use use to build some solutions with these problems based on:

      • Sharepoint
      • Nintex Workflows
      • Nintex Analytics or Reporting Services

      If you ‘d like to schedule a demo of those products just contact us.

      Have a nive day.

      lunes, 3 de septiembre de 2012

      No saber la respuesta está bien - Especialmente para el analista de negocio

      por Fernando Hunth

      En los proyectos donde vamos a utilizar Sharepoint , como en otros proyecto sin Sharepoint, es fundamental la tarea del analista de negocios.

      clip_image002Muchas veces es necesario que conozca del negocio que se está relevando , pero esto no es siempre así en todos los casos. Por eso acá van algunos consejos para esos casos.
      Vos, analista de negocio has sido asignado a un proyecto nuevo o en ejecución . Empezaste a trabajar en su kick off inicial preparándote, leyendo el alcance, revisando el documento de schedule y convocando tus primeras reuniones con los diferentes stakeholders del proyecto. En el medio de la reunión mientras estás escuchando atentamente como es el proceso detallado para la transferencia de una política de un organismo a otro, te encontras tomando notas y más notas. De pronto te das cuenta que las notas empiezan a perder relación y el interlocutor continúa hablando y hablando!.

      Aunque tus notas son palabra por palabra lo que están diciendo, por temor a parecer tonto o que el equipo no pierda credibilidad en tu tarea,lo mejor es seguir escribiendo, mientras intentas desesperadamente entender lo que se está diciendo.
      Cuando este es tu primer proyecto, esto es lo que le suele suceder a un analista de negocios.
      En muchas reuniones donde participe vi esto muchas veces.
      Para estos casos, existen este tipo consejos para manejar esas situaciones
      No importa que tan experimentado sea un analista de negocios, una situación como esta va a volver a suceder. Es muy raro que un analista de negocio -sin importar su experiencia - pueda empezar cada proyecto con todo el conocimiento y tener respuestas para todos los escenarios.
      Cuando estas perdido en la reunión:
      1) Trata de no mirar a los ojos de otros miembros de tu equipo del proyecto como buscando complicidad en lo que no se entiende.
      2) Intentar encontrarle sentido a lo que se dice
      3) Sé capaz de tomar la información relevada - aunque no tenga sentido - y producir requerimientos relevantes a lo escuchado.
      Hay cuatro sencillos trucos para poder salir del aprieto de no saber el tema y aún así obtener algo de la reunión.
      · 1) Saber que "No estoy familiarizado con los detalles". Bajo mis roles, trabajo con muchos clientes. Y la mayoría de las veces, sé muy poco sobre sus procesos internos, normas, procedimientos, políticas, etc., y mucho menos como lo plasmaron en sus sistemas y/o aplicaciones. Pero eso no me impide rápidamente empezar a conocerlos. Podes pedir acceso al sitio de Normas y procedimientos por ejemplo, y empezar a conocer más de lo que se habla en la reunión. Cuando estoy con un cliente o un proyecto nuevo, aunque tenga muchas habilidades, a veces son inútiles a menos que se sepa cómo utilizarlas en un proyecto. Cuando me encuentro en un nuevo proyecto que conozco muy poco, tengo que preguntar ¿Podría explicar esto con más detalle? ¿Le importaría explicarlo de una manera más fácil de entender? La razón de esto es para que se pueda entender el tema en un nivel superior con menos detalle antes de empezar a ver temas como el workflow del proceso en particular o la funcionalidad de la interfaz de usuario o lo que sea que se esté tratando de entender. En otras palabras, estamos admitiendo abiertamente que no estamos familiarizados con los detalles. Ser abierto y honesto al preguntar para que se entienda, fortalecerá aún más la relación de confianza con el equipo del proyecto y los stakeholders del negocio. Manejarse de esta manera es poner en claro que todavía no sé de lo que se esta hablando pero pronto voy a estar al tanto de todos los detalles.
      · 2) Buscar los puntos de acción - aunque no seas un Analista de negocios - y hacete carne de ellos, si es que te corresponde. Otro tip interesante es hacer seguimiento de los puntos de acción que salen de una reunión, incluso si no te involucran directamente. Aprovecha la oportunidad en algún nuevo proyecto para aprender tanto como puedas. No importa de donde venga el conocimiento o contenido, simplemente sumergite en el tema del proyecto. No hace falta decir que primero debes atender tus responsabilidades, pero si tenés la oportunidad de asistir a una reunión ; mejor , por ejemplo a revisar un documento de diseño o sentarse con los stakeholders , o incluso convocar reuniones informales para apuntalar tu conocimiento. A pesar de que algunos de los puntos de acción que no están enteramente relacionados con tu trabajo en el proyecto, te van ayudar a construir tu conocimiento de fondo que será muy útil más adelante en el proyecto.
      3) Creá una asociación con el Stakeholder del negocio (o donde esté el conocimiento). Aunque es importante para el analista tener una sociedad sana con el Manager del Proyecto, es igual de importante tener una sociedad sana y abierta con los stakeholders del negocio. Después de todo ellos van a ser a quienes debemos satisfacer con el proyecto. Muchas veces esta relación se pasa por alto, o se pierde valor. Esto conduce a limitar la comunicación o a romperla en el peor de los casos . Si queres tener éxito como analista , tenes que valorar la asociación con los stakeholders. Te va a ser más fácil obtener información vital con rapidez cuando tengas una alianza saludable, fuerte y abierta.
      Probablemente el truco más difícil, es ser humilde y pedir. Este truco es simple de entender , pero también el más difícil de llevar a cabo. Es bueno que al principio de un nuevo proyecto, seas cauteloso de exponer tu punto débil al resto del equipo , para que tus colegas no sepan que tienen una vulnerabilidad en torno a la plena comprensión del tema. Sin embargo, si no hablas ahora será demasiado tarde. Debido a que el papel de un analista es tan vital para el éxito global de un proyecto, nunca se debe dejar pasar la oportunidad al principio para pedir a los stakeholders para aclarar sus comentarios si no los entendes. Podría ser comentarios sobre el alcance, , los fuera de alcance , las necesidades de negocio, requisitos, especificaciones funcionales, diagramas, o cualquier cosa relacionada con el proyecto. El punto es, no importa cual sea la consulta, si no son muy comprensibles, les pedimos que aclaren la cuestión. Muchas veces la fase de requisitos de un proyecto se trata de ejecutar rápidamente, por lo que es importante para establecer las expectativas de nivel de comprensión de la materia al principio y con el fin de evitar ser olvidado. Y te preocupa la pérdida de credibilidad en el inicio de un proyecto por no saber el tema en detalle, imagínate la cantidad de credibilidad que se pierde cuando no entendes nada después de tres semanas de sesiones de análisis o diseño. Te aseguro que participe en proyectos donde recibió documentación de los analistas que me sirvió muy poco para entender cómo construir la aplicación.
      Muchas veces, he visto como buenos analistas pierden la credibilidad con un equipo de proyecto, ya que no están dispuestos a admitir que no sabe algo. Ante el temor de ser ridiculizados, el analista seguirá adelante, con lo que saben del tema, pero cuando se llega a la hora de la verdad en un proyecto y no son tan bien versados, entonces es cuando los requisitos están en riesgo de ser incompletos o incorrectos. La próxima vez que estés en una reunión del proyecto o reuniendo requisitos no sabes la respuesta a una pregunta o no sabes cómo funciona un proceso de negocio, proba utilizar uno de estos consejos para ayudarte a obtener una mejor comprensión del tema. Tenes que ser lo suficientemente audaz para dejar el miedo de perder credibilidad y hacer lo necesario para tener una comprensión clara y concisa del tema en cuestión. Al hacer esto, te colocaras en la posición para producir requisitos sólidos, reales, y precisos.
      Llegar a obtener estos resultados es muy importante para la siguientes etapas del proyecto.
      Recorda que mucha gente se va a basar en esos requerimientos y que el éxito del proyecto depende mucho de vos.

      En Baufest dia a dia, tratamos de mejorar nuestro vinculo con nuestros clientes, donde muchas veces aplicamos estos consejos.

      Teniendo en cuenta SharePoint Folders


      Este es un detalle de la domesticación amplia y diversa de las bibliotecas de documentos: implementando Folder Content Types.

      Teniendo en cuenta SharePoint Folders
      Un ejemplo. Folder Content Types para Profesionales IT

      La mayoría de ustedes probablemente sepan un poco acerca de los content types en SharePoint.

      Proporcionan los medios para organizar metadata en una forma extremadamente flexible y proporcionan el contexto para los workflows, custom menus, y document templates.

      Sin embargo, debido a la naturaleza centrada en documentos de Microsoft Office y SharePoint, los más comúnmente utilizados y discutidos content types son los document content types.

      Bueno, hay otro menos conocido personaje en la historia del content type  de SharePoint - es Folder Content Type.

      Una de las razones por la que folder content type es menos popular es que la instalación por defecto de SharePoint viene con sólo uno de ellos.

      En comparación con docenas de Document Content Types , Folder Content Types está claramente en desventaja.

      Así que vamos a darle una mirada más cercana a este héroe solitario y crear un par de Folder Content Types de manera que podamos saber cómo utilizarlas para mejorar aún más la experiencia del usuario y de gestión de datos de una document library.

      Para poner las cosas en perspectiva, echemos un vistazo al ejemplo de la Fundación de medio ambiente Rain Forest que puede utilizar los folder content types  para mejorar sus biblioteca de documentos.

      El personal de la Fundación almacena todos los documentos en una biblioteca de documentos y que ya utilizan varios document content types de apoyo a sus actividades.

      Los tipos de documentos se han separado en dos grupos funcionales:

      · Project Documents (Additional Fields: Due Date, Assigned To)

      · Application for Grant (Word document)

      · Financial Memorandum (Excel document)

      · Formal Acceptance Document (Word document) 

      · Internal Documents (Additional Fields: Contact, Status)

      · Purchase Order (Word document)

      · Invoice (Excel document) 

      La biblioteca de documentos de aspecto muy familiar, y todos los tipos de documentos se enumeran en el  menú New:


      El equipo de IT de Rain Forest también define algunas vistas basadas en document content type para realizar el filtrado de cada tipo de documento más fácil y ser capaces de mostrar campos específicos del content type como  Due Date y Assigned To :


      Todos los documentos se almacenan en la raíz y, en ocasiones, los empleados crean carpetas a discreción.

      Sin embargo con el paso del tiempo el desorden de carpetas no permite localizar los documentos facilmente.

      Los usuarios también notan problemas de performance.

      Después de unos meses, la carpeta raíz contiene más de 4000 documentos y se espera que crezca.

      ¿Qué se puede hacer?

      Esto es cuando el poco conocido personaje de nuestra historia SharePoint - Folder content type - viene a ayudar.

      Una de las razones para el tema de performance es que en las carpetas de SharePoint tienen algunas limitaciones de diseño.

      No obstante, si partimos los documentos quarters financieros u otros atributos de tiempo, podemos mantener el número total de documentos en una carpeta dentro de la zona de alta performance.

      Es por eso que decidimos crear una carpeta para documentos internos y documentos de proyectos utilizando el respectivo folder content type para cada trimestre del año.

      Además podemos proporcionar cierta estructura y límites para los usuarios, a fin de que ellos no pueden crear carpetas en cualquier lugar de la biblioteca de documentos. Para ayudar a los usuarios localizar los documentos, vamos a utilizar una gran característica de SharePoint, lo que nos permite bindear vistas a un folder content type específico.

      Esto proporcionará el contexto para cada carpeta, de modo que cuando un usuario entra en una carpeta con documentos internos, la vista cambiará automáticamente para mostrar los metadatos relevantes.

      En primer lugar vamos a crear el folder content type para cada uno de nuestros grupos de documento.

      Los pasos no son diferentes de crear cualquier otro tipo de contenido.

      La única diferencia es que nuestro content type hereda de Folder content type.


      Se puede añadir metadatos específicos para cada uno de los recién creados content types, pero para ello, usaremos las columnas existentes.

      A continuación, vamos a añadir la Folder Content Type a nuestra biblioteca de documentos:


      Además, queremos eliminar la carpeta por defecto en el menú New, de modo que sólo están disponibles nuestras opciones de carpeta personalizada  .

      Para ello, abra la configuración avanzada de la biblioteca de documentos y desactivar la opción Nueva carpeta.


      Después de estos cambios, vamos a agregar nuestros dos nuevas entradas de carpeta para el menú New.


      Ahora, cuando un usuario quiere crear una nueva carpeta para el próximo trimestre, seleccionará el tipo de carpeta correspondiente del menú New, y dará a la carpeta un nombre descriptivo como el Internal Q1 2008. T

      El proceso de dotación de una nueva carpeta puede ser automatizado y ampliado mediante el uso de campos calculados u otras técnicas de programación.

      Para proporcionar las vistas adecuadas , crear una vista de la carpeta raíz y por separado, vistas únicas para cada Folder content type.

      En la vista raíz sólo se mostrarán las carpetas de la nueva definición de content type.




      Cada folder content type personalizado tendrá una vista que muestra los metadatos específicos sobre el tipo de documento que figura en la carpeta.

      Estas vistas son las vistas por defecto, pero se asignan al folder content type específico.



      Veamos el resultado de la creación de una carpeta de cada tipo.


      Se darán cuenta de que si hace clic en la carpeta Internal Q1 2008, la vista va a cambiar automáticamente a la vista Internal Documents al igual que la apertura de la carpeta Project Q1 2008 va a cambiar la vista a la vista Project Documents.

      Para añadir más comportamiento sensible al contexto , también puede limitar los items en el menú New que aparece para cada carpeta, de modo que sólo Internal documents se muestra en el menú New de la correspondiente carpeta.

      Desde el menú desplegable de cada carpeta, seleccione Change New Button Order, y ocultar los tipos de documentos apropiados.



      Al entrar en la carpeta se darán cuenta de que sólo existen los items de menu New correctos.


      Del mismo modo se puede esconder los documentos desde el menú New de la carpeta raíz.

      Abrir la configuración de la biblioteca de documentos y en la sección Content Type hacer clic en Change new button order y default content type

      Ocultar todos, excepto la Folder Content Types.


      A partir de ahora, los dedicados voluntarios de Rain Forest puede estar seguro de que puedan localizar fácilmente los documentos y que el rendimiento de su biblioteca de documentos va a ser estable.

      Por otra parte, el IT Pro de la fundación tiene grandes ideas acerca de cómo agregar menús personalizados para cada folder content type, por lo que las medidas aplicables a todos los documentos en una carpeta se pueden ejecutar con mayor rapidez y en el contexto adecuado.

      También hay muchas oportunidades de utilizar event handlers y el modelo de objetos de SharePoint y workflows o Workflows de Nintex con folder content types para ampliar aún más su aplicación.

      Saludos, Fernando Hunth