Bioactive Technocracy

Estimación de Proyectos de Software: Intro

2012-12-10T09:55:00.001-08:00

Hola estimado Internauta, gracias por pasar por mi blog. Si es que estás leyendo esto, es que más de alguna vez te has encontrado, lidiado o conoces sobre proyectos en los que no se cumple con las fechas de entrega, donde no se cumple con el cronograma, o donde hay sobrecostos.

Por otra parte, yendo al principio, la estimación es una actividad que todos encontramos en nuestro día a día, por ejemplo cuando nos trasladamos desde nuestro hogar hasta el trabajo, estimamos cuánto tiempo nos tomará. Cuando vamos construir un casa, probablemente queremos saber cuanto nos costará y en cuanto tiempo estará lista.

Hay muchos retos alrededor de este tema, relacionados con estimar con precisión proyectos de software. Existen estándares y técnicas que nos ayudarán a abordar este tema, respecto a lo cual señalaré en este artículo algunas de las mejores prácticas.

Es necesario pensar la estimación como un proceso dinámico, en el cual tenemos como entrada la experiencia o datos históricos de proyectos anteriores y que nos sirven para crear una línea base de estimación. En la medida que va avanzando el proyecto se requiere gestionar la estimación, es decir si el contexto del proyecto ha cambiado, es decir el contexto, entonces la estimación debe actualizarse. Por otra parte toda esa nueva información sirve de retroalimentación para ajustar nuestro proceso de estimación.

Para estimar el esfuerzo debemos considerar varios pasos, comenzando por la estimación del tamaño, paso en el cual se acota el alcance y se define la "cantidad de trabajo" que se requiere realizar, por ejemplo en términos de un local de comida rápida, tendríamos que se require cocinar 50 hamburguesas especiales; para cocinar esas hamburguesas (como proyecto, es decir un pedido único), procedemos posteriormente a definir cual es el esfuerzo requerido para cocinar ese pedido, por ejemplo 200 horas - persona. Luego dependiendo del tiempo que dispongamos podemos asignar más o menos recursos para finalmente obtener la duración.

Respecto a la caricatura anterior, para el proceso de estimación, podemos considerar como input la experiencia de los cocineros, es decir utilizar su juicio experto, o Dephi, consultándole a varios cocineros, estimar en términos de pedidos anteriores es decir Analogía, o utilizando alguna fórmula en base estimaciones anteriores, o desglosando las actividades, o simplemente considerar una estimación top down de alto nivel. ¿Cómo sabemos cuál es la mejor alternativa para estimar nuestro proyecto?

A continuación recomiendo un excelente video de referencia:

http://www.youtube.com/watch?v=boAT_ChVEfo

BI en el sector de Servicios Financieros

2012-04-26T10:48:00.002-07:00

Cualquier entidad financiera que quiera competir en el mundo global debe comprender y definir sus objetivos de negocio con la claridad. Por otra parte unos clientes más exigentes, cambios rápidos, fuerte competencia y márgenes cada vez más pequeños, exigen al sector bancario estar a la vanguardia tecnológica.

Una solución tecnológica capaz de desarrollar el potencial de una organización que cubre desde la planificación estratégica, y pasa desde la contabilidad financiera, hasta el control de gestión en la empresa evidentemente permitiría un mejor manejo de ganancias, riesgos, relaciones con los clientes y control de cuentas en forma totalmente integrada en un sistema de gestión completo y seguro.

El mercado ofrece diversas soluciones comerciales que cuando están alineadas con el negocio y sus políticas (IT Governance), proveen un ambiente muy potente para el manejo de todos los aspectos de una organización financiera.

Un sistema de BI vendría a cubrir éstas necesidades en sector financiero. Desde la perspectiva interna, se requiere de un sistema de gestión bancario completo e integrado (Ej. Balanced Scorecard + BI) que ayude a aumentar la rentabilidad a través de decisiones mejor informadas sumado a un enfoque sistémico de:

La rentabilidad de los canales de distribución
Las unidades organizacionales
Los productos
Los clientes

Está el caso de BBVA que con el objetivo de tener al cliente en el centro de toda su actividad (Customer Centric), el Grupo global de servicios financieros BBVA ha seleccionado a MicroStrategy como plataforma corporativa de Business Intelligence tras un ESTRICTO proceso de selección, herramienta ya avalada por los buenos resultados que arrojaron los números respecto a su rentabilidad en el 2011. Desde el año 2008, BBVA inició laboralmente una revisión global de sistemas de soporte a la toma de decisiones, incluyendo las áreas de operaciones, pre-venta, ventas, finanzas, marketing y análisis de riesgos, llegando a la conclusión de sustituir las herramientas de reporting existentes por una plataforma de BI con el objetivo de ofrecer al Grupo una versión única de los datos de negocio (tras proceso ETL y limpieza en datos), habiendo proporcionado conocimiento y levantado las alertas en el momento adecuado para responder a los requisitos de la directiva y reducir los costos e impactos operacionales.

Pronto verán la luz los próximos proyectos BI en Chile que responden como contrademanda a líneas de aplicaciones ya deprecadas. Esta primera fase solo es la punta del iceberg y dará paso a nuevas prestaciones para las multinacionales, por ejemplo para medir y codificar mejor los procesos de un Banco, jugando adelantado y garantizando los resultados antes de expandirse.

Concluyendo, respecto a la implementación existen empresas que ofrecen soluciones customizables, y comento como Tip que podrían establecer prácticas para el desarrollo con un framework Open Source para agilizar y mejorar la calidad de los productos, lo cual no implica compartir fuentes, pero que sí fortalece la marca (Caso RedHat).

MASHUP:
http://www.latcapitalsoluciones.com/soluciones-industria/banca-y-servicios-financieros/
http://www.techweek.es/business-intelligence/soluciones-negocio

Proyectos TI: Valor Organizacional

2012-04-15T16:32:00.002-07:00

La idea de gestión de proyectos ha estado con nosotros desde hace mucho, mucho tiempo. De hecho, ésta idea ha estado con nosotros antes que las grandes pirámides de Egipto fueran construidas. Hoy en día, la gestión de proyectos ha emergido en su propia área, teniendo como fundamentos un cuerpo de conocimiento e investigación en muchas disciplinas. Aunque aún es relativamente reciente el campo del MIS (Gestión de Sistemas de Información) y la Ingeniería de Software, tienen sus propios “cuerpos de conocimiento”, que incluyen varias herramientas, técnicas y métodos apoyados por una creciente base de investigaciones.

Desafortunadamente, la historia para los proyectos TI no ha sido exitosa como uno hubiera esperado, aunque la situación parece estar mejorando. Una razón para estas mejoras ha sido un mayor enfoque en la gestión de proyectos para apoyar las actividades requeridas para desarrollar y entregar sistemas de información.

Construir un sistema es más que sentarse en frente de un computador y escribir código, la gestión de proyectos es más que crear bonitos diagramas o diagramas utilizando uno u otro software para la gestión de proyectos.

