| |
RAZONES
Tanto las organizaciones públicas como las privadas están rediseñando y aligerando sus procesos empresariales. poniendo un énfasis creciente en el cliente. El éxito de estas iniciativas depende de la compresión que se tenga del propio éxito de esta iniciativas depende de la comprensión que se tenga del propio cliente, esto es, de sus preferencias, comportamientos y necesidades, así como de la capacidad de la compañía para responder adecuadamente a ellas. En esta situación, la mayoría de las organizaciones disponen de abundante información sobre la que trazar sus proyectos. Desafortunadamente, si la infraestructura existente no dispone de los medios para la creación, uso, gestión, acceso y puesta a disposición de los datos relevantes, y todo ellos se hace de manera efectiva, la organización verá totalmente frustrados los esfuerzos por capitalizar su base informativa.
Ni los intentos de automatización fragmentada, ni los pedidos unilaterales de aplicaciones montadas sobre grandes sistemas, ni las plataformas físicas incompatibles, ni los programas informáticos dispares, ni los datos inaccesibles, satisfacen las necesidades para que los sistemas informáticos sean un componente esencial, indispensable y estratégico del servicio prestado, y permitirán cumplir los objetivos empresariales y de servicio de la mayoría de las organizaciones. Se hace cada vez más necesaria una revisión de la metodología de la planificación, para tener en cuenta las relaciones entre planificación empresarial e infraestructura técnica.
Es muy importante que se plantee cumplir con las exigencias de:
— satisfacer las necesidades de los clientes;
— responder a los cambios de las estructuras organizativas;
— obtener ventajas de las concepciones de sistemas abiertos;
— homologarse con los estándares industriales existentes;
— proporcionar sistemas físicos, programas informáticos y recursos de datos que sean distribuidos y accesibles, y estén debidamente coordinados;
— apoyar a lo procesos de rediseño;
— responder a las exigencias de cambio;
— ser fácil de usar, y
— reconocer la importancia de los datos como recursos de la organización.
Desde una perspectiva puramente tecnológica la mayoría de las formas de organización de sistemas informativos reconocen que los datos necesitan ser gestionados, pero pocas organizaciones llegan a darse cuenta de que el conocimiento, que reside en las bases de datos de la organización, puede suministrar los medios para hacer avanzar a la empresa de una manera más rápida, adelantando a sus competidores en este proceso. La primera empresa de un sector industrial que reconozca y explote el valor de un tipo determinado de información, que a menudo estará también disponible para el resto del sector, ganará ventaja competitiva sobre las demás.
La Gestión de los Recursos Informáticos (GRI) concibe a la empresa con una visión amplia, no plegándose estrechamente a las exigencias de ningún grupo o departamento en particular.
Todo plan estratégico de GRI contiene una descripción las posibilidades y exigencias de la información dentro de la empresa, con la intención de satisfacerlos y proporcionar las siguientes prestaciones:
— desarrollo de sistemas destinados a apoyar los objetivos estratégicos y operativos;
— incrementar la integración de tecnologías, lo que permitirá compartir mejor la información para cubrir las cambiantes necesidades de los que hayan de tomar las decisiones;
— identificar y adoptar las normas tecnológicas apropiadas sobre la informática, que permitan minimizar la dependencia de los proveedores particulares de sistemas físicos y programas informáticos;
— identificar las oportunidades para mejorar la relevancia y adecuación de la información suministrada y de las actividades llevadas a cabo;
— una infraestructura tecnológica que apoye el plan estratégico de negocio;
— minimización de datos o procesos duplicados, y eventualmente inconsistentes entre sí, dentro del conjunto de sistemas informáticos de la empresa;
— ordenación en el tiempo de los proyectos a ejecutar, y
— mayor justificación económica de las actividades de mantenimiento y de desarrollo de sistemas.
La información es un activo que no tiene precio. La GRI es la propia estrategia seguida por la empresa, así como su posición respecto a las metas. objetivos y retos a los que se enfrenta. Para los propósitos de esta Declaración, se supone que la organización correspondiente ha:
ALCANCE DE ESTA DECLARACIÓN
1. La base que fundamenta el proceso de planificación estratégica de la GRI es la propia estrategia seguida por la empresa, así como su posición respecto a las metas, los objetivos y retos a los que se enfrenta. Para los propósitos de esta Declaración, se supone que la organización correspondiente a:
— definido qué de empresa desea ser;
— identificado sus procesos empresariales básicos;
— identificado y analizado los factores que resulten críticos para su éxito futuro;
— definido sus mercados;
— estudiado el sector industrial al que pertenece y sus competidores, y
— identificado sus fortalezas y debilidades.
2. Los principios descritos en esta Declaración son amplios pero fundamentados; orientaciones sobre las preferencias en la gestión o en la dirección, objetivos y conceptos para guiar el desarrollo y uso de los ordenadores, equipo de telecomunicaciones y programas informáticos que apoyen el entorno de la GRI. Hay circunstancias que pueden indicar que la empresa debe seguir una determinada dirección, por ejemplo comprar o construir sus propias aplicaciones, o bien subcontratar la función informática. En tales casos, la metodología sugerida en esta Declaración suministrará un enfoque de sistemas y un marco apropiado para llevar a cabo el proceso de toma de decisiones.
3. Los principios están sujetos a modificación, de acuerdo con el tamaño y el tipo de actividad, y también a medida que la tecnología va evolucionando o las exigencias de la empresa cambian. La adopción de estos principios tendrá un impacto profundo en la gestión de la tecnología, la estructura y configuración de los medios técnicos, así como en la entrega de servicios responsables y valiosos a los clientes y a los consumidores.
4. Partiendo de la utilización del plan estratégico de actividades de la empresa, esta Declaración tiene como objetivo delinear el proceso de creación del plan de GRI. El plan de GRI habrá de ser una herramienta de ayuda en el diseño e implantación de los sistemas informáticos necesarios para apoyar al plan general de la empresa.
5. Esta Declaración contiene una discusión sobre los objetivos de la GRI, los conceptos fundamentales implicados en la misma y las funciones y responsabilidades asociados con ella. También describe las siguiente fases, correspondientes al proceso de planificación de la GRI:
— traducción del plan estratégico de actividades de la empresa en necesidades estratégicas de información;
— construcción de modelos empresariales basados en las necesidades estrategias de información;
— construcción de las arquitecturas objetivo que se deriven de los modelos empresariales;
— creación de un plan estratégico de implantación que especifique cómo implantar las arquitecturas objetivo, y
— revisión posterior a la implantación, para asegurar que la GRI está efectivamente consiguiendo sus objetivos enunciados.
HACIENDO EMPRESAS BASADAS EN EL CONOCIMIENTO
6. De acuerdo con Vita Cassesse, Vicepresidente de Sistemas de Investigación de Mercados del grupo farmacéutico Pfizer Inc., con sede en New York: "La tecnología es sólo un pequeño componente de un continuo... no se puede gestionar eficazmente la información sin saber cómo y porqué se necesita comunicarla" (1). Igualmente importantes es la necesidad de reconocer que la tecnología informática no puede, por sí misma, transformar simples datos en conocimiento Thomas H. Davenport, Director del Programa de Gestión de los Sistemas Informáticos de la Universidad de Texas, en Austin, afirma que "Nadie puede decir que no está interesado en cómo hacer un uso efectivo a menos que se tenga un cierto grado de dominio sobre este particular" (2).
7. En el entorno actual de empresa basada en el conocimiento, no existe ninguna persona que desempeñe funciones relacionadas con la tecnología informática, o bien gestione una empresa u otro tipo de organización, que no piense en la información como un activo. El dato de si la persona en concreto está en una empresa técnica o pertenece al sector de la informática es irrelevante, porque el problema real en todo caso es el mismo, y se centra en cómo ensamblar una infraestructura, con el mejor y más apropiado contenido (esto es la información) a través de la cual puedan fluir las soluciones a las necesidades de la organización en cuestión. Este es el reto más importante cuando el entorno empresarial, tan volátil, de nuestros días converge con la dinámica del entorno tecnológico moderno.
8. Muchos aspectos o sucesos que caracterizan el mundo empresarial de hoy pueden tener un efecto profundo sobre cómo debe, la organización, sincronizar la actividad y su tecnología. En muchos casos, tales sucesos son externos e incontrolables. No obstante, es responsabilidad de cada organización incorporar estas circunstancias no planeadas (y, a menudo, no deseadas) en su actividad empresarial diaria. Con el objeto de suministrar el apoyo necesario para poder aplicar las recomendaciones de esta Declaración en la dirección apropiada, se va a proceder a discutir, a lo largo de los próximos párrafos, algunos de los retos más significativos.
El nuevo papel de la tecnología informática
9. Hay retos fundamentales que se están desarrollando, dentro
de la aplicación de los ordenadores en la empresa, cada uno de los cuales afecta
a un nivel diferente de la organización. La tecnología informática apoya la
implantación y mantenimiento de una estructura de equipo de alto rendimiento,
permitiendo que la organización funcione como un conjunto de empresas
integradas, a pesar de la posible autonomía de sus unidades componentes, así
como alcanzar y desarrollar nuevas relaciones con otras organizaciones externas,
para convertirse así en una especie de empresa extendida.
10. La empresa virtual (esto es, un enfoque radical de la
transformación organizativa de la que resulta una entidad flexible, capaz de
responder y efectiva, diseñada para satisfacer las demandas de un mercado que
radica físicamente en muchos puntos distantes), no hubiera sido posible sin la
sofisticada tecnología informática con la que hoy se cuenta. " A diferencia de
los productores de ayer, la corporación virtual puede usar la tecnología
informática para superar las barreras impuestas por el tiempo y por la
distancia... Al final de este siglo, el entorno informático tenderá a carecer de
restricciones, y la tecnología será suficientemente portátil como para pasar a
formar parte del bagaje diario trabajo de cada persona... Ya hoy, incluso la
tecnología básica, es más que una herramienta: es un miembro ubicuo del equipo
de trabajo, que lleva a cabo de tareas del equipo rutinario y repetitivo, y se
ocupa de acumular información acerca de de los procesos, de los productos o
servicios y del eventual cliente. Con el paso del tiempo, la explotación
coherente de esta información puede dar a la organización una ventaja
competitiva, suponiendo que ésta puede y quiere tomar el camino apropiado"
(3).
La preponderancia de los programas informáticos ya
elaborados
11. Hoy muchos paquetes de programas de ordenador están
diseñados específicamente para aplicaciones concretas, y para empresas
integradas verticalmente, siendo independientes de los equipos físicos
utilizados, es decir, que pueden ser instalados en muchas plataformas diferentes
y en equipos de cualquier tamaño. En consecuencia, en muchos casos es más
efectivo, desde el punto de vista de los costes, adquirir tales programas
estandarizados que desarrollar aplicaciones con códigos propios. Lo mejor que se
puede hacer tales situaciones es perseguir, de forma agresiva si es preciso, la
documentación respecto a las exigencias que suponen tales programas, antes de
proceder a seleccionar uno concreto. En tal caso contrario, es siempre fácil
seleccionar el programa de aplicación que cumple la mayoría de las
características deseadas, independientemente de si cumple o no las exigencias de
procesamiento de la organización , o si puede o no acomodarse a sus necesidades
informativas. Si bien los programas ya elaborados pueden, en la mayoría de los
casos, adaptarse a todas las necesidades, en el caso de que las modificaciones
exigidas sean muchas, puede quedar poco de los códigos originales del programa
tras la adaptación, que en consecuencia podría resultar costosa y difícil de
mantener. No obstante "comprar en lugar de construir" es el estilo de
comportamiento que muchas organizaciones eligen cuando necesitan instalar nuevas
aplicaciones informáticas.
Importancia de la flexibilidad tecnológica
12. Existen tres tipos de desarrollos tecnológicos, distintos
pero relacionados entre sí, que son claves para la flexibilidad y para la
aceptabilidad:
— Sistemas abiertos, que están basados en estándares
independientes de cualquier proveedor, y están comúnmente disponibles en el
mercado. Debido a la oportunidad que representan de migración hacia nuevos
sistemas y de poner al día tecnologías basadas en las propias exigencias de la
organización, la elección de una política de sistemas abiertos puede producir
una reducción de los costes relacionados con las tecnologías informáticas y
suministrar determinados beneficios que representen valores añadidos, tales
como un riesgo reducido de dependencia del proveedor, flexibilidad en la
arquitectura, mejora de la interoperatividad entre aplicaciones, fácil
migración hacia las eventuales novedades, tecnologías innovadoras y mucho más
poder de decisión a la hora de elegir programas ya elaborados.
— "Sistemas cliente-servidor, que se construyen a
partir de componentes ya preparados y estandarizados, y que pueden expandirse
a medida que sea necesario y ser distribuidos a medida que resulte apropiado
para las necesidades de la organización"
(4).
— "Sistemas orientados hacia objetos, que son
construidos a partir de un modelo común extensible. Los objetos con funciones
específicas se utilizan para construir el sistemas deseado. Las alteraciones
de un sistema de esta clase pueden ser hechas fácilmente, ya sea para
acomodarlo a las exigencias de las actividades cambiantes o para incorporar
(5) determinadas mejoras al mismo".
Emergencia de nuevos sistemas de trabajo
13. La tasa de cambio organizativo es acelerada. Diariamente
nos encontramos con nuevas maneras de hacer las cosas, nuevas herramientas para
utilizar, nuevas cosas para hacer y diferentes personas para llevarlas a cabo. A
medida que las empresas programan su propia reingeniería para adaptarse al
entorno, aparecen nuevos problemas en los planes estratégicos que deben
desarrollar, y cada uno de ellos demanda un nuevo modelo de tecnología
informática, como por ejemplo:
— productividad de los trabajadores del conocimiento y de
los trabajadores dedicados a los servicios;
— calidad;
— capacidad de respuesta;
— globalización o mundialización;
— subcontratación;
— posibilidades de asociación, y
— responsabilidad social y medioambiental
14. Las organizaciones están llevando a cabo las acciones y
tomando decisiones difíciles, que con frecuencia conducen a cambios
irreversibles. El cambio continuo es una parte más de los programas de gestión
de la calidad; los cambios radicales periódicos son una parte de los procesos de
reingeniería de las empresas; la reducción de la mano de obra es una parte del
adelgazamiento de las compañías; y, por último, el cambio desde el trabajo
personal al de trabajo informático en grupos es parte del movimiento hacia la
potenciación del trabajo en equipo. No hay duda de que la supervivencia será
difícil si no se examinan y modifican de forma importante las estructuras
organizativas, el contenido de las tareas, las políticas y prácticas relativas a
los recursos humanos y, desde luego, la provisión de una infraestructura
tecnológica que solucione los problemas de acceso a la información, que es el
ingrediente clave de las empresas actuales.
15. Los nuevos sistemas de trabajo han de sacar partido de
las relaciones sinérgicas que se pueden dar entre las personas, los procesos y
la tecnología. Si se ha de alcanzar el objetivo de mejorar la productividad, la
nueva tecnología. Si se ha de alcanzar el objetivo de mejorar la productividad,
la nueva tecnología y los nuevos sistemas de trabajo deben cambiar la naturaleza
de las tareas a realizar. La cultura corporativa, cualquiera que sea su
filosofía, quedará afectada a medida que el flujo de trabajo y las
responsabilidades de los empleados empiecen a cambiar. La dirección de la
empresa debe, por último, evaluar este nuevo entorno empresarial y responder
adecuadamente a las reacciones de los empleados.
16. Así como esperamos que el uso de la tecnología sea obvio,
debemos centrarnos en desarrollar en los empleados una intuición que les permita
sacar al máximo partido a la tecnología. Una cuestión a resolver es qué se puede
esperar razonablemente del comportamiento de los empleados. Para desarrollar el
nivel necesario de conocimiento en el personal, éste debe ser sometido a
situaciones de aprendizaje. Los recursos técnicos por sí solos no pueden
suministrar el tipo de entrenamiento y habilidades que son necesarias en la
empresa para manejarlos. Por eso, es extremadamente importante que los
profesionales de los recursos humanos sean socios en estos programas de
desarrollo de personal en entornos tecnológicos.
PAPEL DE LA GESTIÓN DE LOS RECURSOS INFORMÁTICOS (GRI)
17. En el pasado, la información era considerada sólo un
recurso interno, pero hoy, los datos de una determinada empresa pueden ser parte
de una base de datos de conocimientos de tipo nacional o internacional. Por
ejemplo, es de esperar que muchos escenarios de reforma sanitaria lleven a
sistemas nacionales o locales de informática sanitaria, en los que comparta un
lenguaje común
(6).
18. El plan estratégico de la organización que describir cómo
van a se los avance y desarrollos en el futuro. El plan estratégico de GRI debe
centrarse en cómo la información y la tecnología pueden apoyar las metas y
objetivos marcados por la estrategia de la empresa. Las estrategias de GRI han
de ser creativas y flexibles para cubrir las necesidades actuales y las
potencialmente expandidas en el futuro. Es necesario para la organización que el
plan IRM se mire en el espejo de la estrategia corporativa; por ejemplo, si la
estrategia de la empresa pone énfasis en el servicio al cliente, el plan de GRI
también debe hacerlo.
19. La GRI es una metodología de planificación de sistemas
informáticos de carácter estratégico que pone énfasis en la importancia de la
información como un recurso más de la empresa. Se centra en el diseño,
implantación y mantenimiento de una tecnología, de unos procesos y de un sistema
de información equilibrados. En el entorno GRI, la tecnología no se concibe como
un fin en sí misma, sino como un medio para ayudar a que la empresa haga mejor
las cosas, así como de un modo más rápido y más barato
(7).
20. Para una organización actual, no es infrecuente tener un
sistema informático de clientes para gestionar la cartera de clientes, ni un
sistema informático contable para gestionar su cartera de inversiones
financieras, ni un sistema informático de personal y nóminas para gestionar toda
la información referente a los empleados, ni un sistema informático de control
de almacenes para gestionar sus inversiones en materias primas. Todos estos
detalles sobre la organización, los hábitos de compra de sus clientes, las
fluctuaciones de precios de los proveedores, las diferencias de cambio en moneda
extranjera, etc., proporcionan información que podría ser utilizada para obtener
muchas ventajas. GRI es el término utilizado para describir la función que
supone gestionar, organizar y coordinar los recursos consistentes en datos, para
que apoyen mejor las actividades de la empresa
(8). En este contexto, los
sistemas de información están considerados como el esqueleto de los recursos de
datos de valor para la organización, que facilitan los medios para emprender
esas actividades.
21. Un sistema informático es un conjunto de componentes
relacionados entre sí, esto es, ordenadores, datos, recursos humanos,
telecomunicaciones, etc., con múltiples relaciones e interacciones entre ellos.
Los sistemas de gestión informática que pueden llamarse efectivos son el
producto de un entorno GRI cuidadosamente construido.
22. Con frecuencia, es difícil discernir dónde terminan los
sistemas informáticos y dónde empieza el entorno. Para el resto de la década de
los noventa es probable que el entorno en el que se plantea, diseña y desarrolla
la GRI se caracterice por tener unas prioridades complejas y conflictivas, por
causa de fenómenos como la reingeniería de procesos, la gestión de la calidad
total, la reducción del tamaño de las empresas, las fusiones, las adquisiciones
y la volatilidad económica general. Este hecho sólo sirve para incrementar
la necesidad de un enfoque de sistemas para el cambio, es decir, uno que pueda
suministrar un marco estable en el que los cambios puedan tener cabida. La GRI
suministra suministra los principios, parámetros y normas que definen el entorno
en el que la tecnología informática pueda organizarse debidamente, desarrollando
al mismo tiempo los sistemas de información.
OBJETIVOS DE LA GRI
23. EL objetivo fundamental de la GRI es asegurar que los
sistemas informáticos de la organización prestan apoyo a la dirección
estratégica y a los planes de actividad que lleva a cabo, realzando la calidad,
a los planes de actividad que lleva a cabo. realzando la calidad, aplicabilidad,
accesibilidad y valor de los recursos informativos de la empresa. Su éxito
potencial en cualquier organización depende de la aceptación de cuatro
principios fundamentales:
— Los datos son recursos valiosos que necesitan una gestión
apropiada.
— Existe la posibilidad de compartir la mayor parte de los
datos.
— La habilidad para compartir y usar más eficazmente los
datos es un factor crítico de éxito para muchas empresas.
— Los sistemas informáticos deben incorporar una visión
amplia de la empresa.
24. Un programa efectivo de e GRI ha de contemplar una
vigilancia continua sobre el entorno, para detectar las oportunidades que vayan
a favor de las actividades de la organización. Los planificadores de la
tecnología informática deben poseer una concepción estratégica de cómo los
sistemas de información pueden incrementar las oportunidades disponibles para la
organización, y también deben saber cómo extender los límites tradicionales de
la empresa para incluir enlaces con los recursos informativos de los clientes y
de los proveedores.
25. David Norton apunta, en el capítulo de su libro
denominado "Paso a paso"
(9), que "Los límites tradicionales carecen de sentido.
En la organización del futuro, los componentes básicos serán los mismos, pero
los límites del sistema diferirían, al igual que las relaciones entre las partes
internas del mismo".
26. Las organizaciones deben poner énfasis en el plan
estratégico de GRI para obtener una ventaja competitiva, por cuanto están
inmersas en una era de automatización creciente y competición a escala mundial.
Los sistemas de información pueden ayudar a dar a las funciones de la empresa un
mayor desarrollo, a mejorar la toma de decisiones de gestión, a crear nuevos
productos y actividades y a promover las relaciones con proveedores y clientes.
DESARROLLO DE UN PLAN ESTRATÉGICO DE GRI
27. La meta última de un plan estratégico de GRI efectivo es
el diseño, puesta en funcionamiento y mantenimiento de un entorno de recursos
informáticos integrados sin aristas, que responda correctamente a la necesidad
de flujos de información entre las diferentes funciones, a la vez que contenga
la flexibilidad y adaptabilidad necesarias para responder al cambio incesante en
la tecnología y en el mundo empresarial. La exigencia a plantear en este plan es
que proporcione un conjunto de posibilidades de trasporte de datos, y conexiones
en la gestión de los mismos, que sean susceptibles de ser utilizadas por cada
función dentro de la empresa, pero que a la vez no sean exclusivas ni propiedad
de ninguna de ellas
(10). Sin un plan así no habrá objetivos, ni medidas ni, a
la postre, se podrán obtener resultados.
28. Hay tres etapas clave en la planificación que precede a
la introducción de las técnicas de GRI en una organización:
1) Determinación de las exigencias
estratégicas para los recursos informáticos.
2) Evaluación del entorno existente.
3) Diseño de la GRI.
29. Como se muestra en la Ilustración 1, el proceso de
planificación comienza con una definición de la dirección que va a seguir la
empresa, lo que constituye el fundamento de todas las etapas subsiguientes. La
planificación estratégica de la actividad de la organización asegura que ésta
comprende sus factores críticos, así como qué debe haber bien para tener éxito y
cómo debe medirse el grado de éxito alcanzado. Por su parte, el proceso de
planificación estratégica proporciona una oportunidad para identificar las áreas
vulnerables, que deben ser objeto de una supervisión más estrecha, y deben estar
sujetas a controles más estrictos. Todo esto ayuda a la organización a trazar su
curso futuro. Los factores críticos para alcanzar el éxito, así como los
criterios de medida utilizados, pueden variar de una organización a otra, y
pueden también cambiar con el tiempo para cada entidad en particular,
dependiendo del entorno empresarial y de la dirección que lleve ésta. Los
ejemplos típicos de las áreas en la que una organización debe hacer
correctamente las cosas para tener éxito, en la próxima década, son el servicio
al cliente, el desarrollo de nuevos productos y el control de costes.
30. La estrategia empresarial guía el proceso de
determinación de qué información requiere la empresa para apoyar sus objetivos,
así como si el entorno existente (sistemas, procesos, información, estructura
organizativa, etc) apoya o puede apoyar, la consecución de los objetivos
planteados para la empresa.
31.Las cuestiones tecnológicas se abordan en la tercera fase,
donde se diseña la infraestructura de la organización. El esquema diseñado toma
la forma de un conjunto de "arquitecturas objeto", esto es, arquitectura de
sistemas y recursos, arquitectura de aplicaciones y arquitectura técnica, cada
una de las cuales describe un componente particular de la infraestructura a
construir. Este plan es conceptualmente similar a los planos que se utilizan en
arquitectura, y se ocupa de describir qué sistemas físicos, qué programas
informáticos y qué bases de datos son necesarias para cumplir con los requisitos
estratégicos de carácter informático previamente identificados. Las
arquitecturas objetivo sirven también para guiar el diseño de la infraestructura
organizativa y del plan de recursos y sistemas.s.
30. La estrategia empresarial guía el proceso de
determinación de qué información requiere la empresa para apoyar sus objetivos,
así como si el entorno existente (sistemas, procesos, información, estructura
organizativa, etc) apoya o puede apoyar, la consecución de los objetivos
planteados para la empresa.

