Business Strategies (BUS) - Falconeris Marimon

Presentación Six Sigma

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 20 Mar 2012 16:24:00 +0000

Hola a todos. Esta es la presentación realizada durante la conferencia "Metodología para la gestión de la calidad Procesos - Six Sigma" en el reciente congreso de Internacional Administración y C.P . Disfrútenla.

http://goo.gl/L5ZK4

Falconeris Marimon Caneda
Socio - Director
TTS Consulting
@falconeris

Como lograr que el cambio perdure

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 22 Feb 2012 21:13:00 +0000

Podcats dirigido a lideres y gestores de cambio donde se dan ejemplos de como lograr que los procesos de cambios en las organizaciones no queden solo en el intento.

El objetivo de este capitulo es concientizar a los líderes por donde se debe de empezar el proceso de gestión de cambio interno.

http://blip.tv/falconeris-marimon/como-lograr-que-el-cambio-perdure-5974247

Falconeris Marimon Caneda
Socio - Director
TTS Consulting
@falconeris

La importancia del reconocimiento en las organizaciones

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 14 Feb 2012 22:28:00 +0000

Este pequeño podcats describe de forma rápida la importancia de reconocer a nuestro grupo de trabajo para generar un buen ambiente laboral . La importancia de los incentivos y 3 ejemplos básicos de lo que han hecho las grandes empresas en este rubro y ver como se refleja directamente en la productividad dela organización.

http://blip.tv/falconeris-marimon/la-importancia-del-reconocimiento-en-las-organizaciones-5958660

Falconeris Marimon Caneda

Socio - Director

TTS Consulting

Gestión de conflictos en proyectos

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 13 Dec 2011 21:54:00 +0000

La mayoría de los conflictos que surgen durante el desarrollo de un proyecto tienden a ser conflicto de intereses, aunque creo que muchas veces el origen de los mismos surge de las esperanzas y miedos de los interesados en el proyecto.

Somos personas, cada una con una percepción distinta de la realidad que nos rodea. Se dice que un Gerente Gerente de Proyecto (Project Manager) gasta el 90% de su tiempo comunicando, quizá sería adecuado decir que gasta un 90% de su tiempo previniendo conflictos.

Es por ello que tanto o más importante que saber resolver disputas es saber prevenirlas. Una buena manera consistiría en tratar la gestión de conflictos de forma parecida a como lo hacemos con otras áreas de conocimiento, más allá de ser un mero proceso del plan de comunicación.

David Kohrell en ProjectConnections nos propone un enfoque en la prevención de conflictos basado en la gestión de riesgos. Podemos estar en desacuerdo acerca de cómo enfocar las relaciones personales con técnicas de gestión duras, pero lo cierto es que se trata de una manera de ser proactivos en cuestiones tan subjetivas. De tal manera que los siguientes pasos nos sirve como una guía para llevar a acabo la gestión de estos:

1. Preparación: Las lecciones aprendidas de anteriores proyectos serán una buena fuente de conocimiento para saber qué nos espera en nuestro actual proyecto.

2. Enunciar los posibles conflictos como riesgos del proyecto: Si el entorno lo permite, conviene incluir los elementos de conflicto como elementos del registro de riesgos. Si la cultura de la organización no lo permite, convendría anotar las posibles áreas de conflicto y hacer un seguimiento.

3. Evaluar el entorno: Un análisis de stakeholders usualmente es un proceso informal de obtención de información. Puede desarrollarse durante las reuniones de seguimiento del proyecto.

4. Evaluar al equipo: Un project manager debe conocer las características personales de cada miembro del equipo, así como sus fortalezas, competencias, debilidades, preferencias y obligaciones.

Seguimiento: Riesgos, entorno y equipo: Actualizar las listas de elementos de conflicto regularmente. Si aparece alguno, se tendría que determinar su nivel para aplicar los planes de contingencia establecidos y las acciones correctoras pertinentes.

El simple ejercicio de la política y el diálogo no siempre resuelve el conflicto. Para solventar las discrepancias, nada como la gracia y el control en la ejecución de un proyecto completado con todo el alcance acordado, en el tiempo requerido y dentro del presupuesto asignado.

Falconeris Marimon Caneda

Socio Director

TTS Consulting

@falconeris

BI Worst Pactice - Selecting a BI Tool Without a Specific Business Need

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 30 Nov 2011 18:15:00 +0000

You might have noticed that the two business examples given in the previous section – the major airline and the telecommunications company – both had finely defined problems and solutions with clear business objectives. Their understanding of their problem helped them identify and implement an effective BI solution. On the other hand, one of the most egregious of the four worst practices in this paper is the purchase of BI software for “general purpose analysis.” In fact, the largest expenses and the smallest ROI is a result of purchasing a solution for “general purpose” BI. In other words, a company recognizes the need for business analysis and immediately plans a project to evaluate and purchase a BI solution for their users.

Without a specific purpose, BI rarely has impact on business. The starting point for creating a BI solution should be when you identify a project that will solve a specific problem through access to information in a timely fashion and in the right context. “Solve a problem,” means that information will accelerate a slow running process, eliminate a bottleneck, reduce the cost of doing business, or even become a new revenue source.

When information requirements such as these are identified up front and used as the business driver behind the BI implementation, the implementation of the BI system has a much greater likelihood for success.

The Solution

The lesson here is that your motivation for pursuing and purchasing BI software, or building a data warehouse for that matter, should never be general purpose. If you want success, understand the business problem and know beforehand what can be expected if information is injected into the process.

Historia de los monos - el prejuicio del ser humano

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 29 Nov 2011 23:04:00 +0000

Un grupo de científicos metió a cinco monos en una jaula. En el centro había una escalera y, sobre ella, un montón de bananas. Cuando un mono subía la escalera para coger bananas, los científicos lanzaban un chorro de agua helada sobre los que quedaban en el suelo. Después de algún tiempo, cuando un mono trataba de subir la escalera para alcanzar las bananas los otros lo golpeaban.

Pasado algún tiempo más, ningún mono intentaba subir la escalera, a pesar de la tentación de las deliciosas bananas colgando de la parte superior. Entonces, los científicos sustituyeron uno de los monos y metieron en la misma jaula otro que no había estado en el experimento del agua helada. Naturalmente, lo primero que hizo el mono nuevo en la jaula fue dirigirse hacia la escalera y subir el primer peldaño, cuando fue rápidamente atajado por los otros. Le agarraron y le pegaron con dureza. Después de algunos intentos y algunas palizas, el nuevo integrante del grupo ya no trató de subir más por la escalera.

Un segundo mono fue sustituido en la jaula y ocurrió lo mismo. Con la diferencia de que el primer sustituto participó con entusiasmo en la paliza atizada al novato; era el que más fuerte le pegaba. Poco después hubo un tercer cambio y se repitió el mismo proceso.

Finalmente, los científicos había sustituido a todo los monos veteranos que aún quedaban en la jaula. De este modo, quedaron un grupo de cinco simios que, aunque nunca recibieron un baño de agua helada, continuaban golpeando a aquél que intentase llegar a las bananas que seguían sabrosas ahí arriba, en la parte alta de la escalera. Si hubiera sido posible preguntar a algunos de los mono que por qué le pegaban a quien intentase subir la escalera, con toda certeza la respuesta habría sido: “No sé, las cosas siempre se han hecho así aquí...”