Por otra parte, construir un sistema es un éxito desde una perspectiva técnica, pero puede ser un fracaso a nivel de la organización. Los sistemas de información –el producto de los proyectos TI- implican un cambio organizacional planificado. Las TI son un facilitador para nuevos productos, servicios, y procesos que pueden cambiar las relaciones existentes entre una organización y sus clientes o proveedores, así como entre las personas dentro de la organización.

Este cambio puede representar una amenaza a muchos grupos. Por lo tanto, la gente no necesariamente será receptiva a nuevos sistemas de información, independiente de lo bien que hayan sido construidos, o que tan avanzada sea la tecnología, herramienta y técnicas. En la otra mano, las personas en una organización pueden legítimamente resistirse a utilizar sistemas de información que no funcionan apropiadamente, o que no satisfacen sus necesidades como esperaban. Por ende, debemos adoptar un enfoque que no considere el aspecto técnico sobre el organizacional, o viceversa. Atender a ambos aspectos, técnico y organizacional de los proyectos TI, debe estar balanceado con tal de lograr un proyecto exitoso.

Pero, ¿qué es un proyecto exitoso? Muchas personas y autores definen un proyecto exitoso en términos de un proyecto completado dentro del plazo y dentro del presupuesto. No voy a argumentar que la

realización de un proyecto en el plazo previsto y con los recursos asignados no sea importante. Sin embargo, completar los proyectos dentro del plazo y presupuesto, son condiciones importantes, pero no necesariamente suficientes, si lo que el cliente recibe no era lo que esperaba.

Un proyecto que aporta valor -medible- a la organización, define que proyectos serán evaluados como exitosos. Por otra parte este enfoque alinea la gestión de proyectos de TI y los conceptos, herramientas y técnicas relacionadas, así enmarca las decisiones a tomar desde la concepción hasta el cierre de un proyecto.

EXTRACTO:

John Wiley & Sons - Information Technology Project Management; Providing Measurable Organizational Value - 2002

Conceptos de Gestión TI

2012-04-15T12:33:00.004-07:00

El papel clave que tienen las tecnologías de la información y la innovación en el desarrollo y sostenimiento de la competitividad de empresas y países, está generando un cambio en las prácticas de gestión empresarial. De allí se pasa a identificar las funciones y actividades propias tales como la prospectiva, planeamiento tecnológico, innovación tecnológica, desarrollo y transferencia de tecnología. La búsqueda deliberada y sistemática de innovaciones y el uso intensivo del conocimiento como factores dominantes y responsables del éxito de las empresas, están promoviendo a la gestión tecnológica como la función motora e integradora de las estrategias de desarrollo empresarial.

Algunos conciben este sistema como "una colección de métodos sistemáticos para la gestión de procesos de aplicación de conocimientos, extender el rango de actividades humanas y producir bienes y servicios" (Kanz and Lam, 1996). Mientras otros, como el National Research Council (NRC) de EEUU, lo considera como los conocimientos integrados de "ingeniería, ciencias y disciplinas del área de gestión, para planear, desarrollar e implementar capacidades tecnológicas en el diseño y el logro de los objetivos estratégicos y operacionales de una organización" (Khalil, 1998).

Se mencionan a continuación algunos conceptos asociados a la gestión de las tecnologías de la información y especifican procesos, elementos y funciones básicas para definir una Estrategia TI en la empresa:

IT Governance+Balanced Scorecard (Estrategia, Políticas)
PMBOK (Gestión, Táctica)
SGC: BPM+CMMi+Ingeniería/UML+ISO9001+ITIL (Procesos, Operaciones)

La relación entre estos conceptos, modelos y teorías nos aportan en los procesos de toma de decisiones y ejecución de acciones relacionados con las tecnologías de la información en la empresa y organizaciones.

REFERENCIAS:

http://jaibana.udea.edu.co/producciones/Heberto_t/gestion_teno_dllo_tecno.html
http://www.monografias.com/trabajos21/gestion-tecnologica/gestion-tecnologica.shtml

PMBOK a secas

2012-04-12T18:39:00.001-07:00

El Project Management Institute (PMI®) detectó en el año 1969 grandes falencias en la Dirección de Proyectos a nivel mundial. En 1987, el PMI publicó la primera edición del PMBOK® como una guía para satisfacer la necesidad de disponer de un marco teórico en la disciplina de Dirección de Proyectos.

La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK®) es un estándar ampliamente reconocido para gestionar y administrar proyectos. La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto e incluye prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas innovadoras que están emergiendo en la profesión, incluyendo material publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante evolución.

El objetivo principal de la Guía del PMBOK® es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas. Identificar significa proporcionar una descripción general en contraposición a una descripción exhaustiva. Generalmente reconocido significa que los conocimientos y las prácticas descritos son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y que existe un amplio consenso sobre su valor y utilidad. Buenas prácticas significa que existe un acuerdo general en que la correcta aplicación de estas habilidades, herramientas y técnicas puede aumentar las posibilidades de éxito de una amplia variedad de proyectos diferentes. Buenas prácticas no quiere decir que los conocimientos descritos deban aplicarse siempre de forma uniforme en todos los proyectos; el equipo de dirección del proyecto es responsable de determinar lo que es apropiado para cada proyecto determinado.

"La finalidad del PMBOK®, entonces, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas"

Para que estas buenas prácticas sean asequibles, el PMBOK® divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto, así como sus distintas fases e iteraciones tiene que transitar por una serie de actividades de inicio, planeación, ejecución y cierre.

Existen otras normas sobre madurez de la dirección de proyectos de la organización (CMMi), características del equipo humano y otros temas donde las normas sobre dirección de proyectos no abordan la totalidad de los detalles de cada tema. Hay varias razones por las cuales una norma no trata un cierto tema: puede estar incluido en alguna otra norma relacionada; puede ser tan general que no haya nada que se aplique únicamente a la dirección de proyectos; o no existe consenso suficiente acerca de un tema. La falta de consenso significa que hay diversas opiniones dentro de la profesión acerca de cómo, cuándo o en qué parte de la organización, y quién dentro de ella, debe llevar a cabo esa actividad específica de dirección de proyectos. La organización o el equipo de dirección del proyecto debe decidir cómo se van a tratar esas actividades en el contexto y las circunstancias del proyecto para el cual se está usando la Guía del PMBOK®. Puesto que se trata de una guía, más que de una metodología usar diferentes metodologías y herramientas para implementar el marco de referencia y comprender mejor el más amplio contexto en el cual se realizan los proyectos.

Actualmente la creciente aceptación de la dirección de proyectos indica que la aplicación de conocimientos, procesos, habilidades, herramientas y técnicas adecuados puede tener un impacto considerable en el éxito de un proyecto. La Guía del PMBOK® también proporciona y promueve un vocabulario común en el ámbito de la profesión de la dirección de proyectos, para analizar, escribir y aplicar conceptos de la dirección de proyectos, además de en el Code of Ethics and Professional Conduct del Project Management Institute se precisa las obligaciones básicas de responsabilidad, respeto, imparcialidad y honestidad. Requiere que quienes se desempeñan en este ámbito demuestren compromiso con la conducta ética y profesional.