32. Este conjunto de arquitectura objetivo apoya el
desarrollo del plan estratégico de GRI, el cual a su vez asegura la tecnología
apropiada y la infraestructura de la información para potenciar los objetivos
elegidos. también articula cómo la empresa puede hacer el uso más efectivo de la
información, de los ordenadores, de la tecnología de las bases de datos, de las
herramientas de apoyo a la decisión y de las telecomunicaciones, en combinación
con otros recursos que también contribuyen a llevar a cabo su misión como
organización. El plan de GRI refleja el enfoque de las actividades de la
organización, centrada su énfasis objetivos y metas tales como el servicio al
cliente, llegar a ser el proveedor más económico, en la expansión y en la
descentralización, estableciendo claramente cómo la organización GRI puede
apoyar a la finalidad que persigue la empresa.
33. Los siguientes principios guían el desarrollo de una
estrategia GRI efectiva:
— Debe estar ligada a la estrategia de la empresa.
— Los procesos relacionados con varias funciones a la vez
son el eje central de la dimensión planificadora.
— La infraestructura tecnológica debe representar un "modelo
de la actividad empresarial".
34. Una vez hay sido diseñado entorno GRI, se desarrolla el
plan de actuación y, como es de carácter iterativo, según se muestra en la
Ilustración 1, irá seguido de un ciclo de revisión. Puesto que el panorama
económico, de los mercados y de la tecnología informática cambia en intervalos
de 12 a 18 meses, es importante repetir este ejercicio al menos cada dos años.
Todo el proceso de planificación e implementación de la GRI es iterativo, y la
duración de los ciclos depende de las exigencias empresariales, los cambios en
el entorno y los avances de la tecnología informática. Si el entorno GRI es un
espejo de la empresa, los ciclos de revisión no se deben abandonar, de forma que
los ajustes del entorno se lleven a cabo cuando sean necesarios.
Determinación de las exigencias estratégicas en cuanto a
recursos informáticos
35. Es importante identificar las iniciativas concretas que
puedan ayudar a obtener una visión general de la actividad de la empresa. Al
estar basada en la rentabilidad a largo plazo de la propia empresa, esta visión
aportará la justificación para avanzar con las implicaciones de la GRI. Una GRI
efectiva exige que los sistemas informáticos estén diseñados para apoyar los
factores críticos de éxito y los procesos que constituyen el núcleo de la
organización, tal y como han sido previamente identificados en el plan
estratégico de actividad.
36. Por ejemplo, un proceso perteneciente al núcleo de la
organización puede ser la "mercadotecnia del producto", y un factor crítico para
el éxito en un plan estratégico de la empresa puede ser la expansión del número
de clientes. El estudio cuidadoso de este factor, en el contexto de la
organización, podría revelar que las estrategias comerciales y la promoción de
ventas necesitan una revisión. Los datos críticos para apoyar esta revisión
pueden estar constituidos, entre otras cosas, por información acerca de posibles
clientes.
37. El reto puede consistir en animar a los gestores de la
empresa a implicarse en el proceso de planificación de recursos informáticos,
así como a incrementar el conocimiento que el grupo de tecnología informática
tiene sobre el proceso de planificación general de la entidad. La comprensión de
la tecnología y de los bloques construidos con información básica es esencial
para llegar a diseñar algo que puede hacer más fácil la actividad de la
organización.
38. Se sugiere que un grupo de planificación, formado por un
ejecutivo del área informática con otros ejecutivos de las demás áreas
funcionales clave, celebren una serie de reuniones de planificación para
examinar los factores críticos de éxito. Es importante permitir la
reconsideración del proceso para asegurar que el análisis es completo y para
determinar las áreas donde debe centrarse la atención. Todo este proceso se
puede hacer de forma más simplificada en las organizaciones que cuentan con un
Director de Informática, el cual será miembro del grupo de dirección de la
empresa y, como tal, estará también implicado en la planificación de los ciclos
de actividad de la empresa desde el principio.
39. En el pasado, el papel principal de la planificación de
sistemas informáticos puede haber estado centrado en determinar cómo aplicar la
tecnología a la autorización de tareas. Al utilizar la filosofía de la GRI, sin
embargo, las cuestiones más relevante pueden ser las siguientes: "¿Cómo se puede
aplicar la tecnología para obtener ventajas competitivas?" "¿Cómo se puede
conseguir la mejor información para los que deben decisiones?" "¿Dónde se
encuentran las mejores oportunidades para añadir valor a través de los recursos
de tratamiento de la información?".
40. En esta etapa, el resultado que se obtiene del proceso de
planificación es una lista específica de los procesos y datos críticos para los
objetivos y la marcha de la organización. Se trata de las exigencias
estratégicas a satisfacer en etapas posteriores del proceso de desarrollo y
planificación de la información.
Evaluación del entorno actual
41. el punto de partida para desarrollar el nuevo plan de GRI
es una combinación de los planes, presupuestos, procesos y sistemas existentes.
El propósito de la reconsideración de la situación actual, es desarrollar una
evaluación completa y adecuada del entorno, tal como funciona en la actualidad.
La información recogida en este estado proporcionará el marco para la evaluación
de los riesgos y ventajas de los cambios propuestos, lo que servirá para
estructurar el plan y cambiar la filosofía de gestión. Puede actuar, asimismo,
como un importante mecanismo de retroalimentación para suministrar a los
usuarios información relevante sobre las mejoras que se necesitan, o sobre las
oportunidades que se ofrecen para realizar estas mejoras.
42. Se revisarán tanto los proyectos en curso como los que se
encuentren en fase de planificación, al objeto de preparar un resumen del
proyecto que contenga su descripción, su estado actual de desarrollo y las
previsiones para su terminación, así como una estimación de sus costes. Algunos
de los proyectos pueden quedar "en espera", de momento, si dependen de
tecnologías o decisiones que puedan cambiar radicalmente por la introducción del
plan de GRI.
43. La revisión de los presupuestos debe centrarse en los
costes existente, con el fin de determinar cuáles de ellos están relacionados
con las operaciones corrientes, cuáles con el mantenimiento de los sistemas
actuales, qué otros con el desarrollo de nuevos sistemas y también qué costes
supone la gestión del departamento informático. Es también útil, en este
estadio, revisar los arrendamientos a largo plazo y los acuerdos de licencia
para determinar los eventuales costes de cancelación o de renovación.
44. La revisión de los sistemas debe centrarse en obtener
información acerca de:
— Variables de tipo demográfico descriptivo: su edad,
los lenguajes utilizados para desarrollarlos, el número de programas, el
sistema utilizado para acceder a los ficheros o los programas de bases de
datos usados, entorno de equipos físicos, etc.
— Estado de mantenimiento: fecha de la última mejora,
mantenimiento planificado, calidad técnica, puesta al día y calidad de la
documentación existente.
— Funcionalidad del sistema: problemas de los
usuarios, necesidades no atendidas, disponibilidad de los datos y resultados
de los procesos, integridad y seguridad de los datos, relevancia presente y
futura del sistema para las actividades de la empresa.
45. Los procesos y actividades que constituyen el núcleo se
definirán y describirán de acuerdo con los siguientes extremos:
— Resultados deseados: ¿cuáles son los resultados y
salidas medibles?
— Punto de partida: ¿dónde "empieza" la actividad?
¿cómo se produce su lanzamiento?
— Enlaces tecnológicos: dentro de la actividad
desarrollada ¿dónde, cómo y por qué enlazarse con la tecnología existente?
— Enlaces inter e intra organización: ¿dónde, cómo y
por qué enlaza la actividad con otras actividades de la empresa u otras
unidades dentro de la misma?
— Enlaces externos: ¿dónde, cómo y por qué enlaza la
actividad con agencias externas, con clientes y con proveedores?
— Propiedad y responsabilidad: ¿quién es el
"propietario" de la actividad? ¿quién es el responsable, en términos
generales, de los resultados obtenidos?
— Punto final: ¿dónde y por qué causa termina la
actividad? ¿qué medidas se aplican para su terminación, marcos temporales,
volúmenes u objetivos?
ILUSTRACIÓN 2
CUESTIONES A AFRONTAR EN LA
EVALUACIÓN
DE LOS RECURSOS
|
— ¿Están debidamente custodiados y salvaguardados nuestros activos?
— ¿Cómo controlamos los sistemas informáticos sin lesionar la innovación?
— ¿Está organizado el departamento de sistemas informáticos de forma apropiada?
— ¿Están la organización y los recursos humanos preparados para el cambio?
— ¿Dónde debemos efectuar las inversiones?
— ¿Están vinculados los sistemas informáticos con la estrategia empresarial?
— ¿Estamos obteniendo rentabilidad sobre las inversiones?
— ¿Estamos sacando ventaja de las tecnologías estratégicas?
— ¿Tenemos la combinación adecuada de competencias informáticas?
— ¿Estamos comprometidos con un único proveedor?
— ¿Tenemos la correcta arquitectura de aplicaciones, datos redes y ordenadores?
— ¿Pueden los clientes usar nuestros sistemas? |
46. La actividad de evaluación será, necesariamente, de
carácter iterativo por naturaleza y, si se contestan las cuestiones relacionadas
en la Ilustración 2 cuanto antes en el curso del proceso de planificación, se
ayudará a los planificadores a obtener una mejor comprensión de:
— el inventario de los diferentes niveles de puestos a cubrir y de la competencia necesaria para cubrirlos, así como a anticipar los posibles cambios;
— equipos y otros recursos, así como la previsión de los posibles cambios;
— políticas y procedimientos en vigor;
— tecnología informática, tanto el entorno existente cono el esperado;
— flujo de información;
— enlaces con otras competencias de la organización relativas a la infraestructura y agencias externas, incluyendo sus sistemas informáticos, y
— factores de producción, entregas, clientes e indicadores claves del rendimiento.
Definición del entorno de los recursos informáticos
47. Existen muchas metodologías y enfoques posibles a la hora
de planificar, definir, diseñar y construir un entorno de GRI. Lo importante
para la organización es seleccionar una metodología coherente, para usarla en
todas las iniciativas que tengan que ver con la GRI dentro de la organización.
El enfoque utilizado en esta Declaración asocia la modernización de actividades
a la bien conocida metodología de la ingeniería de la información, modelización
de datos, modelización de procesos y modelización de la empresa en su conjunto.
De esta manera, aseguramos que están considerando las necesidades de la
organización en su totalidad, y que los recursos informáticos enlazan
directamente con la estrategia general y los objetivos de la empresa, a la vez
que se mantiene el necesario equilibrio entre información, la tecnología, los
procesos y la organización.
48. Modelizar es el acto consistente en desarrollar una
descripción adecuada de un sistema (formado por un conjunto de componentes
interactivos con ciertas relaciones entre ellos), descripción que incluye una
definición de todos los componentes importantes del sistema y de cómo se
producen sus interacciones. La principal razón de la construcción de
modelos es la de poder responder a cuestiones acerca del sistema, sin tener que
tratar directamente con él. Es preciso desarrollar una serie de modelos de
diferente nivel (de empresa, de procesos, de datos, de actividad y de
operación), para apreciar cabalmente qué recursos informáticos existen, cuáles
se necesitan y dónde están las lagunas.
Desarrollo de modelos de información
49. El proceso de modelización es una labor intensiva, que
precisa de una cantidad importante de información procedente de las diferentes
unidades de la organización. Los modelos se construyen unos sobre otros, y cada
uno de ellos suministra información que es algo diferente, pero complementaria,
de su predecesor. Puede suponerse que cada modelo representa una "fotografía en
el tiempo", una visión de la situación tal y como ha sido apreciada en el
momento de construirlo. Aunque parezca que los procesos de cualquier
organización cambian mucho más frecuentemente que los datos que utilizan o la
información de que se nutren, los modelos deben ser revisados regularmente, por
ejemplo de forma anual, aprovechando el momento de la revisión del plan de GRI.
Se recomienda desarrollar los siguientes tipos de modelos:
a. La modelización de operaciones es una técnica que
sirve para definir la información general que envían y reciben los
departamentos de una empresa. Es el primer escalón para comprender la
naturaleza del flujo de información dentro de la organización. Los modelos de
operaciones sirven de puente entre la identificación de las necesidades
estratégicas y la definición una vez que se hayan implementado los planes
estratégicos de la GRI.
b. La modelización de actividades es una técnica
estructurada para definir qué o quién ejecuta una determinada actividad, cómo
dice que lo hace, qué pone en marcha tal actividad y qué produce ésta. La modelización de actividades puede ser usada para asegurar que la
información o los datos van a quién los necesita para trabajar con ellos,
minimizando así el riesgo de sobrecarga o redundancia de datos. Esta fase de
la GRI precisa del desarrollo de un modelo de las operaciones actuales y
futuras. Una serie de actividades se combinan para dar un proceso empresarial,
mientras que una organización está compuesta por una red de procesos.
c. La modelización de datos es una manera de
identificar sistemáticamente las categorías o tipos de datos de los que se
componen los flujos definidos en los modelos de las operaciones y actividades.
Los modelos de datos constituyen un retrato de las interrelaciones entre los
datos de una compañía. Esta fase de la GRI exige el desarrollo de un modelo
conceptual de datos, que representa el más alto nivel en el que se pueden
considerar las bases de datos, en la forma de un modelo de relaciones entre
entidades.
d. La modelización de procesos es utilizada para
documentar el la forma en que se manipulan los datos dentro de la
organización, es decir, define aquellas funciones del sistema que se realizan
dentro de los programas de ordenador. Esta fase de la GRI requerirá el
desarrollo de los siguientes elementos:
— modelo conceptual de transacciones,
mediante el que se representa una visión, del más alto nivel de las operaciones
de creación, recuperación, puesta al día y borrado requeridas para apoyar a la
empresa, y
— modelo de distribución, mediante el
que se representa una visión muy general de como se distribuyen, o van a
distribuirse, la bases de datos y las transacciones que realizan, así como dónde
residen geográficamente.
e. La modelización de empresa consiste en trasladar la
actividad empresarial a mapas con descripciones de datos, aplicaciones y
localizaciones, esto es, constituye un método para integrar los modelos de
datos, de actividades y procesos previamente definidos, en un todo
consolidado, que puede ayudar cuando se desee compartir la información en la
compañía. Puede llevar una gran cantidad de tiempo terminar un modelo completo
de la empresa, pero es importante cualquier esfuerzo para desarrollar un
panorama lo más íntegro posible de las exigencias informativas dentro de la
empresa.
50. Aunque el proceso de modelización puede llevarse a cabo
manualmente, se recomienda la utilización de herramientas informáticas para
hacerlo. De esta manera, la información que se recoja puede ser almacenada en
una base de datos informática para su utilización posterior. Puesto que nos
encontramos en un período de cambio continuo, una concepción estática del GRI
resulta totalmente inadecuada. Los entornos empresariales continúan siendo de
carácter dinámico, y por tanto es complejo determinar cuál es la mezcla
apropiada de tecnologías, recursos humanos, aplicaciones, bases de datos, etc.
Con el fin de ayudar a los arquitectos y diseñadores de modelos, hay disponibles
herramientas muy poderosas de simulación y construcción de prototipos, que les
permiten desarrollar un modelo vivo de empresa que puede mantenerse en el
tiempo, como punto de referencia para definir las arquitecturas informáticas.
51. El Apéndice a esta Declaración suministra más detalles
sobre el proceso de modelización y sobre algunas de las técnicas más comunes
para llevarlo a cabo.
Desarrollo de arquitectura
52. El propósito de esta tarea es preparar un entramado de
arquitecturas de sistema, basada en las necesidades definidas a través de los
modelos de información desarrollados en la etapas previas del proceso de
planificación. Las arquitecturas objetivo se desarrollan para suministrar una
visión compartida del entorno de recursos informáticos necesarios para cubrir
las necesidades de actividad dentro de la organización. El proceso de diseño de
la arquitectura consiste en organizar los pasos de decisión que llevan desde la
necesidad detectada a la solución técnica idónea. Se utiliza el término
"arquitectura" porque lo que se obtiene del proceso es análogo a un plano de
construcción, esto es se específica cómo será el resultado final una vez que los
planes se hayan implementado. En otras palabras, las arquitecturas describen la
infraestructura tecnológica futura de organización.
53. Las arquitecturas específicas del sistema incluyen:
— arquitectura de aplicaciones;
— programas informáticos utilizados por el sistema;
— telecomunicaciones, y
— equipos físicos.
54. El valor para la empresa de la arquitectura objetivo es
considerable. Su propósito es suministrar una guía y orientación para construir
e integrar aplicaciones, datos, tecnología y redes de comunicación. De la misma
manera que las previsiones de ventas suministran un objetivo para la producción
y, a la vez, para las provisiones de primeras materias y planificación de la
mano de obra, las arquitecturas objetivo suministran una guía para el desarrollo
de los sistemas y, a la vez, para la adquisición de equipos físicos, programas
informáticos y bases de datos que apoyen el desarrollo de los sistemas. Además,
procuran la base necesaria para asegurar que los diferentes componentes
tecnológicos son compatibles, de manera que puedan integrarse los unos en los
otros.
55. En la Ilustración 3 se suministra una lista de algunas de
las consideraciones, en la arquitectura objetivo, que pueden ser tremendamente
importantes si se quiere desarrollar un entorno GRI apropiado
(11).
56. La arquitectura del sistema está usualmente determinada
por cómo el diseñador de cada sistema individual escoge utilizar las diferentes
tecnologías de procesamiento de datos, para cubrir las exigencias informativas
del usuario. Las tecnologías de procesamiento de datos subyacentes pueden
dividirse en cinco categorías principales:
— aplicaciones;
— datos;
— programas informáticos del sistema;
— equipos físicos, y
— redes
ILUSTRACIÓN 3
CONSIDERACIONES SOBRE LA ARQUITECTURA
|
— Equipos físicos, incluyen periféricos: normas predefinidas, cuestiones relativas al entorno.
— Distribuida o centralizada: estándares, preferencias de la organización.
— Configuración de la red: redes existentes, capacidad, exigencias.
— Protocolos de comunicación: normas existentes, protocolos que se usan actualmente.
— Programas informáticos a utilizar en el sistema: normas existentes, opciones disponibles en las plataformas de comunicación y equipos físicos previstos.
— Programas de bases de datos: normas existentes, programas en uso.
— Herramientas de desarrollo de aplicaciones, por ejemplo CASE: herramientas utilizadas en la actualidad, herramientas disponibles para plataformas potenciales, motores de bases de datos, sistemas operativos, plataformas de comunicación.
— Desarrollo del entorno: normas en vigor para usuarios y diseñadores, otras plataformas de herramientas que se puedan considerar, prioridades de la arquitectura.
— Programas de aplicaciones, fabricar o comprar, selección de paquetes existentes, etc.: normas existentes, productos estándar del sector, coherencia con la arquitectura que se desea, disponibilidad de apoyo técnico.
— Enlace humano: necesidades, expectativas de los usuarios.
|
57. Para asegurar que el diseño avanza en un contexto
apropiado, existe un conjunto de cuestiones previas a responder en el proceso de
definición de la arquitectura
(12):
— ¿Cuánto puede invertir la organización?
— ¿Cuál es el nivel de habilidades, conocimientos sobre
informática y práctica de los usuarios potenciales del sistema?
— ¿Cuáles son las necesidades reales de tiempos de
respuestas?
— ¿Es esencial que el sistema esté disponible 24 horas al
día, 7 días por semana, o puede bastar con algo menos de tiempo?
— ¿Cuáles son las necesidades en cuanto a la seguridad?
¿cuál es el impacto potencial de los accesos autorizados?
— ¿Con qué frecuencia pueden cambiar la o las aplicaciones?
— ¿Cuál es el nivel de inversión actual?
— ¿Con qué sistemas debe enlazar la aplicación o
aplicaciones?
58. Es posible que las arquitecturas objetivo puedan apuntar
hacia la reposición de las viejas plataformas, puesto que éstas pueden ser
complejas, consumir demasiado tiempo, ser costosas, constituir un obstáculo para
el progreso y además comportar mucho riesgo. Las ventajas de planear tal
migración, a partir del nuevo diseño de la arquitectura, son muchas, pero quizá
la más importante es que suministra el esquema necesario para planificar una
transición ordenada, sopesando riesgos y ventajas en cada etapa.
59. Arquitectura de datos y de aplicaciones - El
objetivo de la arquitectura de datos es introducir información en las bases de
datos. El objetivo de la arquitectura de aplicaciones es introducir procesos,
junto con los datos asociados a ellos, en los sistemas de aplicaciones. Ambas
arquitecturas se diseñan utilizando una hoja de trabajo con forma de matriz. En
la Ilustración 4 se muestra un ejemplo de ese tipo de matrices, basada en
modelos de actividades y de datos previamente desarrollados.
60. Ha de haber un único proceso responsable de la creación
de cada atributo de datos. Esto disminuye la redundancia e incrementa la
integridad de los datos. Por tanto, la matriz proporciona información sobre la
correcta secuencia para construir las aplicaciones. Toda aplicación que necesite
recuperar un tipo de datos en particular debe ser desarrollada después de la
aplicación que se ha designado como responsable de la creación de ese tipo
específico de datos.
61. Además, esta colocación de datos y procesos en una matriz
suministra información sobre las necesidades de datos y de procesos
correspondientes a varios niveles y diferentes áreas funcionales en la
organización. Pone de manifiesto qué necesidades son comunes a varias áreas o
niveles, y cuáles son diferentes. Esto hace que sea sencillo realizar las
aplicaciones que mejor reflejen la estructura de la organización.
62. Arquitectura tecnológica - La arquitectura
tecnológica, compuesta por los sistemas de programas informáticos, de equipos
físicos y de redes, se diseña después de las arquitecturas de datos y
aplicaciones. Se trata de una especificación general de los procesadores, los
dispositivos de almacenamiento, los equipos y programas de red y los sistemas
operados local y remotamente, necesarios para apoyar e implementar las otras
arquitecturas.
63. Para desarrollar la arquitectura tecnológica, los
planificadores, necesitan conocer las necesidades de servicio de cada aplicación
y de cada base de datos. Las necesidades de servicio para las aplicaciones
incluyen los tiempos de respuesta, los tiempos de retorno, las horas de
disponibilidad, el volumen de tráfico, la accesibilidad y las copias de
seguridad. Las necesidades de servicio para las bases de datos son el grado de
seguridad y de integridad exigidos para los datos. En la Ilustración 5 se
muestran las necesidades de servicio para algunos de los tipos de datos
utilizados en ejemplos previos.
ILUSTRACIÓN 4
EJEMPLO DE MATRIZ QUE PONE EN RELACIÓN
LOS DATOS Y LAS APLICACIONES
DATOS
Procesos |
Cliente |
Pedido
del cliente |
Entrega |
Producto |
Proveedor |
Pedido al
Proveedor |
1.1.
Mantenimiento de la
cuenta del cliente |
A,
B |
R |
R |
|
|
|
| 1.2. Recepción de
pedidos |
R,
P |
A,
B |
R |
R |
|
R |
| 1.3.
Planificación y supervisión de ventas |
R |
R |
R |
R |
R |
R |
| 1.4. Plan de
llamadas de ventas |
R,
P |
R |
R |
R |
R |
|
| 2.1. Gestionar
A/R |
R |
R,
P |
R |
|
|
|
| 2.2. Gestionar
A/P |
|
|
|
R |
R |
R,
P |
2.3. Análisis de
rentabilidad
financiera |
R |
R |
R |
R |
R |
R |
3.1.
Mantenimiento de la
información sobre los
productos |
|
|
|
A,
B |
R |
R |
| 3.2. Recepción de
productos |
|
|
|
R,
P |
R |
R,
P |
| 3.3. Expedición
de productos |
R |
R,
P |
A,
P |
R,
P |
R |
|
| 4.1.
Mantenimiento de la cuenta del proveedor |
|
|
|
R |
A,
B |
R |
| 4.2. Análisis de
proveedores |
|
|
|
R |
R |
R |
| 4.3. Envío de
pedidos |
|
|
|
R |
R |
A,
B |
|
A= añadir (crear) los
datos
R= recuperar (acceder) a los datos
P= Poner al día los datos
B= Borra los datos
Cada columna de la matriz corresponde a una entidad en el modelo de datos (o
bien a un grupo de entidades), y cada fila corresponde a un proceso en el
modelo de procesos. Las entradas en cada celda indican si el proceso se
relaciona con el dato en cuestión y, de ser así, cómo. Un proceso puede:
• añadir datos -por ejemplo el proceso. Mantenimiento de la cuenta del
cliente es el responsable de añadir un cliente a la base de datos.
• acceso a los datos -por ejemplo, la Planificación y supervisión de ventas
puede acceder a información acerca de clientes, productos y proveedores.
• poner al día los datos -por ejemplo la Expedición de productos puede poner
al día datos sobre pedidos de clientes.
• borrar datos -por ejemplos, la Recepción de pedidos puede borrar pedidos
de clientes una vez han sido cumplimentados. |
ILUSTRACIÓN 5
EJEMPLO DE ESPECIFICACIONES SOBRE
NECESIDADES DE SERVICIO
DATOS
Procesos |
Cliente |
Pedido
del cliente |
Entrega |
Producto |
Proveedor |
Pedido al
Proveedor |
1.1.
Mantenimiento de la
cuenta del cliente |
3 seg. |
30 seg. |
8-8 |
Medio |
Central |
24 h. |
| 1.2. Recepción de
pedidos |
3 seg. |
30 seg. |
8-8 |
Alto |
Remoto |
24 h. |
| 1.3.
Planificación y supervisión de ventas |
5 seg. |
1 h. |
8-8 |
Bajo |
Remoto |
7 días |
| 1.4. Plan de
llamadas de ventas |
5 seg. |
1 h. |
8-8 |
Bajo |
Remoto |
7 días |
| 2.1. Gestionar
A/R |
5 seg. |
1 h. |
8-5 |
Alto |
Central |
24 h. |
| 2.2. Gestionar
A/P |
5 seg. |
1 h. |
8-5 |
Alto |
Central |
24 h. |
2.3. Análisis de
rentabilidad
financiera |
5 seg.
|
24. h |
8-5 |
Bajo |
Remoto |
24 h. |
3.1.
Mantenimiento de la
información sobre los
productos |
5 seg. |
1 h. |
8-5 |
Medio |
Central |
3 días |
| 3.2. Recepción de
productos |
5 seg. |
1 h. |
8-5 |
Alto |
Central |
24 h. |
| 3.3. Expedición
de productos |
5 seg. |
1 h. |
8-5 |
Alto |
Central |
24 h. |
| 4.1.
Mantenimiento de la cuenta del proveedor |
5 seg. |
1 h. |
8-5 |
Bajo |
Central |
3 días |
| 4.2. Análisis de
proveedores |
5 seg. |
24 h. |
8-5 |
Bajo |
Central |
7 días |
| 4.3. Envío de
pedidos |
5 seg. |
1 h. |
8-5 |
Medio |
Central |
24 h. |
|
Necesidades de servicios para las bases de
datos
|
| |
Integridad
de los datos |
Seguridad
(pérdida de datos) |
Seguridad
en el acceso |
|
|
Datos sobre
clientes
Datos sobre
productos
Datos sobre
proveedores |
Alto |
Alto |
Alto |
|
Alto |
Medio |
Bajo |
|
Alto |
Medio |
Medio |
64. Para toda combinación compuesta por un conjunto de datos
y una arquitectura de aplicaciones, es probable que exista una variedad de
arquitectura tecnológicas alternativas que satisfagan los requisitos del
servicio.
Antes de embarcarse en el desarrollo de arquitecturas
particulares, es útil desarrollar una serie de "principal de la arquitectura",
con el fin de asegurar que los objetivos generales del programa de GRI se
satisfacen de una forma conveniente. En la Ilustración 6 se muestra un ejemplo
de Declaración de Principios Generales de la Arquitectura.
ILUSTRACIÓN 6
PRINCIPIOS GENERALES DE LA ARQUITECTURA
(13)
|
Interesados. La arquitectura estará diseñada para servir a los ciudadanos particulares, a las grandes y pequeñas sociedades mercantiles, a los empleados públicos, a las autoridades regionales y municipales, a las agencias nacionales y a otras organizaciones de servicio público.
a.
Centrada en los ciudadanos: Todas las decisiones de arquitectura deben
sustentar la aparición de sistemas orientados a los ciudadanos, que
respondan a las demandas de éstos, sean adaptables a las necesidades
cambiantes de la actividad de los programas o de los negocios, que promuevan
un servicio de alta calidad y sean fáciles de usar.
b. Facilidad. Las necesidades técnicas y
comerciales de tipo general deben ser tratadas de forma sencilla y
coherente.
c. Compartidos. Los componentes de la
arquitectura serán susceptibles de utilizarse de modo compartido.
d. Apertura. Los componentes de la
arquitectura y sus especificaciones asociadas utilizarán normas comunes de
la industria, con preferencia a las implementaciones neutrales de los
vendedores.
e. Modularidad. La arquitectura estará
basada en componentes modulares con enlaces estandarizados.
f. Comprar frente a fabricar. Se
preferirán los componentes que se puedan adquirir e integrar frente a los
productos fabricados sobre pedido o modificados de forma importante.
g. Coste del cumplimiento de estos
principios. El cumplimiento con las normas de la arquitectura puede suponer
un coste inicial mayor.
h. Medida. La medida del uso y del
rendimiento de los componentes de la arquitectura ha de llevarse a cabo
continuamente, como una práctica común más.
i. Operaciones. El método preferente de
llevar a cabo las transacciones comerciales, ya sean internas o
externas, será a través de medios electrónicos, como por ejemplo
Transferencia Electrónica de Datos (EDI), Transferencia Electrónica de
Fondos (TEF), Correo Electrónico (E-Mail), etc.
j. Ubicación. La ubicación geográfica no
debe ser un condicionante para acceder a los servicios, ni ser usada como un
pretexto para cobrar por acceder a ellos.
k. Flexibilidad para crecer o cambiar. Las
especificaciones técnicas de la arquitectura han de ser diseñadas para
acomodarse al cambio continuo, y deben tomar en consideración las eventuales
necesidades futuras, al mismo tiempo que cumplen en el máximo grado posible
las exigencias actuales.
|
65. Deben también considerarse extremos tales como las
tendencias de la tecnología de los sistemas informativos, la adhesión a o el
establecimiento de normas uniformes empresariales (por ejemplo la arquitectura
de sistemas de redes -SNA-, el enlace de sistemas abiertos -OSI-, etc.), así
como qué elementos de los sistemas actuales pueden verse modificados al
introducir la nueva arquitectura. Puesto que puede llevar varios años a la
organización la tarea de conseguir el entorno de la GRI que pretende, debe
también considerarse, en el diseño de la tecnología de la arquitectura, la
introducción de las tecnologías emergentes. Los planificadores de sistemas
informáticos necesitan evaluar continuamente las tecnologías que estén
apareciendo y su posible impacto en la organización. Para realizar esta
evaluación se desarrolla un perfil de cada tipo de tecnología, evaluando la
posibilidad de utilizarla en el seno de la organización y estimado el marco
temporal en el que podría ser utilizada. El Comité de Sistemas Informáticos debe
recibir una evaluación de las tecnologías emergentes que, eventualmente,
pudieran tener un impacto importante en la actividad de la organización.
66. Otras cuestiones a considerar en el diseño de la
arquitectura son las siguientes:
— Los activos de contenido tecnológico poseído en la
actualidad- sistemas físicos, programas informáticos y conjuntos de
aplicaciones.
— Distribución de bases de datos y de transacciones -
si se utiliza una filosofía informática distribuida o repartida, las bases de
datos y las operaciones con ellas se localizan con frecuencia en los puntos
donde se llevan a cabo las transacciones comerciales, lo cual puede tener
importantes implicaciones para la arquitectura tecnológica.
— Mejor tecnología - con preferencia sobre los
productos de tipo común, seleccionar el mejor tipo de tecnología para el
trabajo a realizar.
— Intercambiabilidad - los componentes tecnológicos
han de seleccionarse sobre la base de su fácil sustitución sin interrupción
del servicio.
— Orientación hacia estaciones de trabajo -
ordenadores personales que pueden constituir estaciones de trabajo
inteligentes y multifuncionales.
— Entorno de red - todas las estaciones enlazadas a
través de la red, sea localmente o mediante redes de área amplia.
67. En cuanto a la arquitectura de los sistemas de programas
informáticos, estará determinada por una variedad de productos técnicos que se
usan para facilitar la operación de, y la interacción de los usuarios con, los
programas de aplicación. Los principios principales componentes del sistema de
programas informáticos son:
— el sistema operativo,
— el supervisor de telecomunicaciones,
— el programa informático de la red,
— el método de acceso a los archivos,
— el sistema de gestión de bases de datos,
— un lenguaje de cuarta generación y
— los lenguajes de programación.
68. La arquitectura de los sistemas de programas informáticos
y la arquitectura de equipos físicos deben ser evaluadas de forma conjunta,
puesto que la elección de los programas de tratamiento de datos que puede
influir en la elección de los equipos físicos, y viceversa. La arquitectura de
los equipos físicos en la mayoría de las configuraciones informáticas se compone
de:
— la unidad central de proceso,
— unidades de disco,
— unidades de cinta magnética,
— terminales o estaciones de trabajo,
— impresoras y
— controladores
69. La arquitectura de red conlleva la definición de
las redes de área local y las líneas y controladores de telecomunicaciones
remotas que apoyan las terminales y las impresoras distribuidas, así como el
enlace con las unidades centrales de proceso remotas.
70. A medida que las preferencias por entornos
cliente-servidor aumentan, también lo hace la panoplia de componentes físicos y
programas ofrecidos por múltiples proveedores, al igual que los enlaces
relacionados con ellos y las interconexiones. El potencial para aumentar la
complejidad es enorme, pero se presentan muchos problemas a resolver:
comunicaciones, gestión de datos, seguridad de los mismos, mantenimiento, copias
de seguridad y recuperación de datos. En el entorno GRI, la arquitectura del
sistema define todos los componentes tecnológicos de la organización. Esto es
particularmente valioso en un entorno distribuido o en un entorno
cliente-servidor puesto que ayuda a:
— identificar las duplicaciones y redundancias en la
tecnología existente;
— poner de manifiesto la dependencia de proveedores
específicos o ciertas tecnologías;
— identificar áreas de tecnología aplicada de forma impropia
o subutilizada, y
— descubrir inconsciencias e incompatibilidades entre
tecnologías diferentes.
Mantenimiento de la arquitectura objetivo
71. Las arquitecturas objetivo tienen como misión describir
cómo serán los recursos informáticos de la organización en el futuro
(normalmente dentro de un período de entre dos y cinco años), pero no cómo son
el momento presente. A medida que las necesidades y el panorama de la
información van cambiando, las arquitecturas objetivo deben ser revisadas para
ponerlas al día, de la misma forma que se hace con las previsiones de ventas
cuando se modifican para reflejar los cambios en las condiciones comerciales de
la empresa. La organización necesita una política que le permita mantener sus
arquitecturas objetivo, y la responsabilidad de llevarla a cabo es de la función
de Planificación de Sistemas Informáticos.
72. Las arquitecturas objetivo especifican cómo será la
infraestructura tecnológica, pero no cómo ha de construirse. El estadio final
del proceso de planificación, por tanto ,consiste en llevar a cabo el plan
estratégico de implementación, que especifica cómo deben construirse tales
arquitecturas. Este plan contempla la transición de la organización, desde su
actual situación, hasta la total implementación de un proyecto particular de
desarrollo de los sistemas.
PREPARACIÓN DEL PLAN DE IMPLEMENTACIÓN DE LA GRI
73. la primera fase de desarrollo del plan de implementación
de la GRI es definir cada proyecto y asignar prioridades. En esencia, la
ordenación de las prioridades se basa en los siguientes factores clave:
necesidades de gestión, coste-beneficio y riesgo. El desarrollo de las
prioridades y la definición de las interdependencias en los proyectos debe dar
lugar a una programación de los proyectos que describa la secuencia en que los
citados proyectos serán abordados.
Mecanismo de selección de proyectos
74. El mecanismo de selección de proyectos debe poseer tres
características:
— Debe ordenar los proyectos según cómo éstos se acomoden al
plan estratégico de actividad de la organización.
— Debe ser un mecanismo formal, con el fin de asegurar que
la planificación es sistemática y rigurosa.
— Debe tener en cuenta los costes y los beneficios no
cuantificables.
75. Los análisis coste-beneficio tradicionales utilizan
cálculos económicos tales como la rentabilidad sobre la inversión, el tipo
interno de rendimiento y el valor actual neto, que están implícitos en las dos
primeras características, pero no en la tercera. Tales análisis comparan el
coste de la inversión esperada de un proyecto con los beneficios que se
derivarán del mismo cuando se lleve a cabo. Puesto que consideran sólo
beneficios de tipo económico, cualquier otro tipo de beneficios que se puedan
derivar del proyecto deben ser, o bien expresados en términos económicos (a
menudo se forma arbitraria), o bien considerados independientemente del anterior
análisis formal.
76. Ninguna de las dos soluciones es satisfactoria cuando se
trata sistemas informáticos, puesto que los beneficios no cuantificables son a
menudo muy importantes. Una solución mejor consiste en utilizar un nuevo método
que tenga en cuenta los costes y los beneficios, tal como el que se describe más
abajo
(14). En esta descripción se ponen de manifiesto los principios generales
que contiene, pero las características específicas (tal como los criterios
concretos de valoración) pueden modificarse por parte de la organización que lo
utilice.
Criterios para la valoración
77. El proceso formal de selección de proyectos descrito aquí
utiliza nuevo criterio para fijar las prioridades. También amplía el concepto de
"beneficio" para incluir una amplia gama de factores que afectan al valor del
sistema para la empresa. De la misma forma, amplía el concepto de "coste" para
incluir una evaluación del riesgo.
78. Los criterios se dividen en dos grupos: uno de carácter
económico y otros de carácter tecnológico. Unos y otros se utilizan para
clasificar cada uno de los proyectos en consideración.
79. Criterios económicos - Son los criterios de
interés económico de la organización:
— Impacto económico - se trata de los criterios de
tipo financiero utilizados para ordenar proyectos, que ya se han mencionado
arriba, tales como la tasa interna de rendimiento o el valor actual neto.
— Alineamiento estratégico - es la medida en que el
proyecto cumple con los objetivos estratégicos de la organización.
— Ventaja competitiva - la medida en que el proyecto
podrá dar a la organización una ventaja sobre sus competidores.
— Mejora en la información para la gestión - la
medida en que la que el proyecto podrá mejorar la información para la gestión
de las actividades que constituyen el núcleo de la empresa.
— Riesgo competitivo - la medida en que la
postergación del proyecto puede producir una pérdida neta en la posición
competitiva de la empresa.
— Riesgo organizativo - la medida en que el proyecto
puede interrumpir marcha normal de la organización o puede necesitar adaptarse
en el caso de ser implementado.
80. Criterios tecnológicos - Los criterios relativos a
la tecnología del proyecto son:
— Arquitectura estratégica - la medida en la cual el
proyecto es una parte integrante de la arquitectura objetivo de la
organización, así como su necesidad de cara a la implantación de los proyectos
subsiguientes
— Incertidumbre en la definición - la medida en la
cual los requisitos y las especificaciones del proyecto han quedado definidas,
han sido objeto de aprobación y no cambiarán probablemente en el futuro
— Riesgo de infraestructura - la medida en la que el
entorno de los sistemas informáticos puede verse modificada para acomodarse al
proyecto, en términos de equipos físicos existentes, programas informáticos,
personal , habilidades y prestación de servicios. Puede por ejemplo, resultar
necesario implementar un programa de formación y entrenamiento para asegurar
que la organización tendrá el nivel de experiencia necesaria para planificar e
introducir infraestructuras tecnológicas cuidadosamente construida, en
especial cuando se trata de tecnologías complejas.
El proceso de valoración
81. La selección de proyectos ha de ser un proceso emprendido
conjuntamente por los usuarios y por el personal de los sistemas informáticos.
La ordenación propuesta ha de poner énfasis en el alto grado de impacto en la
actividad (relación de los sistemas con los objetivos de la organización), en
sus beneficios tangibles (rentabilidad financiera esperada con respecto al nivel
de inversión necesario9, en sus beneficios intangibles (beneficios derivados de
la implantación del nuevo sistema), en bajo nivel de riesgo de implementación
(probabilidad de que el sistema pueda no cumplir los objetivos pretendidos) y en
la calidad de los sistemas existentes (habilidad que los actuales sistemas
tienen para ejecutar la función de forma eficaz y eficiente).
82. En el proceso de evaluación deben participar diferentes
personas, dependiendo de sus responsabilidades y conocimientos. Aquéllos
usuarios que han solicitado el proyecto son los responsables de sus
implicaciones para la actividad de la organización (es decir, del valor y del
riesgo que para la empresa tienen los proyectos que proponen) y como serán los
que mejor comprendan sus méritos, han de realizar la valoración según los
criterios que se han denominado económicos. Los especialistas en sistemas
informáticos son más responsables, puesto que son también mejores conocedores,
de las implicaciones tecnológicas (es decir, del valor y del riesgo tecnológico)
de los proyectos, y por tanto habrán de realizar la valoración según los
criterios que se han denominado tecnológicos.
83. El Comité de Sistemas Informáticos participa también en
la valoración de los proyectos, puesto que es el responsable de la orientación
estratégica de la GRI. De forma periódica, el Comité asigna una ponderación a
cada uno de los criterios de selección de proyectos. El valor de la ponderación
correspondiente depende de la contribución genérica del proyecto, así como de
los elementos de riesgo que se pueda esperar que induzca en la organización. Por
ejemplo, en la Ilustración 7, tanto la prevención de pérdidas netas en la
posición competitiva (riesgo competitivo) como la consecución de los objetivos
estratégicos de la organización (alimentación estratégico) son considerados con
las mayores contribuciones al éxito de la organización, y por tanto tienen las
máximas ponderaciones. Por el contrario, tanto la interrupción que puede inducir
en la vida de organización (riesgo organizativo) como el hecho de que los
requisitos y especificaciones del proyecto no estén concluidos (incertidumbre en
la definición) se consideran como amenazas. Debido al factor de riesgo que
suponen, se les ha dado una ponderación negativa. La asignación de ponderaciones
es la misma para todos los proyectos en cualquier momento del tiempo, y se
hubiera revisión de los pesos correspondientes, los ajustes se aplicarían de una
manera uniforme a todos los proyectos en consideración.
84. En la Ilustración 7 se muestra un ejemplo de proyecto
evaluado.
ILUSTRACIÓN 7
EJEMPLO DE PROYECTO EVALUADO
| |
Ponderación |
Puntuación |
Valor parcial |
|
Criterios económicos |
|
|
|
|
Impacto
económico........................... |
5 |
5 |
25 |
|
Alineamiento
estratégico................... |
10 |
3 |
30 |
|
Ventaja
competitiva........................... |
3 |
2 |
6 |
|
Información para la
gestión................ |
7 |
4 |
28 |
|
Riesgo
competitivo............................ |
8 |
3 |
24 |
|
Riesgo
organizativo........................... |
-2 |
1 |
-2 |
|
Criterios tecnológicos |
|
|
|
|
Arquitectura
estratégica..................... |
5 |
5 |
25 |
|
Incertidumbre en la
definición............. |
-1 |
2 |
-2 |
|
Riesgo de
infraestructura................... |
-2 |
1 |
-2 |
|
Valor total del
proyecto......................... |
|
|
132 |
|
NOTAS:
1. Las ponderaciones, que son establecidas por el Comité se Sistemas
Informáticos, son las mismas para todos los proyectos que se estudian en un
determinado período de tiempo.
2. Las puntuaciones de los criterios económicos se determinan por los
solicitantes para cada proyecto en particular. Cada puntuación puede valer
entre 0 y 5.
3. Las puntuaciones de los criterios tecnológicos se determinan por parte de
los especialistas informáticos para cada proyecto en particular. Cada
puntuación puede valer entre 0 y 5.
4. El valor parcial de cada uno de los criterios se obtiene multiplicando la
ponderación de mismos por la puntuación asignada al criterio en cuestión.
5. El valor del toral del proyecto es la suma de los valores parciales
asignados a los criterios. |
85. Desafortunadamente, la asignación apropiada de las
ponderaciones es compleja, y el procedimiento de puntuación para los nuevos
criterios de selección es subjetivo. Aunque el proyecto se estructura y ejecuta
por parte de profesionales, su evaluación está todavía sujeta a manipulación,
además de influida por las preferencias personales y sesgado, aunque sea de
forma no intencional.
86. Se han realizado muchos esfuerzos para tratar de eliminar
la influencia subjetiva incluyendo el uso de una metodología económica para la
evaluación de proyectos, en oposición a otra meramente financiera, tratando así
de atribuir al proyecto beneficios y costes a largo plazo que no pueden
cuantificarse. La asignación de ponderaciones y puntuaciones exige juicios por
parte de la dirección y evaluaciones subjetivas, pero si todo ello se hace de
acuerdo con una fórmula e estructurada y coherente, es posible lograr la máxima
objetividad.
87. Con independencia del mecanismo utilizado, en el contexto
de la valoración de las ventajas y riesgos de cada proyecto, es necesario
discutir acerca de los siguientes extremos:
— ¿Estamos contemplando las necesidades apropiadas para
la actividad? - Esto supone el alineamiento con los objetivos de la
entidad y con las oportunidades de mercado, el equilibrio entre las
perspectiva a largo y corto plazo, la inversión entre múltiples oportunidades
de ganancia, la sensibilidad a los problemas de desarrollo organizativo y la
mirada puesta por encima de las opiniones y formas de hacer tradicionales.
— ¿Estamos contemplando todo el riesgo a que dan lugar
los proyectos? - Lo que supone valorar los riesgos de hacer algo y de no
hacer nada; sopesar los riegos de los proyectos tanto individual como
colectivamente considerar los riesgos organizativos, tecnológicos y del
proyecto; examinar las maneras de reducir estos riesgos; analizar las posibles
contingencias y tratar de anticiparse a las posibles consecuencias adversas.
— ¿Están dando los proyectos de la rentabilidad económica
óptima? - Lo cual supone considerar las inversiones en equipos fijos; los
criterios de rentabilidad como el VAN, TIR, rentabilidad económica o período
de recuperación de la inversión; la utilización de tasas de descuento, la
determinación de qué variables son medibles; la confianza de la dirección en
el análisis; la coherencia en la estimación de costes y beneficios, así como
la consideración de todos los costes, y no sólo los correspondientes al
sistema.
— ¿Estamos organizando nuestros recursos escasos de la
más efectiva? - Lo que supone enfrentarse a las oportunidades de
integración de sistemas; reevaluar los compromisos existentes de recursos
informáticos; estudiar la distribución de los recursos críticos donde
sean más apropiados y valorar los costes de los recursos escasos utilizando su
verdadero coste de oportunidad.
Proceso de selección
88. En su versión más objetiva, el proceso de selección exige
que cada proponente de un proyecto remita al Comité una descripción del mismo,
con las puntuaciones obtenidas según cada uno de los criterios económicos. Cada
uno de los proyectos remitidos se puntúa utilizando los criterios tecnológicos
y, por último, los proyectos se clasifican de acuerdo con el valor total que les
corresponde. A partir de estas clasificaciones, se seleccionan los proyectos
para su implementación.
89. Sin embargo, en el mundo real se dan otros factores que
contribuyen e influyen en el proceso de toma de decisiones. Por ejemplo, en el
caso de haber restricciones presupuestarias, el coste del proyecto puede tener
un efecto importante sobre su lugar en la clasificación, o si se sabe que un
competidor ha tomado decisiones que puedan tener un impacto negativo en el
desarrollo de las actividades de la organización, esto puede producir un cambio
en la orientación. El objetivo es seleccionar la mejor combinación de proyectos,
tomando todos los factores en consideración, reconociendo que en ocasiones puede
ser necesario invocar medidas de "emergencia" para asegurar el mejor "ajuste"
con la estrategia y cultura de la organización.
90. La selección de proyectos ha de tener lugar de modo
regular, por ejemplo trimestral o anualmente. El calendario del proceso debe
corresponderse con los períodos de tiempo utilizados en la organización para la
toma del resto de las decisiones de tipo presupuestario. Hacer evaluaciones y
selecciones más frecuentemente tiene la ventaja de conseguir agilidad frente a
las cambiantes necesidades de la actividad.
91. Además de hacer frente a los proyectos seleccionados, el
presupuesto debe servir para acomodar los cambios que hayan inducido en los
equipos físicos, en los programas informáticos, en las telecomunicaciones y en
los recursos humanos, por la implantación del proyecto y por las necesidades que
se hayan puesto de manifiesto en las descripciones que contenga, que habrán sido
utilizadas como base de la clasificación efectuada. Si las necesidades de
personal superan a las posibilidades existentes de recursos humanos, se debe
prever el reclutamiento o la formación de especialistas adicionales, o bien el
uso de consultores externos. El presupuesto debe reconocer la necesidad de
continuar el mantenimiento u las mejoras menores en los sistemas en marcha
actualmente existentes. Por otra parte también deberá tener cabida para los
proyectos de "emergencia" que no se pueden prever con antelación.
IMPLEMENTACIÓN DEL PLAN ESTRATÉGICO
92. La aprobación del plan de GRI debe hacerla el Comité de
Sistemas Informáticos (que representan a los mandos intermedios y a la alta
dirección de la empresa). Se debe celebrar una reunión formal donde se revisen
cada uno de los componentes principales del plan. Después de la aprobación, el
plan se cierra y se preparan los programas finales y los presupuestos
correspondientes al proyecto.
93. Es inevitable que sigan apareciendo nuevas necesidades,
que pueden hacer necesario reconsiderar las prioridades. La responsabilidad de
ajustar las prioridades que se aplicarían a los proyectos, y posiblemente los
recursos que se les asignen, pertenece al Comité de Sistemas Informáticos.
94. Los proyectos se implementan de acuerdo con las prácticas
de desarrollo de sistemas existentes en la organización. El Comité de Sistemas
Informáticos, y en particular el representante del área de planificación de
sistemas informáticos, servirá como lazo de unión con los diferentes grupos que
estén llevando a cabo los proyectos, para asegurar que la implantación y el
desarrollo de los mismos se hace de acuerdo con las arquitecturas objetivo.
95. Cuando se está preparando el plan de implementación, es
extremadamente importante considerar el impacto organizativo del cambio que el
proyecto va a suponer. ¿Ha indicado el proceso de evaluación de la situación
existente que la organización puede "encajar" el cambio? ¿Los gerentes del área
que ha propuesto el proyecto tienen voluntad y autoridad como para liderar el
cambio? La gestión de los factores humanos y organizativos es especialmente
importante para logra el éxito general de la iniciativa GRI. Con el fin de
asegurar un rodaje suave del programa, con las mínimas disfuncionalidades
producidas por la falta de compromiso y de interés de los empleados, debe
arbitrarse un programa de cambio estructurado que forme parte de la misma
estrategia de implementación.
MEDIADA DE LO CONSEGUIDO - REVISIÓN POST IMPLEMENTACIÓN
Revisión estratégica
96. Puesto que la economía, los mercados y el panorama
tecnológico de la información son proclives a sufrir cambios radicales, el plan
de GRI debe ser objeto de revisión, en el nivel estratégico, al menos una vez
cada dos años, o más frecuentemente si la estrategia de la empresa exige
revisiones con menores plazos de tiempo. Esta revisión debe evaluar si la
estrategia GRI continua apoyando positivamente la orientación deseada de la
actividad empresarial. Si la organización ha entrado en nuevas actividades o
nuevos mercados, entonces el plan de GRI ha de ser revisado de forma inmediata,
sin esperar hasta la revisión bienal programada.
97. En el nivel de la estrategia, uno de los beneficios
claves de un entorno GRI es que, a medida que va madurando, la organización es
capaz de capitalizar un nivel de conocimiento más perfecto, mejorar la
tecnología y la recogida de datos de la empresa, mejorar la interoperatividad de
los sistemas, etc., y todo ello de diferentes manera que antes no podían
adivinarse. Es importante arbitrar un método para capturar todo este potencial
aprendizaje, de forma que pueda ser usado continuamente en la mejora del entorno
general de la GRI.
98. El marco para capturar este activo intelectual podría ser
tan simple como realizar reuniones programadas para el "intercambio de
información", donde un asistente puede trasladar a documento escrito las
lecciones aprendidas, o bien podría hacerse algo más sofisticado, como por
ejemplo instalar un dispositivo informático para compartir experiencias de
grupo, como por ejemplo Lotus Notes. En este último caso las "discusiones"
pueden hacerse sobre la marcha, puesto que se trata de un dispositivo
independiente del tiempo y del lugar, y además la información producida y
capturada puede usarse más tarde.
Revisión táctica
99. En un nivel más táctico, el impacto de la estrategia GRI
en la organización puede ser evaluada a intervalos regulares (entre 3 y 6
meses). A continuación se ofrecen algunas indicaciones acerca de una efectiva y
exitosa implementación de la GRI:
— El Comité de Sistemas Informáticos continua siendo activo
y estando implicado.
— La dirección de la organización es entusiasta con las
nuevas aplicaciones desarrolladas.
— Las nuevas aplicaciones están apoyando los planes
estratégicos u operativos de la actividad empresarial.
— Los clientes están bien atendidos por los recursos
informáticos de la organización.
— Los sistemas informáticos pueden ahora modificarse
fácilmente para acomodarlos a las exigencias cambiantes de la toma de
decisiones y la circulación de información en la empresa.
— Los equipos físicos, las bases de datos, los programas
informáticos y las aplicaciones del sistema son compatibles entre sí y pueden
funcionar de forma integrada si es preciso.
— Las diferentes áreas funcionales dentro de la organización
pueden acceder a los datos y a los sistemas y posibilidades de cálculo e
información compartida.
— Los auditores internos han dado valoraciones positivas de
los controles, así como de las normas técnicas y de seguridad relacionadas con
los recursos informáticos.
100. En último extremo, el éxito de la GRI será juzgado a
partir de su capacidad para hacer que la organización se mueva de forma efectiva
en el sentido deseado por la planificación, con un coste aceptable.
POLÍTICAS NORMAS Y PROCEDIMIENTOS DE GRI
101. Las políticas representan las reglas básicas del juego
en la GRI. Deben establecerse, en el más alto nivel de la gestión, políticas,
normas y procedimientos de tipo formal, por escrito. Además, han de ser
difundidas por toda la organización, adoptadas formalmente por las diferentes
unidades y se deben hacer respetar como cualquier otro tipo de política de la
organización
(15).
102. Los
principios y políticas operativas pueden incluir los
siguientes los siguientes puntos:
— Debe establecerse la participación completa de los
departamentos usuarios, con el fin de asegurar que los sistemas satisfacen las
necesidades de información que demandan los objetivos generales de la
organización
— Deben suministrarse datos y otro tipo de información que
sean útiles, lleguen en el momento oportuno, sean precisos, coherentes y
accesibles
— Los sistemas de datos y otro tipo de información
compatible e integrada serán suministrados mediante el uso de la tecnología de
Sistemas de Gestión de Bases de Datos (SGBD)
— Se desarrollará e implementará un programa de gestión de
los medios informáticos, tanto para la dirección de los mismos como para su
puesta en día
— Puede usarse una forma de evaluación continua de los
nuevos desarrollos tecnológicos con el fin de conseguir ahorros de coste u
otros beneficios adicionales.
— Se utilizará una combinación de conceptos nuevos y
tradicionales para gestionar los recursos informáticos, por ejemplo mediante
un proceso en circuito de planificación, presupuestación y redacción de
proyectos, revisión continua de los sistemas de seguridad y puesta en práctica
de auditorías; inventarios de aplicaciones, etc.
103. La adopción de las normas comúnmente aceptadas en
la industria es de importancia vital para lograra el éxito en la GRI, porque así
se facilita la preparación para el intercambio de información y se apoya la
interoperatividad de los sistemas. Para lograr un control efectivo y facilitar
la interoperatividad de los datos entre plataformas, es necesario identificar
tanto las normas genéricas como las específicas de las citadas plataformas, con
el fin de que puedan funcionar tanto el procesamiento informático como las bases
de datos en un entorno de red. Algunos de los tipos de las normas o estándares
que pueden ser identificados se encuentran en la siguiente lista:
a. La seguridad es
un tema de importancia creciente a medida
que la organización implementa redes que abarcan toda la empresa y soportan el
acceso distribuidos a datos que están físicamente dispersos. Deben
desarrollarse políticas para lograr la confidencialidad, la integridad y la
disponibilidad de los equipos físicos, de los programas informáticos y de los
datos.
b. Es también importante una metodología de desarrollo de los
sistemas que sea estándar y esté estructurada, ya que puede proporcionar:
— un enfoque
estándar para todos los
aspectos de desarrollo de los recursos humanos de los sistemas,
— un proceso coherente para que los
usuarios participen en el desarrollo o en la mejora de los sistemas que
utilizan,
— una mejora general de la
productividad,
— un producto final más estable,
— una reducción de los errores de
especificación y
— mejoras en las posibilidades de
integración de los sistemas.
c. Con el fin de apoyar la posibilidad de transportar
aplicaciones y datos a diferentes plataformas de proveedores, serán necesarios
los estándares genéricos y específicos de cada plataforma. También es
necesario un mínimo conjunto de normas y estándares para realizar la
evaluación de los programas informáticos ya desarrollados que se deseen
adquirir.
e. La documentación de las operaciones realizadas es una
exigencia de cara a la operación y el mantenimiento de las aplicaciones. Deben
establecerse normativas para la elaboración de documentación, tanto genérica
como específica, de todas las plataformas de equipos físicos y de programas
informáticos.
RESPONSABILIDADES Y FUNCIONES EN LA GRI
104. La década
de los 90 ha producido un cambio dramático en
la estructura organizativa que sirve de base a los sistemas informáticos y en
las responsabilidades asociadas a ellos. Puesto que la convergencia entre las
estrategias de la actividad de la organización entre las estrategias de la
actividad de la organización y de los sistemas informáticos está todavía
realizándose, muchos de los papeles relativos a las mismas están en transición.
Los responsables de cargos con profundo arraigo en la actividad de las
empresas , necesitan cada vez más entender cómo puede organizar, de la mejor
manera posible, la tecnología informática. De modo similar, a los responsables
con profundos conocimientos técnicos se les exige saber interpretar y aplicar
las estrategias generales de la empresa. Por ello es importante que se
comprendan las funciones y responsabilidades asociadas con la GRI, y que exista
un acuerdo común respecto de la distribución de responsabilidades. Los
arquitectos de sistemas, los que desarrollan los sistemas y las aplicaciones,
los gerentes de los departamentos de los usuarios, etc, deben trabajar en equipo
con otros participantes empresariales interesados en la actividad informática,
para gestionar la oportunidad de cada una de las actuaciones desde su concepción
hasta la obtención de beneficios por su aplicación efectiva.
Director de los Sistemas Informáticos
105. La evaluación hacia posiciones de un fuerte
entrelazamiento entre las estrategias generales de la empresa y las se sus
sistemas informáticos, ha llevado a la necesidad de
apoyar la actuación del Director General de la compañía en sus esfuerzos por
mantener la vigilancia sobre la compañía y sus progresos. El cargo de Director
de los Sistemas Informáticos (DSI) ha sido establecido para suministrar estos
lazos de unión entre la dirección de la empresa y el grupo dedicado a la gestión
informática. El DSI es el gestor de mayor nivel encargado de los sistemas de
información, al mismo nivel que el Director Financiero o que el Director de
Operaciones. La diferencia entre el DSI y el tradicional director de los
Sistemas de Información para la Dirección radica en el alcance de la influencia
del propio DSI
(16).
106. El DSI es, en
primer lugar un directivo de la entidad y
en segundo lugar un experto técnico. Forma parte del equipo directivo de la
organización, con el mismo nivel que otros ejecutivos principales que dependen
directamente del consejo de administración o del Director General. La misión que
corresponde al DSI es desarrollar y promover la GRI, realizando la conexión
entre los sistemas informáticos y los planes estratégicos de la empresa.
107. El cargo de
DSI es relativamente nuevo y, por ello, se
ha encontrado con cierto rechazo; no obstante, a medida que las oportunidades de
aprovechar la tecnología aumenten y la conexión entre la estrategia empresarial
y los sistemas informáticos se vuelva más importante, se puede esperar que un
puesto igual o similar a éste sea necesario en la empresas y organizaciones de
gran tamaño. En las pequeñas organizaciones, el Director de Sistemas
Informáticos desempeñará, simultáneamente con su misión estratégica, la
responsabilidad diaria de la gestión del Departamento de Sistemas Informáticos.
Comité se Sistemas Informáticos
108. El liderazgo, en el nivel ejecutivo, es de suma
importancia, y la implicación de los ejecutivos de la entidad en la GRI se
consigue a través del Comité de Sistemas Informáticos
(17), el papel del Comité
es esencial, en primer lugar para el desarrollo de los planes estratégicos y, en
segundo lugar, para fijar las prioridades en los planes tácticos. La misión
principal de este Comité es hacer que la estrategia de GRI sea consecuente con
la estrategia general empresa. El Comité estará compuesto por los ejecutivos de
más nivel de cada área funcional.
109. El Comité
resuelve los temas relacionados con la
actividad empresarial y es responsable de intermediar en relación a las
necesidades de recursos de las diferentes área de la organización. El Comité es
también responsable de la adopción, aprobación y revisión de las normas y
políticas generales de la GRI, así como de aprobar, comprometer y revisar la
financiación de la GRI.
110. En empresas medianas y pequeñas, puede no haber medios
disponibles para la constitución de un Comité de Sistemas Informáticos, y en su
lugar las responsabilidades que competen al mismo pueden ser asumidas por un
subcomité del Comité de la Dirección o del Consejo Ejecutivo. Con independencia
del tamaño de la organización, es absolutamente esencial que se forme un grupo
de gerentes de alto nivel para dirigir el programa de GRI.
111. Es esencial que el equipo sea multidisciplinario y sus
miembros procedan de las diferentes funciones dentro de la empresa. Los
problemas que plantea el solapamiento entre las líneas funcionales tradicionales
de la empresa no pueden ser resueltas a menos que cada función y cada disciplina
se implique en la búsqueda de soluciones.
Los gestores de los departamentos usuarios
112. Es importante la implicación de los gestores (y el
personal) de los departamentos usuarios de los sistemas informáticos. Estos
directivos resultan claves a la hora de identificar oportunidades para la
aplicación de la tecnología informática y para solicitar que se lleven a cabo
las iniciativas informáticas en sus actividades propias. El objetivo es
conseguir que los departamentos usuarios sean socios en la gestión de los
recursos informáticos, y suministren orientación estratégica a los arquitectos
de la GRI. Los recursos informáticos exigen una inversión de importe
significativo, se construyen para su uso a largo plazo y tienen una vida
relativamente larga. Necesitan ser gestionados de forma que se permita a los
grupos de usuarios tomar parte en su construcción y funcionamiento, de manera
que puedan aportar valor a la comunidad en su conjunto, lo cual resulta mucho
más efectivo que tener sistemas de tipo individual adquiridos por grupos
específicos de interés, por ejemplo, por departamentos aislados.
113. Los gestores son responsables del funcionamiento
efectivo, así como de la planificación estratégica, en sus áreas respectivas.
Esta afirmación es tan pertinente para los recursos informáticos como para el
resto de los medios a utilizar
(18). Los gerentes deben identificar las
oportunidades que se les presentan para orientar eficazmente y para automatizar
las operaciones que sus áreas respectivas realizan, proponiendo proyectos
informáticos cuando lo juzguen apropiado. Deben participar en la formulación de
las especificaciones de los sistemas, dirigir su implementación y asegurar que
el conjunto de sistemas y proyectos informáticos que posee la organización es
coherente con sus planes de carácter estratégico.
114. El términos del funcionamiento día a día, los gerentes
son responsables de la participación en la planificación del uso de los
ordenadores en sus áreas respectivas, de contratar y formar a los empleados que
van a utilizarlos, de fomentar el desarrollo de las posibilidades que se pueden
brindar a los usuarios finales y de la relación coste-eficacia en el uso de los
medios informáticos puestos a su disposición.
115. Eventualmente, los departamentos usuarios serán los
"titulares" serán los titulares de los resultados que produzca el
proceso de
planificación. Esto implica la evaluación y coordinación de muchos cambios,
entre los que se incluyen el rediseño de los procesos empresariales, los
cambios, entre los que se incluyen el rediseño de los procesos empresariales,
los cambios en la funciones y responsabilidades, los nuevos sistemas, etc. Su
implicación, compromiso y aceptación son elementos esenciales del éxito.
Los expertos en contabilidad de gestión
116. El papel de los expertos en contabilidad de gestión,
dentro del proceso de planificación estratégica, depende de si el experto en
cuestión es un ejecutivo que pertenece al Comité de Sistemas Informáticos, el
proponente de un proyecto desde otra área funcional o un especialista en
informática. Un experto en contabilidad de gestión, en cualquier de los tres
papeles descritos, puede contribuir a proporcionar valiosas ideas acerca de la
informática y la toma de decisiones dentro de la organización y así, a través de
la GRI, ayudar a mejores el proceso de decisión y llevar a cabo el plan
estratégico de actividad de la organización.
117. En la planificación estratégica de la GRI, el experto en
contabilidad de gestión debe asegurarse de que las bases de datos, los sistemas
informáticos y los demás mas informáticos y los demás sistemas relacionados con
la toma de decisiones han sido diseñados para ayudar a:
— cuantificar e interpretar los efectos de los sucesos
económicos relacionados con el devenir de la organización;
— evaluar los datos para descubrir tendencias y relaciones
que ayuden a evaluar la implantación de los sucesos económicos;
— asegurar la integridad y precisión de la información
concerniente a las actividades y recursos de la organización;
— supervisar y medir el rendimiento, e introducir acciones
correctivas cuando sea necesario;
— implantar un sistema de información que suministre a los
usuarios, dentro de la organización, informes con las características de
oportunidad y relevancia adecuados a sus responsabilidades, y
— preparar estados financieros y otros informes.
Los auditores internos
118. Los auditores internos responsables de los siguientes
extremos:
— valorar los controles de los sistemas informáticos,
comenzando en los estadios de análisis y diseño del proyecto, y continuando a
lo largo de la vida de cada uno de los sistemas;
— determinar si los recursos informáticos tienen la
seguridad adecuada, y
— supervisare la actividad del sistema informático para
asegurar que se ejecuta de acuerdo con las normas y procedimientos
especificados.
Los especialistas en sistemas informáticos
119. Los especialistas en sistemas informáticos son
responsables de los siguientes extremos:
— trabajar con el equipo de dirección para identificar las
oportunidades de obtener ventajas estratégicas a través del uso de sistemas
automatizados;
— percibir el impacto que tienen en la organización las
tecnologías actuales y las que están en desarrollo, y facilitar su
introducción en la empresa cuando sea apropiado;
— planificar el desarrollo de los sistemas, lo que incluye
el desarrollo de normas, la gestión de los datos, la redacción de los
proyectos de infraestructura de los sistemas informáticos (equipos físicos,
programas informáticos, bases de datos y comunicaciones) que la organización
quiere poner en funcionamiento, y luego desarrollar los planes específicos
para conseguir esta infraestructura;
— desarrollar y mantener la infraestructura de los sistemas
informáticos, de manera que proporcionen el respaldo a las necesidades
actuales y faciliten el apoyo a las nuevas que puedan surgir;
— desarrollar sistemas de información de carácter
particular, lo que implica el análisis, diseño, programación y pruebas de las
nuevas aplicaciones creadas;
— asegurar que los diferentes proyectos de desarrollo de
sistemas son coherentes entre sí, evitando la duplicación innecesaria de los
datos o los procesos, y
— comprender los objetivos de actividad y las
responsabilidades funcionales de las áreas a las que sirven los sistemas de
aplicaciones (por ejemplo finanzas, mercadotecnia, etc.)
APÉNDICE
TÉCNICAS DE MODELIZACIÓN
Modelos de actividad
Los
modelos de actividad sirven como se puente entre la
identificación de las necesidades estratégicas (fase 1) y de la definición de la
infraestructura tecnológica (fase 3). En ellos se describe como va a operar la
organización una vez que hayan sido implementados los planes estratégicos de la GRI.
Hay tres
objetivos básicos al construir los modelos de
actividad:
— añadir detalles relevantes para los procesos críticos o
los datos identificados;
— especificar la relación existente entre los procesos
críticos y los datos correspondientes puesto que hasta este punto unos y otros
han sido analizados de forma individual, y
— describir las operaciones existentes, en la medida que las
nuevas necesidades que se acaban de identificar pueden quedar integradas en
las necesidades, funciones y actividades existentes.
En el
ejemplo del párrafo 36. se identifican como necesidades
estratégicas las estrategias comerciales y de promoción de ventas, así como la
información acerca de los posibles clientes. Antes de que se puedan
especificarse las implicaciones tecnológicas de tales necesidades, deben ser
examinadas en mayor detalle mediante la construcción de los correspondientes
modelos de la actividad. En estos modelos se describe cómo se llevan a cabo en
la actualidad esos procesos, y cómo pueden hacerse más efectivos en el futuro.
El modelo específica quién desarrollará las estrategias, así como que
actividades y decisiones están implicadas en este desarrollo. De forma similar,
los modelos especificarán qué tipo de información se recoge actualmente, qué
tipo de información debe ser recogida y cómo sería usada tal información para
adoptar conocimiento sobre futuros clientes. El proceso riguroso de construcción
de modelos de actividad pueden también servir para identificar las actividades
que, se estén ejecutando en el momento actual, no aportan valor.
Características de
los modelos de actividad
Los modelos de
empresa poseen características que hacen de
ellos unas herramientas descriptivas muy efectivas:
— Son independientes de las tecnologías específicas de
equipos físicos o de programas informáticos, de manera que no precisan cambios
de si la empresa adopta nuevas tecnologías.
— Son independientes de la estructura organizativa actual, y
por tanto sirven para detectar las áreas donde la estructura puede ser
modificada y obtener más eficacia.
— Separan procesos de actividad de los sistemas automáticos
utilizados para procesar los datos, lo que facilita el desarrollo de sistemas
que dan servicio a diferentes áreas dentro de la organización.
— Están construidos de arriba a abajo, de forma jerárquica,
lo que limita la cantidad de detalles que han de ser recogidos y absorbidos
cada vez.
— Proporcionan un lenguaje común para discutir sobre
procesos y datos concernientes a la actividad, lo que facilita la comunicación
entre los participantes en los procesos de planificación y desarrollo
informáticos.
— Suministran la documentación, en forma de diagramas, que
puede ser entendida por personas sin conocimientos técnicos. De esta forma
contribuyen a mejorar la comunicación entre los gestores y los especialistas
en sistemas informáticos.
Los modelos de actividad están basadas en información
recogida por toda la organización. Entre las fuentes de datos están
comprendidos:
— los documentos relacionados con la planificación
— las entrevistas con los gerentes y con el resto del
personal
— el examen de los formularios, archivos y registros
actuales
— el examen de los manuales de procedimientos operativos
— las discusiones, en pequeños grupos, con los empleados
claves
Existen diferentes técnicas específicas para elaborar modelos
de actividad, aunque todas ellas comparten las características enunciadas
arriba. muchas organizaciones y firmas de consultoría han establecido sus
propias normas para la construcción de modelos de actividad, y existen asimismo
paquetes de programas automáticos, denominados genéricamente herramientas de
Ingeniería de Programas Asistidos por Ordenador (CASE)
(19), que analiza la
integridad y consistencia de los modelos de actividad, y se encargan de producir
la documentación correspondiente.
Las organizaciones elaboran dos tipos de modelos de
actividad: modelos de proceso y modelos de datos.
Seguridad de los datos procedentes de los modelos de
actividad
Debido a que el desarrollo de los modelos de actividad
necesita una gran cantidad de datos, recogidos por diferentes personas en un
intervalo de tiempo, es necesario gestionar adecuadamente y velar por la
seguridad de la información recogida. La herramienta fundamental para conseguir
esto es un diccionario de datos. Son los especialistas informáticos los
responsables de mantener el diccionario de datos y desarrollar las políticas y
normas para su control.
Un diccionario de datos es un depósito central de información
acerca de cada elemento de los que componen el modelo de actividad (proceso,
flujos de datos, fuentes de información interna y externa, entidades, relaciones
y atributos).
Por ejemplo, el flujo de datos de una "orden de compra" puede
ser definido como
(20):
Orden de compra = Número de orden de compra + Nombre del
proveedor + Dirección del proveedor + Fecha de iniciación de la orden + Forma de
entrega + {Artículo número + Artículo + Descripción + Cantidad + Precio + Total}
+ Total + Autorización.
En la expresión anterior las llaves {} encierran a los
componentes se repiten muchas veces. Pueden existir entradas en el diccionario
de datos para cada componente de esta definición. Por ejemplo, Cantidad puede
ser definido como un número entero mayor que cero.
El diccionario de datos asegura que:
— cada elemento está nombrado y definido de forma única y
coherente
— los elementos se usan uniformemente en el conjunto de
modelos de actividad que se haya construido
— es posible determinar los efectos que produce el cambio de
un elemento sobre el resto del sistema
Un diccionario de datos puede ser mantenido o bien
manualmente, utilizando tarjetas archivables o un clasificador de páginas
intercambiables, o bien automáticamente, utilizando un programa comercial de
diccionario de datos. Las herramientas de CASE para modelos de actividad llevan
incorporados sus propios diccionarios de datos.
Modelos de proceso
Los modelos de proceso describen las actividades llevadas a
cabo por la organización. Si se piensa en la organización
como un sistema compuesto de partes interdependientes, el
objetivo al desarrollar un modelo de actividad (o diagrama
de flujos de datos) consiste en especificar cómo opera el
sistema.
Un modelo de procesos tiene cuatro componentes:
1. Proceso a actividades
(representados con círculos)
2. Flujos de datos, que representan
los flujos de información dentro, fuera o entre los procesos (representado por
flechas)
3. Fuentes de información exteriores
al sistema que se está examinando (representadas por medio de rectángulos)
4. Fuentes de información interiores
del sistema que se está examinando (representadas por líneas paralelas)
El diagrama que sigue es un ejemplo de un modelo de
actividad. Se trata de un diagrama simplificado que muestra las relaciones entre
las cuatro actividades fundamentales de una empresa de distribución, que se
denominan de la siguiente manera: Administración de ventas, Gestión de recursos
financieros, Gestión de productos y Gestión de proveedores.
Nótese que se ponen de manifiesto tres importantes fuentes de
información externas a la organización: fuentes del sector, clientes y
proveedores. Por otra parte, las tres fuentes importantes de datos internos son:
el Archivo de clientes, el Archivo de proveedores y Archivo de productos.
Nótese también que cada actividad se compone de
subactividades. Por ejemplo, la actividad de Gestión de productos de diagrama
incluye las siguientes subactividades: Mantenimiento de la información del
producto, Recepción de productos y Expedición de productos. Cada subactividad
Mantenimiento de la información de producto puede incluir a su vez, por ejemplo,
las siguientes subactividades: Creación de nuevos productos, Poner a día el
inventario y Calcular el coste del producto.
Definir subactividades en un modelo de procesos se denomina
descomposición. Con ello se limita la cantidad de datos que deben recogerse y
absorberse cada vez, puesto que los detalles de cada actividad se específica en
un modelo principal.
(Ver ilustración)
Modelos de datos
Los modelos de datos se utilizan para describir los ítem de
información que deben ser recogidos en la organización, así como la
interrelación que guardan entre sí tales ítem. Un modelo de datos (o diagrama de
relaciones entre entidades) tiene tres componentes:
— entidades, que son conceptos de interés principal dentro
de la organización (representadas como cajas)
— las relaciones que ligan a las diferentes entidades
(representadas como líneas)
— atributos, que son característicos de las entidades
(rotulados dentro de la caja de la entidad que describen)
Se presenta un ejemplo simplificado de modelo de datos en el
diagrama de modelo de datos adjunto. En él se describe la parte de la
información relevante para la empresa distribuidora descrita en el diagrama del
modelo de procesos, Nótese que para cada entidad se muestra un atributo, o a
veces más de uno, en letra negrita; este es el código fundamental, la
característica que lo identifica específicamente. Por ejemplo, los clientes se
identifican específicamente por una Cuenta de Cliente, para las entregas, el
código se compone de un Número de pedido, Número de producto y Fecha de entrega.
Las relaciones entre las entidades describen las reglas de
actividad dentro de la organización, que están a su vez representadas por
flechas son dobles y otras son simples; por ejemplo, la relación "hace pedido",
colocada entre un cliente y una orden de los clientes exhibe una única punta de
flecha en la parte superior y dos puntas en la inferior. Esto es para indicar
que cada pedido está asociado a un único cliente, pero un cliente puede estar
asociado con más de un pedido.

GLOSARIO
| Atributo |
Es cada uno de los elementos de un modelo de datos. Los atributos se
utilizan para especificar las características de las entidades. |
Herramientas
CASE |
Herramientas de Ingeniería de Programas Asistidos por Ordenador
(Computer-Aided
Software Engineering). Son paquetes de programas que ayudan en el diseño
y desarrollo de sistemas informáticos. Permiten crea documentación (tal como
diagramas de modelos de datos o de procesos y diccionarios de datos) que se
almacena en el ordenador. |
Diccionario
de datos |
Un depósito central de información sobre elementos dentro de los modelos de
procesamiento y de los modelos de datos. Contiene la definición de cada
elemento. |
| Flujo de datos |
Es cada uno de los elementos de un modelo de procesos. El flujo de datos
representa información que entra o que sale de un proceso. |
| Modelo de datos |
Es todo diagrama que describe el conjunto de datos de la organización,
explicando cómo están interrelacionadas las diferentes series de datos. |
| Descomposición |
Es el resultado de dividir un proceso particular, dentro de un modelo de
procesos, de manera que puedan definirse subprocesos con mayor detalle. |
| Entidad |
Es un elemento dentro de un modelo de datos. Una entidad es una categoría de
objeto que tiene interés para la organización, de manera que ésta mantiene
ciertos datos que se refieren al mismo (ejemplos pueden ser un cliente o un
empleado). |
Centro de
información |
Una entidad dentro de la organización que ayuda a los usuarios finales a
desarrollar aplicaciones informáticas. |
Arquitectura
de red |
Implica la definición tanto de redes de área local como de líneas y
controles de telecomunicación remota con el fin de apoyar los terminales e
impresoras distribuidas, así como de enlazar con unidades centrales de
proceso remotas. |
Clave
fundamental |
Uno de los atributos de una entidad, dentro de un modelo de datos, que sirve
para identificar de forma unívoca dicha entidad, tal como el código de un
empleado. |
| Proceso |
Cada elemento dentro de un modelo de procesos. Un procesos representa una
actividad dentro de la organización. |
Modelo
de procesos |
Es un diagrama que describe las actividades de la organización, así como la
manera en que dichas actividades están interrelacionadas. Hay disponibles
diferentes técnicas para producir modelos de procesamiento. La clase
específica de modelo que se ha mostrado en esta Declaración es un diagrama
de flujos de datos. |
| Relación |
Es todo elemento en un modelo de datos. Una relación es una asociación
que tiene lugar entre entidades. |
Arquitectura
objetivo |
Es un esquema de las tecnologías de la información de la organización, que
muestra como quedará después de haber completado la implantación que se
quiere llevar a cabo. Se puede hablar de arquitectura objetiva para los
datos, para los sistemas de aplicaciones, para los sistemas físicos y para
la tecnología de las comunicaciones. |
| Arquitectura objetiva |
Es el conjunto de especificaciones para los sistemas de programas
informáticos, para los sistemas físicos y para las redes. Se desarrolla
después de las después de las arquitecturas correspondientes a los datos y
de las aplicaciones. |
BIBLIOGRAFÍA
ARMITAGE, H. M.: Linking Management Accounting Systems
With Computer Techonology (Hamilton, ON: The Society of Management
Accountants of Canada, 1985).
BUCKHOLTZ, Thomas J.: Informationn Profiency: Your Key to
the Information Age (New York, NY: Van Nostrand Reinhold, 1995).
HICKS, J. O.: Information Systems in Business, 2.ª Ed.
(St. Paul, MN: West Publishing Company, 1990).
JACKSON, I. R.: Corporate Information Management (Englewood
Cliffs, NJ: Pretice Hall, 1986)
KEN, P. G. W., y L. A. WOODMAN: "What to do With all Those
Micros". Harvard Business Review (September-October 1984). 142-150.
KEER, James M.: The IRM Imperative Strategies for Managing
Information Resources (Toronto, ON: John Wiley and Sons, Inc., 1991).
KEYES Jessica: Infortrends: The Compettive use of
Information (Toronto, ON: McGraw Hill, 1993).
LUCAS, H. M.: Managing Information Services (New York,
NY: Mcmillan Publishing Company, 1989).
Management of Electronic Recorda: Issues & Guidelines,
Preparad by the Advisory Committee for the Coordination of Information Systems (ACCIS),
United Nations (New York, NY, 1990).
McGEE, James, y Lawrence PRUSAK: Managing Information
Strategy (Toronto ON: John Wiley & Sons, Inc., 1993).
MYLOTT, Thomas R., III: Computer Outsourcing: Managing the
Transition of Information Systems (Englewood Cliffs, NJ: Prentice Hall,
1988).
PARKER, M. M., y R. J. BENSON: Information Economics.
Linking Business Performance to Information Technology (Englewood Cliffs,
NJ: Prentice Hall, 1988).
ROCKART, J. F.: "The Line Takes the Leadership - IS
Managemente in a Wired Society", Sloan Management Review (Summer 1988),
57-64.
VAN DER HOVEN, JOHN: "Data Base Management, IRM: An
Enterprise View of Data", Information Systems Management (Summer 1995),
69-72.
|
|