¿Te suena familiar esta historia, verdad? Una buena parte de la Humanidad acepta las reglas sin preguntarse nada, sin más. Es oprimida sin que haya otro argumento que la aceptación de la opresión y trata de que todos los demás aceptemos su mismo miedo ciego, su misma hambre y su poco interés por la vida.

No pierdas la oportunidad de pasar esta historia a tus amigos, para que, de una u otra manera, se pregunten por qué nos están golpeando y no respondemos, por qué estamos haciendo las cosas de una manera, si a lo mejor podríamos hacerlas de otra.

“Es más fácil desintegrar un átomo que un prejuicio”
A. EINSTEIN

Solución de BI para PYMES

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 08 Nov 2011 13:16:00 +0000

Solución de BI (Inteligencia de Negocios) para PYMES

NuBIa es una solución desarrollada para que su área de trabajo o empresa integre la información relevante y la traduzca en los análisis, reportes, proyecciones y gráficas que necesita para la toma de decisiones, dependiendo de sus necesidades.

Todo lo anterior sin un mayor esfuerzo, sin adquirir software, sin adquirir servidores y sin tener que contratar personal especializado; pues se basa en el concepto denominado cómputo en la nube, es decir, la información se podrá visualizar desde cualquier computadora en cualquier lugar, a través de un portal de internet que almacena y despliega la información de análisis que usted necesita para su empresa.

http://blip.tv/falconeris-marimon/solución-de-bi-inteligencia-de-negocios-para-pymes-5717035

Presentación Inflación e indicadores Financieros

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Sat, 05 Nov 2011 18:54:00 +0000

Esta es la presentación realizada durante la conferencia en el congreso de Administración y Economia sobre "Inflación e indicadores financieros". disfrútenla.

http://goo.gl/gTF1U

Diez lecciones para líderes

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 18 Oct 2011 04:16:00 +0000

1. El sentido de oportunidad es cel todo. Saber cuando introducir una iniciativa, cuándo contraria a los propios constituyentes y cuando frenar son habilidades cruciales.

2. Confianza perdida rara vez es recuperada. La confianza quizá deseo atributo más frágil del liderazgo. Ningún líder puede permitirse no cumplir su palabra.

3. Todo es posible si compartes la gloria. Dar a otro la oportunidad de arrogarse el crédito es una manera fácil y eficaz de conseguir resultados.

4. El liderazgo es establecer conexiones. Los líderes eficaces hacen que las personas sientan que participan en problemas compartidos.

5. Los líderes aprenden de sus errores. Para tener éxito, los líderes deben de reconocer, asumir y entender sus errores, y corregir sus propias carencias.

6. La confianza - no sólo en uno mismo - es crucial. En gran parte, los líderes confían en si mismos,incluso hasta el error. El talento real es la habilidad de aplicar esta confianza a los demás, lo que significa creer en sus talentos.

7. Las asociaciones eficientes precisan lealtad con los socios. Prestar atención a las necesidades de la fábrica o institución distante produce compromiso por parte de los demás.

8. La renovación surge de fuentes diversas. Los líderes deben de conocerse a sí mismos y hallar sus propias reservas de energía.

9. Los líderes deben ser descubridores de talentos. La habilidad de reclutar, identificar y dirigir con eficacia a las personas mas dotadas - incluyendo a quienes son diferentes de nosotros - es en sí misma un talento clave.

10. El lenguaje es nuestra herramienta más eficaz. Si el líder carece de la capacidad de comunicarse puede tener todos los atributos y no lograr impactó alguno.

Published with Blogger-droid v1.7.4

Método para priorizar iniciativas en un proyecto de BSC

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 07 Sep 2011 23:35:00 +0000

Antes de priorizar las iniciativas asociadas a los objetivos planteados es importante verificar las iniciativas o proyectos actuales, estos nunca deben de dejarse a un lado y aunque en el momento de la implementación no haga parte de un presupuesto estratégico no deben de dejarse a un lado.

Con la lista de iniciativas generadas por el método que más convenga en la empresa (lluvia de ideas, consenso, etc.) se realiza un inventario de iniciativas, las cuales deben de tener información relacionada como: patrocinador, áreas que involucradas, fecha inicial, fecha final, costo, recursos asignados y estatus actual (%) para el caso de las iniciativas existentes. Con el inventario de iniciativas definimos qué criterios se utilizaran para priorizar dichas iniciativas, por lo general utilizo algunos criterios definidos, pero puedes incluir estos como base y que el equipo de BSC proponga otras.

Lista de criterios básicos:

Criterio	Descripción
Vinculación con la estrategia	Capacidad de la iniciativa de tener un impacto positivo sobre los objetivos estratégicos
Valor presente neto (VPN)	Valor presente neto de la iniciativa desde hace 5 años
Costo total	Costo total incluyendo mano de obra y materiales
Recursos Necesarios (Personal Clave)	Personal clave que necesita para la iniciativa incluyendo requerimientos de tiempo
Tiempo necesario para completarse	Tiempo total esperado para completar la iniciativa
Dependencias	Impacto de otras iniciativas sobre los resultados exitosos esperados con esta

A Cada uno de los criterios se especifica un peso el cual sumara un 100%. Por ejemplo:

Criterio	Peso
Vinculación con la estrategia	45%
Valor presente neto (VPN)	15%
Costo total	10%
Recursos Necesarios (Personal Clave)	10%
Tiempo necesario para completarse	10%
Dependencias	10%
	100%

Para cada lista de iniciativas asignaremos una puntuación (escala) para cada criterio evaluado, a mí me gusta utiliza una escala de 1 a 10, donde 10 es la puntuación máxima y 1 la mínima.

Y para cada puntuación que asignes a la iniciativa en cada criterio, multiplicamos la puntuación asignada por el peso del criterio para tener una puntuación para la iniciativa.

		Iniciativa 1		Iniciativa 2
Criterio	Peso	Puntos	Puntuación	Puntos	Puntuación
Vinculación con la estrategia	45%	7	3.15	1	0.45
Valor presente neto (VPN)	15%	5	0.75	10	1.5
Costo total	10%	6	0.6	10	1
Recursos Necesarios (Personal Clave)	10%	8	0.8	10	1
Tiempo necesario para completarse	10%	8	0.8	10	1
Dependencias	10%	3	0.3	10	1

Total	100%		6.4		5.95

En este pequeño ejemplo nos da como resultado que la iniciativa 1 tiene mayor prioridad, es decir usted podrá inclinarse por ejecutar esta iniciativa con menor riesgo.

Es importante mencionar que este método sirve de base para el filtrado o selección de iniciativas, independientemente de que el grupo de BSC definido en la empresa seleccione iniciativas bajo otro criterio.

Falconeris Marimon Caneda

Socio-Director

TTS Consulting

@falconeris

What are the steps companies should take to determine their current levels of BI need or effectiveness

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 24 Aug 2011 21:08:00 +0000

IDC has developed a methodology for evaluating an organization's BI competency and pervasiveness based on the following six indicators:

„ Degree of internal use of the BI solution by employees from different levels and departments of an organization. As BI use becomes more pervasive, the number of employees using it will increase.

„ Degree of external use of the BI solution by stakeholders such as customers, suppliers, and government agencies. As BI use becomes more pervasive, the number of external users will increase. Information sharing through a BI solution can strengthen relationships with clients based on codependence on a set of data and metrics that both parties incorporate into their respective decision-making processes.

Percentage of power users or employees who are very familiar with the functionality of the BI software, who use it regularly, and whose primary task is to analyze data and provide decision support to other staff members or management. As BI becomes more pervasive, the number of power users within an organization grows up to a certain level, which does not seem to be significantly
affected by organization size or industry.

Number of domains or subject areas within the primary data warehouse. As BI becomes more entrenched within an organization, the organization will add additional domains to the data warehouse. An organization may start with just a few domains in one department and then expand the number of domains within and across departments. As the number of domains increases, so does the number of users.

„Data update frequency refers to the appropriateness of the data warehouse update frequency to support business decision-making needs. There is a need for the data to be fresh enough to be meaningful to power users and information consumers. Without accurate, timely data, there is no desire to use BI.

„ Analytical orientation is an indicator that consists of responses to several questions dealing with information sharing, importance of and reliance on analytics for decision making, and the influence BI has on an mployee's actions.

The Efficient Enterprise (Cloud Services)

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 23 Aug 2011 14:53:00 +0000

Boosting enterprise efficiency doesn’t have to be complicated. Some Providers combines the latest technologies with best practices and extensive industry expertise to help IT executives get their bearings in five primary areas that accelerate adoption of the Efficient Enterprise model.

Recent technology advances in five key areas put efficiency gains on the fast track. Here’s how Dell can help CIOs capitalize on virtualization, mobility management, storage optimization, cloud services, and automated IT management. This Post only talk about Cloud services.

Cloud services: Free IT staff for strategic projects

Traditional on-site systems can be slow to change and difficult to scale—a significant disadvantage as IT teams are asked to do more with less. Cloud services offer an efficient model that can augment existing infrastructures with additional flexibility and help free IT staff to work on strategic projects rather than
day-to-day systems management.

Some Companies helps companies leverage the benefits of cloud computing by pragmatically combining the power of software as a service (SaaS) with Dell’s infrastructure support and expertise. SaaS offerings can be deployed in as little as a day and scale when needed. Monthly costs are predictable, and enterprises pay only for what they use. With near-zero maintenance and automatic upgrades included, these services enhance IT flexibility and business agility. And when uptime is important for critical applications such as e-mail, a cloud-delivered approach such as Email Management Services helps ensure fast failover to avoid disruption.

Falconeris Marimon Caneda
Owner - Director
TTS Consulting

Yo planeo, Tu planeas, ¿Nosotros planeamos?

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 20 Jul 2011 21:18:00 +0000

El plan es una herramienta esencialmente estratágica. O sea, uno planea en el sentido de la mayor conveniencia. A partir de las fortalezas y debilidades propias y de la lectura del entorno. Copiar lo que otros hicieron porque es lo que más les conviene A ELLOS parecería no tener el status de plan.

¿Cual es el inicio del plan?

“Conócete a ti mismo” sostenían en Grecia Antigüa….Principio de todo: me miro, construyo la matriz F.O.D.A. (Recordemos: Fortalezas, Oportunidades, Debilidades, Amenazas) y a partir de allí armo el plan que más me conviene.

Conciencia sobre mis capacidades, mis posibilidades, mis limitaciones.
Conciencia sobre el entorno y la realidad.
Conciencia sobre el accionar de mis competidores

Segundo Paso: fijación de objetivos. Concretos, reales, ni inalcanzables ni absurdamente complacientes.

Tercer Paso: cómo lo hago? Cómo armo mi equipo? Puedo pagar o necesito aliados que provean su trabajo y participen de resultados? (por ejemplo); cómo convoco? Utilizo el “boca a boca”? acudo a instituciones? a bolsas de trabajo? a conocidos?, etc. etc. etc..

Lo más importante del plan es que respete las necesidades para las cuales está diseñado.
El plan, más que lindo e iluminado, debe ser sencillo, realista y eficaz.

“Lo sencillo promete éxito” me enseñó un amigo hace años. Tenía razón. Si tenemos dos delanteros de más de metro ochenta, y….el centro al cabezazo probablemente dé mejor resultado que la pelota al pie todo el tiempo…. Si tenemos azúcar en lugar de sal, mejor hacer torta que ravioles, no?

El mejor plan es aquel que responde a las demandas del escenario que se nos plantea a resolver. No es el más lindo, el más inteligente o el más complejo.

Falconeris Marimon Caneda
Socio - Director
TTS Consulting

¿La culpa de mis fracasos la tienen los demás?

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 12 Jul 2011 21:36:00 +0000

¿Ha escuchado o dicho alguna vez ¡La culpa no es mia! o… ¡Yo no fui!?.
Por lo general, buscamos la manera de exonerarnos de culpas, señalando a otras personas como las responsables de todos aquellos sucesos que no nos han salido como quisimos.

O bien, cuando no nos queda otra alternativa: decimos: ¡“la culpa es de todos”!... ¿Será que “mal de muchos, consuelo de tontos”?.

Un proverbio chino muy conocido dice: “Por culpa de un clavo se cayó la herradura. Por culpa de la herradura se perdió un caballo. Por culpa de un caballo no llegó el mensaje. Por culpa del mensaje que no llegó, se perdió la guerra”.

El rencor y los resentimientos, sin duda, nacen cuando culpamos. Y la culpa, es el pretexto o la escusa ideal, para disfrazar nuestra incapacidad para asumir la responsabilidad de nuestros errores cometidos.

Lo triste de esto es que “echar la culpa” se ha convertido en una cultura enraizada de la sociedad en la que vivimos.

El pasado es algo vivido; pero no siempre es “experiencia”. Si lo que Usted ha vivido en el pasado le causa remordimiento, rencor, miedo a que pase nuevamente, no es eso experiencia.

La “experiencia” es la sabiduría que Usted ha logrado extraer de esos sucesos y dejar de culpar al mundo por sus tantas caídas.

Si Usted está permanentemente preguntándose ¿“Porqué a mi”?, es porque transita la vida con sentimientos de “Víctima”.

Reformule la pregunta. Pregúntese: ¿“Para qué”? y conviértase en un “Aprendiz de la vida”. Asuma la responsabilidad sobre sus actos.

Entonces, tanto la Víctima como el Aprendiz tienen una pregunta que formularse.

La pregunta de la Víctima, nunca tiene respuestas: ¿Porqué... Porqué a mí? Y siempre está buscando la manera de responsabilizar a los demás de sus fracasos y desgracias.

La pregunta del Aprendiz: ¿Para qué?, en cambio, SI tiene una respuesta, y es: “para aprender”.

Creerse “víctima” no es un sentimiento. Es una “MALA ACTITUD”, un comportamiento humano involutivo, alejado de toda posibilidad de desarrollo.

La actitud de víctima hace que las personas huyan de asumir sus responsabilidades y terminen “lavándose las manos” ante sus errores. Son fabricantes de excusas y “verdades inventadas” (o mentiras) hasta llegar a la manipulación.