PMBOK 5, más ágil que nunca

2012-03-15T10:40:00.000-07:00

Hace unos días el PMI (www.pmi.org) ha liberado el “Exposure Draft“ de la siguiente versión 5 del PMBOK (A Guide to the Project Management Body of Knowledge). El objetivo de este documento es presentarlo a los profesionales miembros del PMI para que la revisen y generen sus comentarios.

Encuentro muy interesante que en el 2011 existiendo una mayor madurez de las metodologías ágiles, estas se comiencen a integrar como alternativas respecto al ciclo de vida de los proyectos, en lo que sería la gestión de proveedores.

Respecto a los cambios en los Procesos y Areas de Conocimiento, quizás lo más importante es que se ha añadido una nueva área de conocimiento, denominada “Project Stakeholder Management“, que tiene el código 13, con los siguientes procesos:

13.1 Identificar a los Interesados (que en la versión de la Guía para el PMBOK(r) pertenecía al capítulo 10, Gestión de las Comunicaciones del Proyecto.
13.2 Planificar la Gestión de los Interesados
13.3 Plan la relación con los interesados (Plan Stakeholder ENGAGEMENT). Realmente la palabra Engage, es más que relación (mi traducción). En inglés se usa la palabra ENGAGE al momento de COMPROMETERSE en matrimonio.
13.4 Gestionar la relación con los interesados (Manage Stakeholder Engagement)
13.5 Controlar la Relación con los Interesados (Control Stakeholder Engagement)

Otra novedad muy importante es que ahora se ha formalizado el desarrollo de los planes para la gestión de los alcances, tiempos, y costos, que en la versión anterior se exigía pero estaba inserta en la introducción a dichos capítulos. Es decir, ahora tenemos los nuevos procesos,

5.1 Planificar la Gestión de los Alcances. Aquí se ha añadido un ejemplo de una matriz para la trazabilidad de los requerimientos.
6.1 Planificar la Gestión del Cronograma
7.1 Planificar la Gestión de los Costos

Los contenidos de dichos planes son los mismos básicamente que en la versión anterior.

Otro elemento importante es el ítem 1.6 Valor del Negocio (1.6 Business Value). Esta nueva sección de dos páginas trata la importancia del proyecto de generar valor para las organizaciones como objetivo principal. De nada sirve terminar a tiempo, cumpliendo los presupuestos, etc. si el proyecto no añade valor a la organización.

En el capítulo de Alcances, el proceso que anteriormente se denominaba Verificar el Alcance, ha sido re-nombrado como “Validar el Alcance“.

Si usted tiene algún comentario sobre la nueva versión de este estándar, puede ingresar a la página web del PMI y enviar dichos comentarios.

REFERENCIAS:

http://www.allaboutagile.com/agile-project-management-extending-pmbok/
http://www.velociteach.com/2012/02/thoughts-on-the-5th-edition-pmbok-guide-exposure-draft/
http://www.pmi.org/PMBOK-Guide-and-Standards/Standards-Library-of-PMI-Global-Standards.aspx

CMMi y la Necesidad de un Modelo Integrado

2012-02-04T19:01:00.000-08:00

A mediados de la decada los 80' se hizo evidente para el Departamento de Defensa de los Estados Unidos de que la gran cantidad de sistemas que se estaban desarrollando para aplicaciones de defensa que eran intensivos en software, no estaban cumpliendo con los requisitos establecidos y se estaban elevando descontroladamente los costos.

El Software Engineering Institute (SEI), como parte de la Carnegie Mellon University, fue fundado por el Departamento de Defensa como un centro de para la investigación y desarrollo, con la misión de liderar y promover las prácticas de la Ingeniería de Software para mejorar la calidad de los sistemas basados en software.

Inicialmente el modelo se enfocó predominantemente en los procesos de Ingeniería de Software. Las actividades del ciclo de vida del software que coincidían con las descripciones encontradas en la ISO9001:1994 fueron colocadas todas juntas en una Area de Proceso Clave (Key Process Area) llamada Ingeniería de Producto.

Muchos debates tomaron lugar en los sagrados salones del SEI durante el desarrollo del CMMI v1.0 con respecto a la necesidad de una descripción más detallada de las actividades del ciclo de vida versus mantener un cierto tamaño y un número de Areas de Proceso Claves que fueron desarrolladas en el Nivel 3 de Madurez. Al final, se decidió mantener sólo una Área de Proceso Clave llamada "Ingeniería" donde se describen las actividades o funciones que se mantendría compatibles con el resto de KPA en CMM.

Mientras el uso de CMM crecía rápidamente alrededor del mundo, comenzó a verse clara y rápidamente que el foco estricto en la Ingeniería de Software, no satisfacía las necesidades de negocio o sistemas intensivos en software. Una asesoría conducida por Jeff Perdue del Institute of Software Process Improvement (ISPI) mostró que la necesidad por un proceso de mejora de "sistemas" de ingeniería era inmediata y los resultados serían precisos. Finalmente varios modelos CMM fueron desarrollados para una gran variedad de disciplinas, aparte de la ingeniería de software. Estos modelos incluidos para la adquisición de software, la gestión de personas, desarrollo y la integración de producto y procesos.

Aunque estos modelos resultaron útiles para muchas organizaciones, el uso de múltiples modelos también se convirtió en un problema. Las organizaciones que deseaban centrarse en su mejora en todas las disciplinas tuvieron dificultades. Las diferencias entre los modelos específicos de cada disciplina, incluyendo sus arquitecturas, contenidos y enfoques, limitaban la habilidad de las organizaciones para enfocar sus esfuerzos en mejorar sus procesos exitosamente. Adicionalmente, la aplicación de múltiples modelos que no estaban consistentemente integrados dentro y a través de una organización, resultaba en altos costos en términos de capacitación, evaluaciones y actividades de mejora.

El proyecto CMMi fue formado para superar el problema de usar múltiples CMM. La misión del equipo del modelo CMMi fue combinar tres modelos:

SW-CMM: Capability Maturity Model for Software (v2.0 draft C).
Electronic Industries Alliance Interim Standard (EIA/IS 731).
Integrates Product Development Capability Maturyty Model (IPD-CMM v0.98)

En definitiva, el objetivo era integrar estos modelos en un único framework para su uso por organizaciones que persiguen en toda la empresa la mejora de sus procesos.

La necesidad de un modelo integrado se puede apreciar en como evolucionó CMMi en el set de modelos que representa hoy en día.

REFERENCIAS:

Introduction to the Architecture of the CMMI® Framework
Addison Wesley - CMMI for Development 3rd Edition Mar 2011
Addison Wesley Professional - CMMI for Services - Guidelines for Superior Service - 2nd Edition - Mar 2011
Practical Insight into CMMI

Mercado de Capitales

2012-01-22T15:55:00.000-08:00

El Mercado, en economía, es el medio (social o virtual) donde se realizan/propician un conjunto de transacciones o acuerdos de negocios entre compradores (demandantes) y los vendedores (oferentes) de un bien o servicio. En contraposición con una simple venta, el mercado implica el comercio formal y regulado, donde existe cierta competencia entre los participantes.

En otras palabras, debe interpretarse como la organización social a través de la cual los oferentes (productores y vendedores) y demandantes (consumidores o compradores) de un determinado tipo de bien o de servicio, entran en estrecha relación comercial a fin de realizar abundantes transacciones comerciales.

Los primeros mercados de la historia funcionaban mediante el trueque. Tras la aparición del dinero, se empezaron a desarrollar códigos de comercio que, en última instancia, dieron lugar a las modernas empresas nacionales e internacionales. A medida que la producción aumentaba, las comunicaciones y los intermediarios empezaron a desempeñar un papel más importante en los mercados.

Mercados financieros Es un mecanismo que permite a los agentes económicos el intercambio de activos financieros. En general, cualquier mercado de materias primas podría ser considerado como un mercado financiero si el propósito del comprador no es el consumo inmediato del producto, sino el retraso del consumo en el tiempo.

Mercado de bonos Es un mercado financiero donde los participantes compran y venden títulos de deuda, usualmente en la forma de bonos
Mercado de capitales Son un tipo de mercado financiero en los que se ofrecen y demandan fondos o medios de financiación a mediano y largo plazos. Frente a ellos, los mercados monetarios son los que ofrecen y demandan fondos (liquidez) a corto plazo.
Mercado de valores Son un tipo de mercado de capitales en el que se negocia la renta variable y la renta fija de una forma estructurada, a través de la compraventa de valores negociables. Permite la canalización de capital a medio y largo plazo de los inversores a los usuarios.
Mercado secundario Es una parte del mercado financiero de capitales dedicado a la compraventa de valores que ya han sido emitidos en una primera oferta pública o privada, en el denominado mercado primario.

El mercado de capitales, también conocido como mercado accionario, es un tipo de mercado financiero en los que se ofrecen y demandan fondos o medios de financiación a mediano y largo plazo. Su principal objetivo es participar como intermediario, canalizando los recursos frescos y el ahorro de los inversionistas; para que los emisores, lleven a cabo dentro de sus empresas operaciones de: financiamiento e inversión. Frente a ellos, los mercados monetarios son los que ofrecen y demandan fondos (liquidez) a corto plazo.

TIPOS DE MERCADOS DE CAPITALES

En función de los que se negocia en ellos:

Mercados de valores
Instrumentos de renta fija.
Instrumentos de renta variable.
Mercado de crédito a largo plazo (préstamos y créditos bancarios).

En función de su estructura:

Mercados organizados
Mercados no-organizados ("Over The Counter")

En función de los activos:

Mercado primario: el activo es emitido por vez primera y cambia de manos entre el emisor y el comprador (ej: Oferta Pública de Venta en el caso de renta variable, emisión de bonos en el caso de renta fija)
Mercado secundario: los activos se intercambian entre distintos compradores para dotar de liquidez a dichos títulos y para la fijación de precios.

Participantes del mercado de capitales

Dentro del mercado accionario intervienen diversas instituciones del sistema financiero que participan regulando y complementando las operaciones que se llevan a cabo dentro del mercado. Las siguientes cuatro entidades son las más imprescindibles:

Bolsa de Valores: Su principal función es brindar una estructura operativa a las operaciones financieras, registrando y supervisando los movimiento efectuados por oferentes y demandantes de recursos. Además, da fé de cotizaciones e informa al inversionista de la situación financiera y económica de la empresa y del comportamiento de sus instrumentos financieros.

Emisoras: Son entidades que colocan acciones (parte alícuota del capital social) con el fin de obtener recursos del público inversionista. Las emisoras pueden ser sociedades anónimas, el gobierno federal, instituciones de crédito o entidades públicas descentralizadas.

Intermediarios (Casa de Bolsa): Realizan las operaciones de compra y venta de acciones, así como, administración de carteras y portafolio de inversión de terceros.

Inversionista: Los inversionistas pueden categorizarse en persona física, persona moral, inversionista extranjero, inversionista institucional o inversionista calificado). Son personas o instituciones con recursos económicos excedentes y disponibles para invertir en valores.