Una persona con actitud de víctima llega, incluso, a hacer ejercicio de la creatividad para sostener su flaqueza.

Tenga por seguro que la víctima sólo recibirá las migajas enmohecidas de la lástima, y creerá que es amor y comprensión; pero en realidad, es el ocultamiento del MIEDO que se posee. El miedo es lo opuesto al amor; es concretamente la “negación del amor y la verdad”.

La creencia de Víctima está llena de un “ácido” que carcome la consciencia. Nos hace transitar anchos y espesos caminos con paisajes grises y negros de depresión, de falta de esperanza, de ceguera del alma. En este estado, no se puede distinguir las manifestaciones de amor, ya que el ego busca la manera de encontrar “sin-razones” para estar siempre a la defensiva y prontos al ataque.

“Víctima” es una palabra proveniente del latín antiguo “Victus”, cuya connotación o significado es “Vencido”. En la antigüedad la palabra era utilizada en el léxico religioso para designar a los animales sacrificados. Otra versión considera que la palabra “Víctima” puede tener origen en la palabra latina “Vincta”, para designar “Atado” o con “Atadura”.

Le pregunto:
¿Se siente Usted vencido por las circunstancias de su vida?
¿Cree que los fracasos pueden más que Usted?
¿Siente que su vida es dolorosa o sacrificada?
¿Se siente “atado” por algo?
¿Sabe Usted que la actitud de víctima es sencilla y llanamente “mediocridad”?

Un profesional de la psiquiatría, el español Enrique González Duro, comenta en su libro “La Paranoia” que, entre los factores que desencadenan esta actitud de víctima, se encuentran el narcisismo, las renuentes exposiciones de personas a serias frustraciones y la baja autoestima y dice que "el pensamiento paranoide no tiene en cuenta las razones contrarias, sólo recoge datos o signos que le confirmen el prejuicio, para convertirlo en convicción...” y menciona este ejemplo: "Vi una rosa y quise olerla, pero tuve miedo de ser lastimado".

Aclaro que no estoy diciendo que una persona que culpa de sus fracasos a los demás, aquella que tiene una marcada actitud de víctima, padezca de paranoia; aunque una persona que asume el papel de víctima, tiene pensamientos paranóides.

Reflexione: Usted es el único responsable de su presente y de futuro. Todo lo que piensa, siente y hace es una siembra que, a la corta o a la larga, dará su cosecha.

Aceptar sus errores y fracasos, le permite a su mente y a su corazón que se abran, para recibir la maravillosa sabiduría que se esconde detrás de toda adversidad.

Aceptar el fracaso le da a Usted “poder”, porque al recibir conocimiento de estos benditos sucesos adversos, lo adquiere por añadidura.

Es archiconocida la frase “el conocimiento es poder”; pues bien… acepte el fracaso como un momento maravilloso de aprendizaje.

Le aseguro que hay dos cosas que Usted gana cuando acepta los fracasos:

La primera es que Usted abre su corazón a las dimensiones de la humildad. Aceptar un fracaso, es de corazones humildes y, de esta manera, habrá triunfado ante su ego herido, que no soporta ser vencido.

La segunda cosa importante que Usted gana aceptando el fracaso es que, además del conocimiento y la humildad, la vida le premiará con la capacidad de ser poderosamente más creativo, más ingenioso; y siéndolo, tendrá las herramientas más preciadas para resolver los problemas.

Las cosas que no hemos resuelto, esencialmente son aquellas que primero hemos “censurado”; es decir, nos hemos autoimpuesto gigantes barreras por lo que nos extralimitamos a resolver situaciones en la vida. Todo esto sucede debido al poco o nulo compromiso con nuestra observación interior.

Desarrolle su genialidad, es decir, déje fluir en Usted ese maravilloso genio interior que posee, que es inquieto y que quiere crear cosas nuevas, soluciones coherentes, que provee de respuestas para tomar decisiones inteligentes y evolutivas. Desarrolle ese “genio” en Usted.

Esa lámpara de Aladino, que al frotarla aparece el genio, es la alineación de su corazón con la armonía y su mente consciente enfocada en lo que realmente quiere para su vida. Y para que ese genio aparezca, Usted necesita dejar fluir su esencia.

La humildad es uno de los mayores tesoros que posee, como Líder, y le permitirá alejarse del fracaso.

Dicho de otra manera: La humildad, es uno de los secretos por el cual se alcanza el triunfo y se lo conserva.

Le invito a que considere que los fracasos y las adversidades tienen un propósito divino. Dios nos regala la Gracia de alcanzar el éxito y el triunfo en nuestras vidas, cuando tenemos un corazón humilde para aceptar su voluntad.

“El caballo se alista para el día de la batalla; mas Jehová es el que da la victoria”. (Proverbios 22:31).

Formúlese las siguientes preguntas:

- A decir verdad ¿Los demás tienen la culpa de todo lo que me ha pasado?
- ¿Estoy resentido, con rencor, por las situaciones que he vivido?
- ¿Dejo ir de mi mente y mi corazón aquellas circunstancias que he atravesado?
- ¿Por lo general pienso que siempre tengo la razón y que los demás están equivocados?
- ¿Lo sucedido en mi vida, que me ha causado dolor, todavía siguen latentes en mi, y me siento incomprendido, que nadie me entiende?
- ¿Cada vez que recuerdo mis fracasos, me deprimo y me quita las ganas de hacer cosas para mi crecimiento?
- ¿Prefiero no hacer nada, antes que me vuelvan a lastimar?
- ¿Prefiero no hacer nada, antes de volver a fracasar?
- ¿Acepto mis fracasos?
- ¿He aprendido de mis fracasos y vicisitudes?
- ¿No me siento muy creativo, ni con ideas para resolver los escollos de mi vida?

Carpe diem, Aproveche el día con Plenitud.
Autor: Dr. Daniel Fernando Peiró

Agile DW/BI in a Nutshell

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Thu, 30 Jun 2011 22:47:00 +0000

Agile DW/BI is based upon the classic agile approach called scrum that revolutionizes the way software professionals collaborate within the project room. We put business and coders in the same room, repeatedly giving them two or three weeks to deliver the next increment of shippable code. We provide them only a high-level design to work from, letting them work in the fastest way they can devise, figuring out the remaining details as they go. We ask them to accumulate and utilize a reference model to guide their detailed designs, and have them work to a tough definition of "done" that's applied daily, using only two, light-weight, paper-based tracking tools that all parties can use to monitor progress within and between iterations.
We have to adapt generic scrum in two important ways for data integration projects. First, the solution architect must work with the project's business partner to draft a short vision document, partition the development work into "bite-size" chunks, and sequence the list of desired features for business priority and technical dependencies. Second, we utilize a second agile technique called Kanban to organize the work of the data modeler and systems analyst so that their specs for each module are 80 percent complete when the developers start building each module of code. At that point, however, the developers proceed with largely generic Scrum methods, gaining tremendous speed through a combination of self-organized teams, information-rich programming, and quality-driven development -- all of which allow them to fail fast and fix quickly. Let's consider these aspects to see where "fail fast and fix quickly" begins.

Self-Organized Teams

Whereas waterfall projects prepare a detailed work breakdown structure before coding starts, agile leaves most of that detail for teams to figure out for themselves. Activity within the project room during the first few iterations may look chaotic for a new team, but scrum requires teams to end each cycle with a discussion of how to improve their work habits. Agile places a tough burden upon the team: demo new, shippable code to your business partner every few weeks. Teams quickly devise for themselves exhaustive standards for module development, including traditional quality techniques such as peer reviews and thorough "as-built" documentation for operations. At the end of the cycle, the embedded business partner either accepts or rejects the new modules based upon their functional capabilities.

By placing such tough objectives upon the team and repeating the process every few weeks, agile forces the developers to get good at delivering increments of new value and keeps them good at it. They quickly eliminate every inefficiency in their process, evolving their work habits to be many times more effective than the highly-managed approach offered by waterfall methods.

Fail Fast and Fix Quickly

All three aspects we've described save labor, but more important, they form a synergy that further doubles a team's development velocity. Software professionals make mistakes during projects -- mistakes in requirements, design, and coding. By generating a big, detailed design before coding starts, waterfall methods ossify these mistakes, so they cost a tremendous amount of time to resolve once the application reaches system test.
Through regular demos of shippable code and continuous integration testing, agile forces a team's mistakes to the surface quickly, allowing business and IT to have informed, adult conversations about what can be done with the resources available. The early discovery of major issues means the developers still have time to correct misconceptions in requirements and design. They can keep the project on track, avoid large-scale rework, and consolidate designs so less must be built. Building less, avoiding major defects, preventing rework -- this is where agile DW/BI gets its tremendous speed.

By Ralph Hughes, MA, PMP, CSM.

Lecciones de un CIO: las 5 cosas que tenemos que considerar sobre la nube

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 07 Jun 2011 23:54:00 +0000

La mayoría de los Directores de Información (CIO) ya están hablando sobre la nube y conocen sus beneficios, pero el gran interrogante sigue siendo cuál debería ser el primer paso para conseguir dichos beneficios. El CIO de Microsoft, Tony Scott, publicó recientemente un artículo basado en su propia experiencia de implementación de computación en la nube en la compañía y las lecciones que aprendió en el proceso.

Dado que en Latinoamérica observamos una creciente adopción de computación en la nube (tanto en el ámbito público como en el privado), esas experiencias son lecciones valiosas que pueden ayudar a los clientes a realizar una adecuada priorización para sacar adelante su proyecto.

1. Trasladarse a la nube es una decisión tanto comercial como técnica. Al tomar la determinación de migrar hacia la nube, se deben tener en cuenta —y se deben balancear— los elementos comerciales y técnicos. Identificar las prioridades de negocio y qué problemas de índole comercial se están tratando de resolver, es una parte vital. Pregúntele a su CEO (Director Ejecutivo) cuál es el sistema más importante en la empresa, y cuál es su interés principal. Esta es una buena oportunidad para cambiar las suposiciones y comprender cuáles son las áreas de oportunidad.

2. No hay una talla única. Las necesidades comerciales siempre serán el motor clave y no existe una solución que pueda ajustarse a todos los tamaños y necesidades. Si bien hace unos años muchas empresas construyeron y planificaron para los picos de trabajo, la utilización de servidores fue disminuyendo y los costos de soporte se fueron elevando. La virtualización puede ser el primer paso, pero obtener los beneficios de la nube junto con el nivel de control requerido por ciertos servicios y capacidades, puede extender dichos beneficios. La Tecnología de la Información (TI) de Microsoft pudo reducir los costos de soporte en un 35%; reforzar los SLA (acuerdos de nivel de servicio) y mejorar la satisfacción de los clientes al construir una nube privada, de manera que la flexibilidad en su uso, ya sea en la forma pública o privada, o una combinación de ambas, es la clave.

Toda organización tiene que considerar preguntas cruciales como: ¿cuáles son las capacidades de nuestra oferta?, ¿cuál es nuestro plan de acción?, ¿cuál de nuestras aplicaciones puede trasladarse más fácilmente?, ¿cuáles ya están separadas por estados?, ¿cuál puede ser virtualizada?, ¿cuáles no vale la pena mover a la nube? y ¿cuál es el impacto comercial de trasladar cada aplicación a la nube? Estas respuestas pueden ayudar a definir el equilibrio que mejor se adapta a su empresa.

3. La ventaja de la oportunidad de re-edificar. Muchas veces, en especial en el campo de TI, la tentación detrás del ‘funciona, entonces mejor no lo toques’ impide que las empresas aprovechen las oportunidades de implementar ‘nuevas formas de hacer cosas nuevas’, y no solamente ‘nuevas formas de hacer lo mismo’. Con la incorporación de la nube, TI ahora tiene la oportunidad de cambiar drásticamente el perfil de costo de aplicaciones más antiguas y trasladarlas a una plataforma que sea más escalable. Según Tony Scott, uno de los primeros proyectos en la nube fue mover la herramienta de subastas de Giving, la campaña interna de Microsoft, a Windows Azure porque solamente se usaba una vez al año durante un mes, y las últimas 48 horas de ese mes, siempre mostraba un alto pico en la cantidad de usuarios. Al reconstruir la herramienta, Microsoft redujo el costo de ejecutarla, a la vez que ganó mayor confiabilidad.

4. Busque ahorros de costos en entornos upstream (flujo de datos del cliente al servidor). Detrás de cada entorno de producción hay varios entornos upstream, tales como los de prueba, que muchas veces no se usan o se desaprovechan. La nube le brinda capacidad a estos entornos con solo presionar un botón, disminuyendo los recursos de TI desaprovechados. Esto es ahorro de costos instantáneo en lugares en los que la mayoría de los CIO ni siquiera buscan.

5. El rol de los Directores de Información (CIO) cambiará a medida que la nube se imponga y las organizaciones cambien. Los CIO necesitan prepararse para la evolución de su rol dentro de la compañía. A medida que las empresas se vuelven digitales y se alejan de lo analógico, el CIO debe centrarse más en los procesos de negocios que en los límites organizacionales.

La cuestión principal en relación con la computación en la nube es que los CIO tienen que ponerse en marcha. Esa es la parte más difícil. Sin embargo, una vez que empiezan y experimentan una de estas plataformas, las posibilidades se disparan. Con la visión única de Microsoft y la capacidad que tenemos de ofrecerla a empresas de prácticamente cualquier tamaño, tenemos una gran posibilidad de construir juntos este camino.

La oportunidad es única: conectar las actuales inversiones en activos y conocimiento para aprovechar este nuevo paradigma y beneficiar a empresas en toda Latinoamérica.

Autor Por Aylton Souza

Gerente de Producto Cloud
Microsoft Latinoamérica

¿Por qué unos líderes inspiran y otros no?

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Mon, 06 Jun 2011 19:15:00 +0000

Hace pocas semanas me encomendaron dictar una conferencia tomando como modelo el caso Wal-Mart en el mundo, el día de ayer, un buen amigo me recomendó una conferencia en internet y las cosas se concatenan maravillosamente.