En conclusión, el mercado de capitales es solo una parte de la economía que mueve cada país según la función que este ejerza.

REFERENCIAS:

La Mesa de Dinero, “Una Visión de Futuro” - (Enrique Pereira, 1999)
http://es.wikipedia.org/wiki/Mercado_de_capitales

Arquitectura de Software Empresarial & Servicios Financieros

2012-01-22T14:42:00.000-08:00

La mayoría de las empresas hoy en día no poseen una arquitectura formal (Gartner, 2003). La solución no es otra super inversión que provoque un Big-Bang en la organización. Si en un proyecto no se ha definido una arquitectura de sistema confiable, flexible y escalable, simplemente éste no debe proceder.

La arquitectura juega un papel fundamental al permitir que una organización cumpla con sus objetivos de negocio. Arquitectura tiene un precio (el costo de su desarrollo, cuidado), pero vale la pena por sí mismo generosamente al permitir la organización para lograr sus los objetivos con el sistema y ampliar las capacidades del software. La arquitectura es un activo que tiene un valor tangible a la organización de desarrollo más allá del proyecto para el cual fue creado. La arquitectura estrictamente desde un punto de vista de la ingeniería de software aporta tanto a proyecto de desarrollo, además de que el valor devuelto a la empresa.

La arquitectura de software en década del 90' surgió como un subcampo de la ingeniería del software , cuando se hizo ampliamente reconocida la idea de que conseguir la arquitectura correcta era un elemento clave para la creación de un sistema de software que cumpliera con los requerimientos. Tras esto se siguió una serie vertiginosa de las propuestas de anotaciones, herramientas, técnicas y procesos para apoyar el diseño arquitectónico y de integrarlo con las prácticas de desarrollo de software existentes. Y, sin embargo, a pesar de la existencia de este cuerpo de conocimiento, en la arquitectura de software existen aún muchos casos en los que no se sigue una práctica estandarizada.

Parte de la razón de esto ha sido una especie de polarización de opiniones sobre el papel que la arquitectura debe jugar. Por un lado es una escuela de pensamiento que defiende la arquitectura centrada en el diseño, en la que la arquitectura juega un crucial y esencial papel durante el proceso de desarrollo de software. La gente en este campo han tendido arquitectura para centrarse en los diseños arquitectónicos detallados y completos y bien definidos hitos y normas explícitas para la documentación de la arquitectura. En el otro lado es una escuela de pensamiento que menos énfasis arquitectura, con el argumento de que surjan naturalmente, como un subproducto de un buen diseño.