Existe un común denominador de los grandes líderes u organizaciones, de aquellos que logran realmente hacer que miles o millones de personas se vinculen con sus marcas, productos, ideas y/o atributos.

Resulta que las empresas e instituciones se comunican siempre “de afuera hacia adentro”, le dicen al mercado primero “qué hago” y luego “cómo lo hago” ejemplo: “vendo coches (qué)…. Los mejores coches deportivos al mejor precio” (cómo); pero pocas empresas o instituciones, pocos líderes, aterrizan en un “porqué lo hago”.

Y no sólo es importante comunicar el por qué, sino que, más aún, hay que ponerlo por delante. Cuando Sam Walton inicio su negocio, nunca empezó una reunión con su equipo de trabajo diciendo “somos la empresa de venta al menudeo más grande y rentable del mundo (el qué) porque damos el precio más bajo siempre (el cómo). Lo que él realmente les decía es el por qué…. “debemos poner al alcance de la familia americana cualquier producto o servicio permitiendo mejorar la calidad de vida del hombre promedio”.

Cuando uno comparte el IDEAL, la Visión, el fin final del esfuerzo, cuando uno externa en qué CREE, permite a las personas identificar el mismo sistema de creencias básico y permitir que, quienes coinciden con ese ideario, se vinculen “de adentro hacia afuera” con la causa del líder.

Si analizamos cualquier estructura social masiva con miles o millones de seguidores encontraremos el mismo patrón… las personas se vinculan con el porqué aunque el cómo y el qué, incluso, no les sean del todo agradable.

Lo mismo que Amway que genera “libertad financiera” para miles de personas, Casas GEO “creando el mejor lugar para vivir en comunidades sostenibles”, Disney “creando el lugar más feliz del mundo” o cualquier otra institución de liderazgo probado…. Sus seguidores se vinculan con el “por qué” del esfuerzo.

Cuando el líder habla “al corazón” de su equipo, realmente le habla al cerebro límbico, al que están encargados de decodificar los instintos, la inteligencia emocional, subjetiva.

No hay líder que genere seguidores con datos y cifras, como tampoco hay producto que se venda en el mercado previa lectura del manual de funcionamiento.

Las relaciones entre personas, marcas y productos se generan a través de los vínculos emocionales, de confianza, ese “no sé qué, que qué sé yo”, se obtiene al vincular tu discurso y tu accionar a la emocionalidad de tus seguidores, a su sentido sublime por encima del cognitivo.

Así pues, antes de intentar ser seguido porque tu producto o empresa “es el mejor en el mercado”, “tiene los mejores precios” o “es socialmente responsable”, trata de identificar cuál es el fin final de tu servicio o producto, tu propia gestión como líder, ¿porqué es que el mundo puede ser un mejor lugar si me vinculo a tu causa?… a tu esfuerzo… a tu cotidianidad.

Si mi corazón (mi cerebro límbico) realmente confía y cree en ello… tendrás un soldado dispuesto a todo por tu empeño.

Hoy más que nunca…
Piensa, Reflexiona y Actúa….

Autor: Helios Herrera
Derechos Reservados

5 razones para ser más analíticos

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Fri, 06 May 2011 16:07:00 +0000

Parecería extraño pensar que después de 30 años que se ha manejado el concepto de inteligencia de negocio como parte de la estrategia de las tecnologías de la información en las empresas de América Latina, aún tengamos un rezago en la adopción e implementación de métodos para el uso de información en la toma de decisiones.

Las compañías están siendo llevadas al extremo por los cambios en las condiciones del mercado y los ejecutivos, tomadores de decisiones se están preguntando si los métodos actuales de análisis son los correctos, ya que gran parte de su tiempo se destina a entender el pasado a través del uso de reportes y tableros de control con indicadores financieros. Pero ¿que sucede con el presente? y más aún ¿qué pasará en el futuro? Situaciones de tiempo que están presentes en la mente de los tomadores de decisiones sin ningún tipo de respuesta concreta basada en hechos, más bien respuestas motivadas y apalancadas por la intuición de los ejecutivos.

Es por eso que a continuación se exponen cinco razones de peso para que las empresas en América Latina se conviertan en compañías analíticas.

Razón 1: Economía Local, Regional y Global

Sin lugar a dudas, el entorno económico juega un papel fundamental en la operación de las compañías. 2008 y 2009 son la experiencia más reciente, donde la crisis financiera puso en jaque a muchas economías alrededor del mundo y América Latina no fue la excepción. Por ende, ahora en el 2011 se tiene que aprovechar el momento de crecimiento económico que estamos viviendo, por lo que es muy importante incentivar en todos los niveles de la compañía el uso de datos para generar conocimiento. Los procesos analíticos no son exclusivos de los CFO, todas las áreas de la empresa deben hacer uso de estos procesos para el entendimiento del entorno y la correcta toma de decisiones

Razón 2: Transformación del Ambiente de TI

El modelo actual de TI está centrado en el producto y/o servicios transaccionales, derivando en silos de información desintegrados y en procesos monolíticos poco flexibles ante los cambios del mercado, sin embargo las compañías se han dado cuenta que con la aparición disruptiva de nuevos modelos de TI que incluyen soluciones en la nube (cloud computing), dispositivos y aplicaciones móviles, manejo de grandes volúmenes de información (big data) y soluciones de social software (socialitics), estos están siendo los transformadores del ambiente de TI y que es cuestión de tiempo para que las compañías tengan un entorno amigable a los procesos de 'Business Analytics'.

Razón 3: Patrón de Inversión en soluciones de 'Business Analytics' por parte de las Empresas en América Latina.

Cifras recientes del mercado de herramientas de inteligencia de negocios muestran que alrededor del 72% del presupuesto asignado a estas soluciones, tiene que ver con la generación de reportes o la creación de sistemas que analizan información del pasado, lo cual ha ocasionado un estancamiento importante en el camino hacia convertir a las empresas de la región, en compañías analíticas; sólo el 18% de las inversiones en soluciones de 'business analytics' se relaciona con modelos avanzados de análisis de información que tratan de simular, predecir y entender qué podría estar sucediendo en el futuro. Es decir, modelos predictivos que se adelanten a los posibles escenarios tanto favorables como negativos que las compañías puedan estar enfrentando. Este patrón de inversión es un inhibidor para lograr un nivel de madurez en el uso de información para la generación de conocimiento en todos los niveles de la organización.

Razón 4: La Era de las Redes Sociales

El efecto de las redes sociales en las soluciones de 'business analytics' es tan importante que hoy se están planeando proyectos para incorporar en las bases de datos y en los modelos analíticos toda aquella información que se encuentra en las redes sociales, con el único objetivo de entender el sentir de los consumidores así un servicio, un producto o una compañía. Ejemplos claros de instituciones bancarias en América Latina que han invertido en social software para entender lo que sus clientes pensaban antes y después de la crisis financiera de 2008, es una muestra que las soluciones de 'business analytics' no serán las mismas después de las redes sociales.

Razón 5: Necesidades de los Ejecutivos de Negocio

Más allá del CFO, las soluciones de 'business analytics' están siendo demandadas por todas las áreas del negocio que tienen que tomar decisiones con información clara y verídica; esto hace que las necesidades de los diferentes ejecutivos de negocio tengan un peso especifico importante en la decisión de inversión en este tipo de soluciones; y en un mediano plazo tendrán la capacidad de madurar los procesos de información de las compañías.

En conclusión, las compañías deben entender que el camino hacia convertirse en empresas analíticas no tiene que basarse exclusivamente en soluciones tecnológicas; más bien tienen que usar la innovación tecnológica como catalizador de los procesos analíticos y por ende en la cultura del uso de la información. Sin olvidar que cualquier decisión empresarial que se tome tiene que pasar por analizar el pasado, entender el presente y conocer o anticipar lo que sucederá en el futuro.

Que es Inteligencia de Negocios (BI) ?

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Fri, 29 Apr 2011 17:21:00 +0000

En este Capitulo se explica el concepto de Inteligencia de Negocios o tambien conocido como BI. Comenzamos con un marco teorico, pasando por las tecnicas de análisis de información para la toma de las deciciones en las organizaciones hasta llegar al concepto de indicadores de gestión para medir el rendimiento. Finalmente se muestra una demostración de una solución de BI utilizando una herramienta tecnologica.

http://blip.tv/file/get/Falconeris-QueEsInteligenciaDeNegociosBI730.mp4

Mistake to avoid when driving BI solutions adoptation and managing change

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Mon, 25 Apr 2011 18:23:00 +0000

Organizations struggle with many issues that inhibit their ability to achive long-term business intelligence (BI) success, Although thechnology often plays key role, it's the nontechnical elements-people, process, politics and corporate culture. That pose the greatest threat and can sabotage even the best-intented BI Efforts.

Organizations must address the human side of BI to drive awareness, increase adoptions, and create sustainable monument the delivers the greatest long-term value from their BI capabilities.

NOT ESTABLISHING A FORMAL TRAINING PROGRAM

Training users about your BI solutions is one of most important elements for change. for this reason, you must formalize your BI training program by including it as a component of your BI strategy and providing oversight through your governance board.

when developing a formal BI training program, beging by categorizing the users of your solutions. Categorizing users helps your better understand requirement differences for information use and consumption, Bi delivery tools, and training. Most organizations have at least three to five different BI user profile groups.

Once you identify your users, create a formal curriculum for each of the identify user profile in your organization. While the governance board needs to make training a prerequisite to user provisioning, the BICC should own the trining content and provide oversight fort its delivery. Initial training should focus on the proper user of data and business metrics leveraging the BI tool's functions.

Consider a "train- the- trainer" approach and leverage the business champions to server as trainers throutgout your organization. Utilizing business champions enables:

Better cost and time management (Having core BICC team deliver onsite training in geographically dispersed organizations could be too costly)
A stronger focus ont he proper business use of data, reports and analytics
Addresing bussines issues amd question in real time
Better advocacy of the BI solutions and more effective change management

Presentacion Conferencia INDICADORES DE GESTION (Congreso Grupo Loc)

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Thu, 14 Apr 2011 21:20:00 +0000

Hola todos, les dejo el enlace para que puedan acceder a la presentación que realicé en el congreso de economia / Finanzas / Administración organizado por grupo LOC en puerto Vallarta el pasado 8 de Abril 2011.

El tema expuesto fue INDICADORES DE GESTION. Inlcluye temas relacionados con la definición de indicaodres, concepto de gestión y la metodología de como crearlos o establecerlos.

Aqui les dejo la liga: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B8ACYjAZbXRUYjNjZmJhMTgtNDM3Zi00Yjk2LWE0Y2YtNjc1ODhjN2I4OTcw&hl=es

Espero la disfruten.
Saludos cordiales.

Falconeris Marimon Caneda
Socio Director
TTS Consulting

Presentacion Conferencia SIX SIGMA (Congreso Grupo Loc)

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Tue, 12 Apr 2011 22:51:00 +0000

Hola todos, les dejo el enlace para que puedan acceder a la presentación que realicé en el congreso de economia organizado por grupo LOC en puerto Vallarta el pasado 8 de Abril 2011.

El tema expuesto fue SIX Sigma como filosofia de calidad. Inlcluye temas relacionados con la metodología, errores comunes en la implementación, origen y administración de proyectos de Six Sigma.

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B8ACYjAZbXRUOThkYzllN2ItZDI1YS00ZjFjLWE5MGQtMDZmOGNiYzEzOTk4&hl=es

Espero la disfruten.
Saludos cordiales.

Falconeris Marimon Caneda
Socio Director
TTS Consulting

What is a business rules analyst? Is it really a new role?

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Wed, 23 Mar 2011 21:59:00 +0000

The term business analyst is not new. How is this new role of the business rules analyst different from the role of a business analyst? A business analyst is responsible for analyzing the business needs of their clients to help identify business problems and propose solutions. A business rules analyst, however, can be thought of as a business analyst with a focus on business rules. The role's primary objective is to focus on separating rules from code.

You do not need a special degree or qualification to become a business rules analyst, but you should have experience as a business analyst. Analytical skills are important for a business rules analyst to discover, capture, and express business rules in simple English that is easily understandable by business peers as well as the IT people who are going to design the business application. It is also useful for a business rules analyst to have an understanding of object-oriented programming concepts. A business rules analyst doesn't necessarily need to have working experience as a software developer, but that experience certainly helps them appreciate and implement the reusability aspect of software development.

The skills needed for this new role are very similar to that of a general business analyst, but the focus and day-to-day responsibilities are quite different. For example, it would be the business analyst who facilitates sessions to capture business rules for a new business application, whereas the business rules analyst
would ensure that the extracted rules reflect the business intent and will result in the desired business behavior. The business rules analyst also uses these sessions to understand how rules are enforced, how they are going to change, and how rule-related issues such as conflicting rules would be resolved.

The previous figure shows the role each expert plays in the rules application development cycle. There are four steps involved, as explained next.

1. Define the business application Based on real market need, business owners decide to introduce a new product. The key players in this step are business owners and business analysts. After an in-depth feasibility study and quantitative analysis, they define the requirements for the new application. The majority of work at this step is done by the business analysts.

2. Discover rules The requirements then come to the business rules analyst, who goes through the documents and extracts business rules from these requirements. The business rules analyst comes up with a list of rules in the form of structured natural-language statements that clearly, completely, and concisely express the rules to be implemented in the application. The business rules analyst must use his or her knowledge of process modeling and fact modeling to discover these rules. This step also involves validating the rules and developing scenarios for testing.

3. Create a framework for writing rules In this application design and development step, the business rules analyst works very closely with rules architects and rules developers to help them design the application in a way that ensures that the rules reflect the business intent and that the application will result in the desired business behavior. The key players here are business rules analysts, rules architects, and rules developers. The architects design the framework for business rules analysts to write the rules in a simple, English-like language. This is the most important step, because the business rules analyst has to make sure there is no redundancy in the rules while also helping the rules architects make components that will be reusable in other similar applications. The business rules analyst also structures the rules properly based on a logical model and works with the rules architect to help design the application in the BRM system. The rules architect along with expert developers then create a rules application, known at this stage as rules templates. Rules templates are guiding models that business rules analysts use to create the actual rules.