Es obvio que para la clase de sistema. La gente en este campo han tendido a centrarse en la minimización de diseño de la arquitectura como una actividad separada de la aplicación, y en la reducción o la eliminación de documentación arquitectónica.

Claramente, ninguno de estos campos tiene derecho para todos los sistemas. De hecho, la pregunta que uno debe plantearse es: "¿Cuánto diseño arquitectónico se requiere para desarrollar un sistema dado? "

En el libro, George Fairbanks se propone una respuesta: "Sólo Arquitectura suficiente." En un primer momento a esto podría ser: "Bueno, duh!", Porque ¿quién querría demasiado o muy poco. Como tal, proporciona una manera refrescante y no dogmático de enfoque de software arquitectura - con un enorme valor práctico.

Fairbanks señala que el criterio básico para determinar la cantidad de la arquitectura es suficiente la reducción del riesgo. Donde hay poco riesgo en un diseño, la arquitectura poco es necesario. Pero cuando dura problemas de diseño del sistema surgen, la arquitectura es una herramienta con la un enorme potencial. En concreto, se centra en la reducción de riesgos de ingeniería se alinea los beneficios con los costos, asegurando que el diseño arquitectónico se utiliza en situaciones donde se requiera cumplir con ciertas expectativas.

Naturalmente, hay un montón de cuestiones secundarias para responder. ¿Qué riesgos son los mejores dirigida a la arquitectura de software? ¿Cómo se aplican los principios de diseño arquitectónico para resolver un problema de diseño? ¿Qué escribir acerca de su arquitectura compromisos para que los demás saben lo que son? ¿Cómo se puede ayudar a asegurar que compromisos arquitectónicos son respetados por los ejecutores de abajo?

REFERENCIAS:

Enterprise Software Architecture & Financial Services Industry – Future Trends, Challenges & Frameworks - MIT [Ahmad Shuja, 2003]
Software Architecture in Practice 2nd Edition - The SEI Series in Software Engineering
Just Enough Software Architecture - [Fairbanks, 2010]

Red BIAN y una arquitectura estándar para la industria bancaria

2012-01-22T07:44:00.000-08:00

Establecida en 2008, la Red de Arquictectura de la Industria Bancaria (BIAN) es una asociación privada independiente, sin ánimo de lucro, que trata establecer y promover una arquitectura marco común para los problemas de interoperabilidad bancaria. El objetivo de BIAN es definir SOA y las definiciones semánticas para los servicios de TI en el sector bancario. La comunidad se centra en crear un panorama semántico estándar de servicios bancarios, y asegurar definiciones de servicios, niveles de detalle y límites de forma coherente. Esto ayudará a los bancos a conseguir una reducción de los costes de integración y a utilizar las ventajas de la arquitectura orientada a servicios.
Las instituciones financieras, los proveedores de software y los integradores de sistemas, junto con otros socios tecnológicos, están invitados a unirse a la asociación y jugar un papel como colaborador con otros líderes de la industria en la definición, construcción e implementación de la próxima generación de plataformas bancarias.

Banks need a flexible architectural model for the growth of banking services – one that enhances interoperability and reduces integration costs. The BIAN model is a Service Oriented Architecture with consistent service definitions, level of detail and boundaries. This makes it easier to choose and integrate commercially available products of different vendors.

By working together through BIAN, we can reduce integration costs, align IT with business objectives and therefore respond quicker to customer needs. The result: it will be easier to seamlessly integrate package solutions info your existing landscape.

Establecida en 2008, la Red de Arquictectura de la Industria Bancaria (BIAN) es una asociación privada independiente, sin ánimo de lucro, que trata establecer y promover una arquitectura marco común para los problemas de interoperabilidad bancaria. El objetivo de BIAN es definir SOA y las definiciones semánticas para los servicios de TI en el sector bancario. La comunidad se centra en crear un panorama semántico estándar de servicios bancarios, y asegurar definiciones de servicios, niveles de detalle y límites de forma coherente. Esto ayudará a los bancos a conseguir una reducción de los costes de integración y a utilizar las ventajas de la arquitectura orientada a servicios.

Las instituciones financieras, los proveedores de software y los integradores de sistemas, junto con otros socios tecnológicos, están invitados a unirse a la asociación y jugar un papel como colaborador con otros líderes de la industria en la definición, construcción e implementación de la próxima generación de plataformas bancarias.

Los miembros de BIAN son: ACI Worldwide Inc., Callataÿ & Wouters, Capital Banking Solutions, CGI, Commonwealth Bank of Australia, COREtransform, Credit Suisse, Deutsche Bank, Deutsche Postbank, FERNBACH, HCL Axon, IBM, ifb group, IKOR, Infosys, ING, innobis AG, kutxa, Microsoft, Rabobank,SAP, SunGard, Standard Bank of South Africa, SWIFT, Scotiabank Group, Temenos, UniCredit Group, Zürcher Kantonalbank

El gigante azul se convierte en el último miembro en unirse a la BIAN, organismo que busca establecer una arquitectura orientada a servicios (SOA) estándar en el sector financiero. IBM formará además parte del Consejo de Directores de la asociación.

IBM sigue impulsando su negocio, expandiendo y profundizando en sectores muy diversos de la economía internacional. Su última acción ha sido afiliarse a la BIAN, una red que busca fomentar los estándares dentro del sector financiero. Además de convertirse en afiliado de pleno derecho de la comunidad BIAN, Chae An, vicepresidente de soluciones de servicios financieros en IBM, tendrá un puesto en el Consejo de la asociación. Desde su creación en 2008, la misión de la BIAN ha sido establecer una arquitectura orientada a servicios (SOA) estándar en la industria bancaria.

La integración de IBM en el Consejo ha sido entendida desde la asociación como un catalizador para ofrecer estándares de mayor calidad a un ritmo más rápido, asegurando en última instancia el éxito en la industria. Asimismo, el gigante azul see une a una comunidad global de treinta expertos de las industrias mundiales de banca y software, incluyendo a empresas como ING, Commonwealth Bank of Australia, Credit Suisse, Microsoft, SAP, Infosys o SunGard. “Los estándares abiertos facilitan la interoperabilidad y aceleran la adopción de nuevas tecnologías que ayudan a las industrias a trabajar de manera más inteligente", señaló Chae An, vicepresidente de Soluciones de Servicios Financieros en IBM, tras dar a conocer esta noticia. "La colaboración de BIAN con grupos de la industria como Object Management Group y SWIFT demuestra su compromiso para hacer que sus modelos de banca otorguen más valor a sus miembros”. Por su parte, Steve Van Wyk, presidente del Consejo de BIAN, y CIO global de ING, comentó que la asociación está encantada de dar “la bienvenida a IBM a nuestra creciente red global de bancos, proveedores de software e integradores de servicios. Juntos seguiremos trabajando duro para establecer los estándares SOA de facto para el sector bancario mundial”.

BIAN, la red de arquitectura para la industria bancaria, ha dado la bienvenida a IBM como el miembro más reciente a su comunidad que promueve los estándares en la banca. Además de convertirse en afiliado de pleno derecho de la comunidad BIAN, Chae An, vicepresidente de soluciones de servicios financieros en IBM, tendrá un puesto en el Consejo de BIAN.

Desde su creación en 2008, la misión BIAN ha sido establecer una arquitectura orientada a servicios (SOA) estándar en la industria bancaria. Tras adquirir un impulso significativo – en 2011 BIAN ha recibido a nueve miembros nuevos, y ha lanzado su nuevo servicio BIAN Service Lansdcape– la organización está entrando en una nueva etapa de madurez. La integración de IBM en el Consejo, como destacado visionario de tecnología bancaria, es el catalizador para ofrecer estándares de mayor calidad a un ritmo más rápido, asegurando en última instancia el éxito en la industria.

“Los estándares abiertos facilitan la interoperabilidad y aceleran la adopción de nuevas tecnologías que ayudan a las industrias a trabajar de manera más inteligente", señala Chae An, vicepresidente de soluciones de servicios financieros en IBM. "La colaboración de BIAN con grupos de la industria como Object Management Group (OMG) y SWIFT demuestra su compromiso para hacer que sus modelos de banca otorguen más valor a sus miembros. A través de la comunidad BIAN, IBM seguirá trabajando para atender las necesidades de las instituciones financieras a través de soluciones basadas en estándares abiertos.”

Steve Van Wyk, presidente del Consejo de BIAN, y CIO global de ING, comenta: "Estamos encantados de dar la bienvenida a IBM a nuestra creciente red global de bancos, proveedores de software e integradores de servicios. Juntos seguiremos trabajando duro para establecer los estándares SOA de facto para el sector bancario mundial. La amplia experiencia de IBM en los modelos de la industria, los estándares abiertos y el sector de servicios financieros, permitirá a BIAN hacer grandes avances en la creación de un modelo común, de la que se beneficiará toda la industria. Como nuevo miembro del Consejo de BIAN, IBM apoya la visión de que la estandarización y la colaboración a través de nuestra industria es la forma más eficaz para simplificar la entrega de mejores servicios a nuestros clientes a menor coste. "

IBM se une a una sólida comunidad global de 30 expertos líderes de las industrias mundiales de banca y software, incluyendo a ING, Commonwealth Bank of Australia, Credit Suisse, Microsoft, Scotiabank, SAP, Callataÿ & Wouters, Infosys y SunGard. Los miembros están trabajando conjuntamente para desarrollar estándares que ayuden a los bancos a reducir significativamente los costes TI. BIAN ha publicado recientemente su versión 1.5 de BIAN Service Landscape, y documentos de apoyo, como marco de referencia para los bancos. Cada vez más miembros están adoptando los estándares que están emergiendo en la industria como forma de reducir los costes de integración TI mediante una mayor eficacia y flexibilidad organizativa.

Acerca de BIAN
Establecida en 2008, la Red de Arquictectura de la Industria Bancaria (BIAN) es una asociación privada independiente, sin ánimo de lucro, que trata establecer y promover una arquitectura marco común para los problemas de interoperabilidad bancaria. El objetivo de BIAN es definir SOA y las definiciones semánticas para los servicios de TI en el sector bancario. La comunidad se centra en crear un panorama semántico estándar de servicios bancarios, y asegurar definiciones de servicios, niveles de detalle y límites de forma coherente. Esto ayudará a los bancos a conseguir una reducción de los costes de integración y a utilizar las ventajas de la arquitectura orientada a servicios.

Las instituciones financieras, los proveedores de software y los integradores de sistemas, junto con otros socios tecnológicos, están invitados a unirse a la asociación y jugar un papel como colaborador con otros líderes de la industria en la definición, construcción e implementación de la próxima generación de plataformas bancarias.

Los miembros de BIAN son: ACI Worldwide Inc., Callataÿ & Wouters, Capital Banking Solutions, CGI, Commonwealth Bank of Australia, COREtransform, Credit Suisse, Deutsche Bank, Deutsche Postbank, FERNBACH, HCL Axon, IBM, ifb group, IKOR, Infosys, ING, innobis AG, kutxa, Microsoft, Rabobank,SAP, SunGard, Standard Bank of South Africa, SWIFT, Scotiabank Group, Temenos, UniCredit Group, Zürcher Kantonalbank

REFERENCIAS:
http://www.bian.org/content/
http://www.microsoft.com/presspass/press/2009/jul09/07-13bianpr.mspx
http://www.bpmcenter.cl/index.php/component/content/article/3-noticias/343-soa.html
http://www.finanzasybanca.com/index.php/Apuntes/ibm-entra-en-la-direccion-de-la-red-de-arquitectura-bancaria-bian.html

Ranking Top 40 Proveedores Core Bancario al 2011

2012-01-22T06:33:00.000-08:00

	Proveedor	Aplicativo	Más Información