4. Create and manage rules The final step is to create or add the rules to the application. The business rules analyst uses a simple Web-based user interface to create rules for the first time. The business rules analyst uses the same interface to manage rules in the future. You might have noticed that the business analysts primarily interact with the management and business owners, whereas the business rules analysts must talk to all levels involved in developing the actual solution that the business rules are part of.

After the rules are created and tested, they are deployed and interfaced with other logical components of a system. A good business rules analyst elicits the invaluable knowledge from the business experts, digitizes it, and helps manage it in the most efficient manner possible.

Why Agile BI Needs an Agile Architecture

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Thu, 17 Mar 2011 19:40:00 +0000

Agile development has been sweeping through application development teams (and more recently BI teams) across the public and private sectors alike. We’ve seen development methodologies come and go over the decades; today we’re embracing terms such as “scrum,” “sprints,” and “refactoring” into our everyday vocabulary. With each one of these methodologies, the driving force has always been to improve aspects of our value delivery. Information consumers are interested in quicker delivery of information, and government agencies need to act quickly to meet regulatory requirements.

Organizations of all types and sizes want lower the risk of projects not meeting intended business needs. Projects delivered in smaller increments will reduce risk, deliver valuable increments faster and effectively manage ever-changing project requirements in a fast-paced world.

Such needs drive development methodologies to incorporate short delivery cycles, partnerships, and fast failures (to reduce losses) while not worrying about formal requirements processes that can be rigid. However, when the organization wants the benefits of being agile, the whole system of information delivery -- not just the developers’ methodology -- has to be agile.

Agile architecture doesn’t immediately come to mind when we think about agile BI. Some might even jokingly say that it’s an oxymoron. However, information delivery does create and run on an information platform and architecture. Architectures represent solid foundations and standards that emphasize consistency that will stand the test of time. This may sound as though it’s the opposite of being agile and tactical -- or of delivering quickly. We need to understand that being agile is a philosophy and the same benefits enjoyed by agile developers are gained in building information architecture.

Here are some of the principles that I have found successful in bringing architecture and platform evolution into the agile model.

Refactoring Architectures

The data warehouse architect needs to recognize that just as information delivery projects add value to customers, their DW architectures make it possible to deliver those projects efficiently and reliably. Similarly, customer demands change rapidly, as much the underlying architecture. It must continually change and evolve.

We grow into our vision of data warehouse architecture with each project delivered and by mercilessly refactoring and revising the architecture. Classic architectures and principles should be the guidelines along the way, of course. TDWI’s BI Maturity Survey reinforces that data warehouses naturally evolve over time -- from infant stages to being a sage. Conforming dimensions, populating an EDW subject area, and consolidating staging areas are examples of refactoring, and having a mindset open to such changes allows agile BI projects to be completed quickly without concern that developers will ignore architectures, create information stovepipes, or run into dead ends.

A physical data warehouse architecture typically starts with a single server and a few hundred gigabytes of data. By the time it’s a teenager, your warehouse architecture must have matured to handle dozens of special-purposed server and hundreds of terabytes that serve an ever-growing variety of enterprise users tackling an ever-growing variety of BI tasks.

Specific architecture-based projects need to be treated the same as agile BI projects but use separate sprints and defined as distinct projects following BI project implementations. Typically refactoring happens about every six months for younger data warehouse architectures that are focused on initial deliveries and 12 to 18 months for more mature data warehouses focused on efficiency and consistency. Always look for opportunities that simplify the architecture, maintain or improve consistency and consolidate patterns in the architecture while not removing any functionality. Keep in mind that refactoring architecture can be either opportunistic or sometimes reactionary when there’s enough pain.

The Importance of Strategic Road Maps

As in any agile project, communication is key. This is especially true when you’re building and maintaining a data warehouse architecture.

One key component of an agile BI approach will be active management and communication of strategic architecture road maps. You start by performing an assessment and inventory of your data warehouse assets and capabilities. If the inventory is point A, then the vision of your data warehouse architecture will be point B. A good architecture road map shows snapshots of your expected architecture evolution for the next three to five years. The current year will have quarterly snapshots that (at a minimum) reflect your current planned project deliveries, years 2 through 5 will only offer an annual snapshot that shows which part to the architecture you plan to focus on.

At least once a year, preferably quarterly, formally update this road map and communicate it throughout your organization. Executive sponsors prefer this level of detail and progress tracking while gaining confidence that you have a well thought out plan. The annual review will also include the past year’s accomplishments and typically coincide with the budget planning process for the next year. While a physical architecture roadmap assists with the capital budget process, the logical data architecture deals more the BI deliverables and capabilities.

Finally, all aspects of your agile BI program will need to agile: the people, process, architecture, data, and technology. Agile architecture is keeping our natural data warehouse evolving while increasing value of the information platform and minimizing rework.

Logical Versus Physical Design in Data Warehouses

fmarimon@yahoo.com (Falconeris Marimon Caneda) — Thu, 10 Mar 2011 23:01:00 +0000

Your organization has decided to build a data warehouse. You have defined the business requirements and agreed upon the scope of your application, and created a conceptual design.

Now you need to translate your requirements into a system deliverable. To do so, you create the logical and physical design for the data warehouse. You then define:

The specific data content
Relationships within and between groups of data
The system environment supporting your data warehouse
The data transformations required
The frequency with which data is refreshed

The logical design is more conceptual and abstract than the physical design. In the logical design, you look at the logical relationships among the objects. In the physical design, you look at the most effective way of storing and retrieving the objects as well as handling them from a transportation and backup/recovery perspective.

Orient your design toward the needs of the end users. End users typically want to perform analysis and look at aggregated data, rather than at individual transactions. However, end users might not know what they need until they see it. In addition, a well-planned design allows for growth and changes as the needs of users change and evolve.

By beginning with the logical design, you focus on the information requirements and save the implementation details for later.

Creating a Logical Design

A logical design is conceptual and abstract. You do not deal with the physical implementation details yet. You deal only with defining the types of information that you need.

One technique you can use to model your organization's logical information requirements is entity-relationship modeling. Entity-relationship modeling involves identifying the things of importance (entities), the properties of these things (attributes), and how they are related to one another (relationships).

The process of logical design involves arranging data into a series of logical relationships called entities and attributes. An entity represents a chunk of information. In relational databases, an entity often maps to a table. An attribute is a component of an entity that helps define the uniqueness of the entity. In relational databases, an attribute maps to a column.

To be sure that your data is consistent, you need to use unique identifiers. A unique identifier is something you add to tables so that you can differentiate between the same item when it appears in different places. In a physical design, this is usually a primary key.

While entity-relationship diagramming has traditionally been associated with highly normalized models such as OLTP applications, the technique is still useful for data warehouse design in the form of dimensional modeling. In dimensional modeling, instead of seeking to discover atomic units of information (such as entities and attributes) and all of the relationships between them, you identify which information belongs to a central fact table and which information belongs to its associated dimension tables. You identify business subjects or fields of data, define relationships between business subjects, and name the attributes for each subject.

Your logical design should result in (1) a set of entities and attributes corresponding to fact tables and dimension tables and (2) a model of operational data from your source into subject-oriented information in your target data warehouse schema.