1	FIS \| Fidelity National Information Services (FNIS)	Corebank, FIS Alltel Systematics, Sanchez Profile, Horizon ACBS (Advanced Commercial Banking System), Kordoba, ALLprofits, MiSER, BancPac, Metavante
2	Oracle Financial Services Software (formerly i-flex Solutions)	Flexcube; Microbanker; Finware
3	Infosys Technologies	Finacle
4	TEMENOS	T24; T24 for Microfinance and Community Banking (MCB) formerly eMerge; GLOBUS; TEMENOS CoreBanking (TCB)
5	TCS FS - Tata Consultancy Services Financial Solutions - formerly FNS	BaNCS - TCS BaNCS (formerly FNS Bancs - Financial Network Services B@NCS-24)
6	Fiserv	ICBS (International) \| Signature by Fiserv, - Fiserv CBS (US); Basys/Metabank; Catapult; Premier; Acumen
7	Misys	BankFusion Universal Banking, Equation, BankFusion Equation, Equation Islamic Banking, Midas Plus, BankFusion Midas(Bankmaster)
8	Sungard Ambit	Ambit EBS (Enterprise Banking Suite) core banking - Retail banking, Corporate banking (formerly System Access Symbols)
9	Silverlake Axis	Silverlake - SIBS, Silverlake Integrated Islamic Banking System (SIIBS)
10	Open Solutions Inc (OSI)	TCBS/TCCUS: DNA platform \| TCBS - The Complete Banking Solution, TotalPlus (outsourced) core banking, TCCUS - The Complete Credit Union Solution
11	SAP	SAP for Banking, Corebanking; SAP R/3
12	Jack Henry & Associates	Jack Henry Banking - SilverLake; CIF 20/20; Core Director for US market
13	Polaris	Intellect Suite - OrbiOne, BankWare; BankNow
14	Harland Financial Solutions	PhoenixEFE
15	Datapro Inc	Datapro eIBS (e-IBS) CORE
16	SAB	SAB AT universal banking system (formerly SAB2i) and Samic private banking
17	Nucleus Software	*FinnO*ne
18	Callatay & Wouters	Thaler
19	Olympic ERI Bancaire	Olympic
20	Path Solutions	iMAL
21	3i Infotech	KASTLE
22	Laser Soft Infosystems (LSI) (Polaris group)	Laser Panacea core banking, Probanker CB, Probanker PB
23	Neptune Software	Rubikon universal core banking system (Java platform - new 2008), Orbit microfinance retail banking, Equinox
24	CGI Group	RFS core banking + HORIZON CRM, Loan Origination (LOS), DMS
25	InfrasoftTech	OMNIEnterprise
26	BML Istisharat	ICBS (Integrated Computerized Banking System)
27	ICS Financial Systems Ltd. (ICSFS), formerly International Computer Systems (ICS)	ICS BANKS
28	Delta	Delta-Bank
29	TOP Systems	TOPAZ Banking, TOPAZ Microfinance, TOPAZ Trace
30	Cobiscorp \| Cobis Systems Corporation (Macosa SA, MicroBanx Systems merged)	COBIS Core Banking \| COBIS UBS (universal banking solution)
31	Alnova Financial Solutions	Alnova 'A la Carte'; Alnova Jetbank, Altamira
32	TietoEnator	TietoEnator Financial Solutions, PBS Core Banking (Nordic solution) - (includes the former AttentiV systems Summit)
33	Avaloq	Avaloq Banking System
34	Computer Sciences Corporation (CSC)	Hogan, CSC/IBS, Celeriti, K3000
35	Infopro	ICBA, eICBA
36	DataVision Software	Data Mate Core Banking (India) - Micro Mate microfinance, cooperative banking
37	Mindmill	BankMill
38	BankVision Software	Core BankVision
39	ITS - International Turnkey Systems	ETHIX total banking solution \| ITS Core Banking Solution (Phoenix for ME), ITS Islamic Banking Solution
40	TCS FS - Tata Consultancy Services Financial Solutions - formerly TKS-Teknosoft	TCS BaNCS private banking, QUARTZ core financial platform, Quartz Securities, Quartz Payments, e-Portfolio

REFERENCIAS:

http://www.inntron.com/core_banking.html

El Information Framework y el IBM IFW Financial Services Data Model (FSDM)

2012-01-22T05:25:00.000-08:00

El Information Framework (IFW) es un framework de arquitectura enterprise, originalmente concebido por Roger Everden en 1996. El Information Framework es una familia de datos, procesos y modelos para ayudar a las instituciones financieras a transformar sus arquitecturas cross-enterprise. Es utilizado para clasificar los entregables en las arquitecturas enterprise, del mismo modo que el Zachman Framework.

Vistal actual del Zachman Framework

En 1987 John Zachman propuso el Zachman Framework para describir la arquitectura de la información con 6 ~~preguntas~~ conceptos fundamentales:

Qué: relacionado con los datos e información.
Cómo: relacionado con los procesos.
Dónde: relacionado con la red y la ubicación.
Quién: relacionado con los actores y personas.
Cuándo: relacionado con el tiempo.
Por qué: relacionado con la motivación.

Según Everden [1996], en un estudio realizado en los 90', indicó la tremenda necesidad de integrar los conceptos mencionados, en un paradigma unificado y para la creación de una herramienta CASE que soporte el modelamiento de la arquitectura de la información.

El Information FrameWork (IFW) está basado en vistas del dominio de arquitectura, con tres vistas y diez columnas:

Vista de la Arquitectura de la Organización (Estructura, Estrategia, Habilidades).
Vista de la Arquitectura del Negocio (Datos, Funciones de negocio, Workflow, Soluciones).
Vista de la Arquitectura Tecnológica (Aplicaciones, Redes, Sistemas).

Cada dominio de la arquitectura es además visto en términos de los niveles de detalle (A, B, C, C', D). El objetivo y alcance del IFW es amplio, tanto como el Zachman Framework original, basado en las experiencias en la industria de servicios financieros.

El IBM IFW Financial Services Data Model (FSDM)

El propósito fundamental de la FSDM es definir los conceptos de negocio, para facilitar su comprensión y comunicación. Proporciona una vista de toda la empresa de los datos comunes a todas las organizaciones de servicios financieros. La FSDM está organozado en una estructura jerárquica, "top-to-bottom", o conceptual para el diseño físico, con múltiples capas de los modelos de contenido de negocios que contenga las definiciones de negocio estándar de la industria de los datos. Cada capa de la estructura contiene un modelo de contenido que ofrece datos más detallados sobre la base de la capa anterior.

El FSDM como parte del modelo BDW

La FSDM es un modelo genérico, la definición de datos que es ampliamente aplicable a cualquier organización de servicios financieros. La información que figura en el modelo de datos es independiente de la estructura organizativa y ha sido validado por múltiples fuentes dentro de la industria.

El modelo proporciona un marco para el desarrollo de unas estructuras de datos entre empresas que promueven el intercambio de información entre las aplicaciones de negocio. Ya que ofrece una visión de arriba hacia abajo desde una perspectiva empresarial, la FSDM proporciona un plan para el desarrollo de bases de datos, así como una herramienta para entender y comunicar los recursos de información empresarial de las actividades de negocios más importantes de una organización genérica de los servicios financieros.

REFERENCIAS:
http://en.wikipedia.org/wiki/Zachman_Framework
http://www.ibm.com/developerworks/rational/library/372.html
http://it.toolbox.com/blogs/architecting-information/why-information-framework-ifw-17045 (Roger Everden post)
http://www.globaldataconsulting.net/articles/technology-platform/ibm-ifw-financial-services-data-model-fsdm-beginners
http://www-01.ibm.com/software/sw-library/en_US/detail/Y964722E82030E35.html
http://www.tdan.com/view-articles/4140/

Soluciones de Core Bancario o "Core Banking"

2012-01-21T14:17:00.000-08:00

Hoy por hoy los bancos se encuentran en una encrucijada. El actual entorno económico, sumamente complejo, les somete a una gran presión, por lo que se ven obligados a efectuar agresivos recortes en materia de costos, y optimizar sus operaciones, al tiempo que se deben preparar para disfrutar de cierta ventaja competitiva cuando el ciclo económico cambie y se oriente de nuevo hacia el crecimiento.

Un sistema de Core Bancario según una definición de Gartner Group es un sistema back-end que procesa las transacciones diarias, actualizaciones de cuentas y otros registros financieros. Estos sistemas suelen incluir depósitos, préstamos y capacidades de procesamiento de créditos, con interfaces a los sistemas de contabilidad general y herramientas para la generación de reportes (Jasper Reports, Crystal Reports). El enfoque estratégico de en estos sistemas se basa en una combinación de la arquitectura orientada a servicios, y tecnologías de apoyo que crean arquitecturas extensibles.

Hoy en día, la mayoría de las entidades financieras utilizan las aplicaciones de "Core Bancario" para apoyar sus operaciones dado que el avance en la tecnología, especialmente en las tecnologías de la información han mejorado la eficiencia en la administración y control de los procesos y actividades de la banca.

Las soluciones de Core Bancario son aplicaciones que se basan en una plataforma que tiene por objetivo permitir a los bancos mejorar las operaciones, reducir costos, y prepararse para el crecimiento. La implementación de una solución empresarial modular, basada en componentes, facilita la integración de tecnologías bancarias existentes. Una arquitectura orientada a servicios (en inglés Service-Orientes-Architecture SOA) ayudará a los bancos a reducir el riesgo que puede derivarse de la carga manual de datos e información desactualizada, incrementa la gestión de la información y su revisión, y hace más fluido el negocio con la implementación de sistemas completos.

Es por esto que el Core Bancario representa el corazón de la operación financiera de los bancos, y la decisión de seleccionar una plataforma de última generación representa un reto en términos de flexibilidad, escalabilidad, funcionalidad e inversión, que esté totalmente alineada con la estrategia del negocio y que garantice la continuidad operacional a mediano y largo plazo.

Módulos más importantes considerados para una plataforma de Core Bancario flexible, para organizaciones de cualquier estructura y escala geográfica:

Cuentas Corrientes
Cajas de Ahorro
Depósitos a Plazo Fijo
Préstamos a Plazo Fijo
Descuentos
Administración de Límites
Garantías otorgadas
Garantías recibidas
Valores al cobro
Custodia y administración de valores
Ordenes de pagos y transferencias
Venta de cheques de viajeros

Cajas de seguridad
Mesa de Dinero
Mercado de Capitales
Cambios (Contado / Futuro)
Cartas de Crédito de Importación
Cobranzas de Importación
Cartas de Crédito de Exportación
Cobranzas de Exportación Soporte SWIFT
Información y reportes a los Organismos de Regulación y Contralor
Información y reportes a la Casa Matriz
Información Gerencial (MIS)
Contabilidad (Cumpliendo con cambios normativos e IFRS)

Los sistemas de información son uno de los activos más destacables de las instituciones financieras contemporáneas y aquellos considerados "Core" resultan especialmente importantes y son un ejemplo claro de capacidades distintivas (Gestión Estratégica) entre entidades, ya que de ellos depende la facultad de una determinada institución para atraer clientes, prestarles sus servicios y conservarlos.

¿Debemos sustituir nuestro sistema de Core Bancario?
La decisión sobre sustituir un sistema de Core Bancario, y el momento y la forma de llevar a cabo su reemplazo, sea posiblemente una de las decisiones más importantes que tenga que tomar el CIO de un banco. Por tanto es crucial escoger el momento y el enfoque más adecuados para minimizar los riesgos y maximizar las ventajas a largo plazo que de dicha sustitución se derivarán para la empresa.

Habitualmente dos son los criterios que determinan la decisión sobre el llevar a cabo proyectos TI de sobre el cambio en la plataforma de Core Bancario:

Por un lado cuando el costo total de propiedad de los sistemas resulta insostenible, y/o cuando las capacidades de estos sistemas suponen un serio obstáculo para la competitividad de la institución, para su crecimiento y para la consecución de altos niveles de rentabilidad. Por desgracia la complejidad de los sistemas básicos de la mayoría de los bancos se ha ido incrementando a medida que estos añadan estratos de funcionalidad para adaptarse a las cambiantes necesidades de su ámbito de actividad (enfoque al cliente, multicanalidad, entre otros). El resultado de esta situación son sistemas que requieren de un mantenimiento complejo y con un costo muy elevado.
En el actual entorno económico, este alto costo en la evolución y el mantenimiento de dichos sistemas de información con, en general, muchos años de vida útil ya no son sostenibles, como lo era en épocas de fuerte crecimiento. Es más, las necesidades de negocio de la mayoría de los bancos están experimentando cambios muy rápidos, y las mejoras y adaptaciones que se requerían en estos antiguos sistemas de información no proporcionan la funcionalidad que permite a estas entidades alcanzar sus objetivos financieros, ni en tiempo, ni a un costo razonable.

Junto con este costo, otro gran motivo para aplazar la decisión de cambiar los sistemas de core básicos es el riesgo. Pero hoy en día, sustituir estos sistemas básicos resulta mucho más seguro que en el pasado. De hecho, dada la incertidumbre y la rapidez de los cambios que se están produciendo en la economía en este momento, en realidad la opción más arriesgada podría ser mantener dichos sistemas tal y como están. El riesgo es, sin lugar a dudas, un elemento inherente a todas las iniciativas relativas a los cambios de sistemas. No obstante, la aparición de paquetes de software de core bancario significa que los bancos ya no tienen que crear nuevos sistemas de la nada como hicieron hace décadas, cuando desarrollaron sus sistemas básicos. Ello minimiza significativamente los riesgos de que la actividad de la empresa de vea alterada, y reduce el tiempo y el costo de las iniciativas de sustitución de estos sistemas básicos.

Los actuales enfoques graduales y secuenciales de estos procesos de estos procesos, incluso la capacidad de cambio selectivo de capacidades clave, ayudan a minimizar la disrupción en el negocio. Así se facilita la continuidad de los mismos, otro de los elementos clave de preocupación a la hora de abordar este tipo de transformaciones. Además, los nuevos modelos industrializados de delivery, las herramientas avanzadas migración de datos y ejecución de proyectos, así como unos equipos de profesionales con gran experiencia en los procesos de transformación de los sistemas core de los bancos, ayudan a reducir tanto los costos como los riesgos asociados a este tipo de iniciativas.

Por otra parte, los nuevos modelos globales de obtención de recursos en países con menos gasto (offshoring) mitigan asimismo los riesgos y los costos que supone la sustitución de plataformas de Core Bancario.

De esta forma, la transformación de los servicios de core bancario debería orientarse a la consecución de dos ventajas competitivas:

mejora de la eficiencia y la innovación de los productos y los servicios para impulsar el crecimiento de los beneficios y

reducción de los costos totales de procesamiento de las operaciones. En muchos casos dicha transformación es crucial para conseguir un incremento sustancial en la eficiencia operativa, aumentar el potencial de crecimiento, responder a las necesidades de los clientes en constante evolución, y mejorar la gestión del riesgo.

REFERENCIAS:

http://www.financialtech-mag.com/000_estructura/index.php?ntt=11105&vn=1&sec=4&idb=177

http://www-01.ibm.com/software/cl/industry/banking/

http://www.bantotal.com/home/index.asp

http://www.nasoft.com/site/Home/Soluciones/Portecnolog%C3%ADa/CoreBancario/tabid/97/Default.aspx

http://www.fischile.cl/index.php?option=com_content&view=article&id=5&Itemid=14

http://www.alide.org.pe/fn11_fin_rev4_coreBancoldex.asp

http://financiablog.gilmartinspain.com/archives/1