PLANEACIÓN E IMPLEMENTACIÓN DEL CAMBIO EMPRESARIAL

 

La planeación y el desarrollo de los sistemas de información nuevos suelen ser complejos. La planeación de sistemas suele requerir la creación o el ajuste de planes estratégicos debido al gran impacto de la IT sobre los modelos y las operaciones empresariales. Los participantes en el desarrollo deben traducir una oportunidad empresarial, una solución a un problema o una directiva, en un conjunto funcional de componentes de hardware, software y telecomunicaciones. Una vez establecido un proyecto de desarrollo, muchas personas de diferentes disciplinas participan en el esfuerzo. Las habilidades de comunicación son muy importantes para obtener resultados exitosos.

PLANEACIÓN DE LOS SISTEMAS DE INFORMACIÓN.

                               

En años recientes, cada vez más corporaciones han implementado IS empresariales como sistemas ERP o sus componentes principales, sistemas SCM y CRM y otros, que atienden a toda la organización o muchas de sus unidades. Es enorme la inversión de recursos en tales sistemas, tanto en términos financieros como de otro tipo. También es inmenso el riesgo al implementar sistemas tan grandes. Si la implementación tiene éxito, el sistema nuevo cambia en forma significativa el modo en que la organización realiza negocios e incluso los productos o servicios que vende. Por todas estas razones, es necesario planear la implementación de los sistemas de información, ya sea que se desarrollen en forma interna, que otra compañía los haya hecho sobre pedido o que sean adquiridos y adaptados para la organización. Al planear, es importante alinear las estrategias del IS con las estrategias generales de la organización. (Algunas organizaciones prefieren emplear el término “planeación de la IT” en vez de “planeación del IS”. En este análisis, los términos se usan de manera indistinta.)

Pasos en la planeación de los sistemas de información.

La planeación del IS incluye algunos pasos importantes que son parte de cualquier proceso de planeación exitoso: 

• Crear una declaración de misión corporativa y del IS. 

• Expresar con claridad la visión para el IS dentro de la organización.

• Crear planes estratégicos y tácticos para el IS. 

• Preparar un plan para las operaciones que lograrán la misión y la visión. 

• Desarrollar un presupuesto para asegurar que los recursos estén disponibles con el fin de lograr la misión y la visión.

                                   

La planeación de la IT no es muy diferente de la planeación de cualquier otra decisión de recursos, comenzando con la visión de cómo se usarán los recursos para lograr las metas y esas ideas en los proyectos y recursos que se van a asignar para completar con éxito los proyectos. En años recientes, se ha gastado una proporción cada vez mayor de los fondos para la IT en software y casi todos los fondos se asignan para comprar y adaptar software, en vez de desarrollarlo de manera interna o asignar su desarrollo a otra empresa.

Beneficios de la estandarización en la planeación. 

                             

Una meta y ventaja importante en la planeación es la estandarización. Cuando la administración decide adoptar ciertos recursos de la IT para todas sus unidades, sin tomar en cuenta su misión o su ubicación, estandariza su IT. La estandarización produce varios beneficios: 

• Ahorros en los costos. Cuando la organización decide comprar el mismo hardware o software para todas sus unidades, tiene mayor fuerza de negociación y, por lo tanto, obtiene precios más bajos de los vendedores. Esto se aplica al comprar o arrendar computadoras de todas clases mainframes, medianas y personales y a la obtención de licencias del software. 

• Una capacitación eficiente. Es más fácil capacitar empleados para que utilicen una pequeña variedad de software que enseñarles cómo emplear una gran variedad. Se requiere menos tiempo. Por qué debe... de un capacitador y lo que es más importante los empleados dedican menos tiempo a la capacitación y más tiempo a sus tareas normales. Esto también ahorra el costo de dedicar menos horas de mano de obra a la capacitación. Incluso si cada empleado sólo emplea una sola aplicación, pero la organización tiene varias aplicaciones para el mismo propósito, el tiempo de capacitación es extenso. 

• Un soporte eficiente. La estandarización en una cantidad pequeña de modelos de computadoras y aplicaciones de software permite al personal de IT especializarse en el hardware y el software al que dan soporte. Las habilidades más enfocadas facilitan el reclutamiento de personal de soporte por parte de la organización y produce un servicio más satisfactorio para los usuarios.

De la planeación al desarrollo.

                         

Después de planear un IS o un conjunto de IS, la administración decide cómo obtener los sistemas. En casi todos los casos, “sistemas” significa software. Por ejemplo, los sistemas CRM y SCM rara vez requieren hardware especializado. Cada vez más sistemas nuevos se adquieren y adaptan para las necesidades de una organización, en vez de desarrollarse de manera interna, aunque el desarrollo interno todavía ocurre en muchas organizaciones. Los métodos para el desarrollo de sistemas son los mismos, sin tomar en cuenta quién desarrolla los sistemas, la organización o su vendedor.

EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.

                          

Los IS grandes que abordan problemas estructurados, como los sistemas de contabilidad y de nómina y las aplicaciones de soporte de la empresa, suelen concebirse, planearse, desarrollarse  y mantenerse dentro de una estructura llamada el ciclo de vida del desarrollo de sistemas (SDLC). 

El método también se denomina desarrollo “en cascada” porque consiste en varias fases distintas que se siguen en forma metódica, y los desarrolladores completan cada fase de modo secuencial. Los desarrolladores no entregan segmentos del sistema antes de concretar el sistema completo. Aunque distintos textos asignan nombres diversos a las diferentes fases y fases secundarias del SDLC o las organizan de manera un poco distinta, en términos generales, el proceso sigue los mismos pasos. Si bien el SDLC es una metodología poderosa para el desarrollo de sistemas, las organizaciones a veces se ven forzadas a reducir los tiempos y saltarse un paso aquí o allá. A veces, las presiones de tiempo, las decisiones monetarias y otros factores, conducen a los desarrolladores a autorizar métodos diferentes para el desarrollo de sistemas. 

El método SDLC supone que la vida de un IS comienza con una necesidad, seguida por una valoración de las funciones que debe tener un sistema para atender dicha necesidad y termina cuando los beneficios del sistema ya no sobrepasan sus costos de mantenimiento, en cuyo punto comienza la vida de un sistema nuevo. Por lo tanto, el proceso se llama un ciclo de vida. Después de la fase de planeación, el SDLC incluye cuatro fases principales: el análisis, el diseño, la implementación y el soporte.  Las fases de análisis y de diseño se dividen en varios pasos, tal como se describe en la descripción siguiente.

1. Fase de Análisis: La fase de análisis de sistemas es un proceso de cinco pasos diseñados para responder estas preguntas: 

• Investigación ¿Cuál es el proceso empresarial al que el sistema va a dar soporte? ¿Cuál oportunidad empresarial quiere usted que aproveche el sistema, cuáles problemas quiere que resuelva o cuál directiva debe satisfacerse? 

• Estudio de factibilidad técnica ¿Existe la tecnología para crear el sistema que quiere? Estudio de factibilidad económica ¿Cuáles recursos necesita para implementar el sistema? ¿Los beneficios del sistema sobrepasan sus costos? 

• Estudio de factibilidad operativa ¿El sistema será utilizado en forma adecuada por los usuarios a quienes está dirigido (empleados, clientes, proveedores)? ¿El sistema será manejado a toda su capacidad? 

• Definición de los requerimientos ¿Cuáles características pretende que tenga el sistema? ¿Cuáles interfaces tendrá el sistema con otros sistemas?

1. Investigación: El primer paso en el análisis de sistemas es la investigación, la cual determina si existe una necesidad real de un sistema y si el sistema se considera factible. Se integra un pequeño equipo formado por un representante del ejecutivo responsable, uno o dos analistas de sistemas y representantes de las unidades empresariales que utilizarían el sistema nuevo o que serán afectadas por él para realizar una investigación preliminar rápida. El equipo interroga a los empleados en sus estaciones de trabajo para conocer de manera directa el modo en que realizan actualmente sus deberes y los problemas con el sistema actual. Este contacto directo con los usuarios permite a los trabajadores expresar sus ideas acerca del modo en que les gustaría que funcionara un IS nuevo para mejorar su trabajo. 

2. Estudio de factibilidad técnica: Un IS nuevo es técnicamente factible si existen sus componentes o se pueden desarrollar con las herramientas disponibles. El equipo también debe considerar los compromisos existentes de la organización con el equipo de hardware, software y telecomunicaciones. Por ejemplo, si la compañía adquirió en forma reciente cientos de unidades de cierta computadora, no es probable que la administración apruebe la compra de otro modelo de computadoras para una sola aplicación nueva. Por lo tanto, la investigación debe determinar si el sistema propuesto funciona de manera adecuada con el hardware existente. 

3. Estudio de factibilidad económica: Igual que cualquier proyecto, el desarrollo de un IS debe tener una justificación económica, de modo que las organizaciones realizan un estudio de factibilidad económica. Es decir, durante la vida del sistema, los beneficios deben sobrepasar los costos. Con este propósito, los analistas preparan un análisis costo/beneficio, el cual puede ser una hoja de cálculo que muestra todos los costos efectuados por el sistema y todos los beneficios que se esperan de su operación.

4. Estudio de factibilidad operativa: El propósito del estudio de factibilidad operativa es determinar si el sistema nuevo se utilizará como se pretende. De manera más específica, este análisis responde las preguntas siguientes: 

• ¿El sistema se adaptará a la cultura de esta organización? 
• ¿Todos los usuarios emplearán el sistema a toda su capacidad? 
• ¿El sistema interferirá con las políticas de la empresa o las leyes vigentes?

5. Definición de los requerimientos Cuando el análisis determina que el sistema propuesto es factible, se instala el equipo del proyecto. La administración o la empresa consultora nominan a un líder del proyecto que integra un equipo para desarrollar el sistema hasta que esté preparado para ser entregado. El equipo incluye analistas de sistemas, programadores y, a menudo, representantes del grupo de usuarios propuesto.

2. Fase  de  Diseño.

Con una lista de requerimientos pormenorizada, el equipo del proyecto comienza el paso siguiente en el desarrollo de sistemas, el diseño del sistema nuevo. El propósito de esta fase es plantear los medios para cumplir todos los requerimientos empresariales detallados en el informe de requerimientos. El diseño de sistemas comprende tres pasos: una descripción de los componentes y cómo funcionarán, la construcción y la prueba del sistema. 

Descripción de los componentes se convierte en una descripción de cómo se adaptarán ciertos componentes para las necesidades específicas de la organización y la construcción son los cambios reales en el código de programación.

• Un diagrama de flujo de datos (DFD) sirve para describir el flujo de los datos en una operación empresarial y emplea sólo cuatro símbolos para estos elementos: las entidades externas, los procesos, los almacenes de datos y la dirección en la cual fluyen los datos Entre las entidades externas están las personas y los grupos de personas ajenos al sistema, como los clientes, los empleados, los otros departamentos de la organización u otras organizaciones. Un proceso es cualquier evento o secuencia de eventos en la cual los datos se modifican o se afectan, como la transformación de los datos en información o la aplicación de los datos en la toma de decisiones. Un almacén de datos es cualquier forma de datos inactivos, como un archivo o una base de datos.

• Lenguaje de Modelado Unificado (UML) Debido a que cada vez más aplicaciones desarrolladas se orientan a objetos, se requería un nuevo modo de describir el software deseado. Durante la década de 1970, se desarrollaron varios grupos de diagramas, pero a fines de la década de 1990 surgió un estándar de facto: el UML. El Lenguaje de Modelado Unificado (UML) es un estándar gráfico para apreciar, especificar y documentar el software. 

• Construcción Una vez elegidas las herramientas de desarrollo del software, comienza la construcción del sistema, el cual es programación, en gran medida. Los programadores profesionales traducen a programas las entradas, las salidas y los procesos descritos en los diagramas de flujo de datos. El esfuerzo suele tardar meses o incluso años (en cuyo caso, es posible que los usuarios no sean bien atendidos debido a los cambios en las necesidades empresariales). Cuando se concluye un módulo de programa, se prueba. La prueba se realiza mediante un repaso ligero y una simulación.

• Prueba del sistema Si bien la simulación con cada módulo funciona como prueba, es importante probar el sistema integrado completo. Se compara el sistema contra los requerimientos del sistema originalmente definidos en la fase de análisis, al ejecutar por el sistema los datos normales. Se examina la calidad del resultado y se miden los tiempos de procesamiento para asegurar que se cumplen los requerimientos originales.

3. Fase de Implementación La implementación de un IS nuevo, también llamada entrega, consta de dos pasos: la conversión y la capacitación. Aunque la capacitación puede venir antes que la conversión, si la capacitación se hace en el trabajo, puede ocurrir después de la conversión. La conversión ocurre cuando una operación pasa de emplear un sistema antiguo a emplear uno nuevo. La conversión es un momento difícil para una organización. Los operadores necesitan acostumbrarse a los sistemas nuevos y aunque un sistema haya sido probado minuciosamente, la conversión puede contener algunas sorpresas desagradables si ciertos defectos o problemas no se han descubierto con anticipación. Es posible que se retrasen los servicios a otros departamentos y a los clientes y se pierdan datos. Existen cuatro estrategias básicas de conversión para dirigir la transición

• Conversión en paralelo En la conversión en paralelo se utiliza el sistema antiguo junto con el nuevo durante un periodo predeterminado. Esta duplicación reduce el riesgo, porque si falla el sistema nuevo, las operaciones no se detienen y la organización no sufre daños. Sin embargo, la conversión en paralelo es costosa debido a los gastos, sobre todo el costo de la mano de obra, asociados con ejecutar dos sistemas. 

• Conversión en fases Los IS, sobre todo los grandes, se dividen en módulos funcionales, los cuales se ponen en operación uno a la vez, un proceso llamado conversión en fases. Por ejemplo, la conversión de un IS para contabilidad se hace en fases y en ella se convierte primero el módulo de cuentas por cobrar, después las cuentas por pagar, luego el libro mayor general y así en forma continua. Un sistema de administración de la cadena de suministro se implementa un módulo a la vez: primero, el módulo de pedidos del cliente; a continuación el módulo de embarques, después el módulo de control del inventario y así en forma sucesiva, hasta el módulo de cobro. Este método en fases también reduce el riesgo, aunque se retrasan los beneficios de aplicar el sistema integrado completo. 

• Conversión abrupta En una conversión abrupta, también llamada conversión de corte rápido, se descarta el sistema antiguo y el nuevo se encarga de toda la operación empresarial para la cual fue desarrollado. Esta estrategia es muy arriesgada, pero si tiene éxito, su costo es muy bajo, porque no se gastan recursos en ejecutar dos sistemas en paralelo y se captan de inmediato los beneficios del sistema nuevo completo.

• Conversión mediante un piloto Si más de una unidad empresarial va a utilizar el sistema nuevo, primero se introduce durante un periodo en una sola unidad, en donde se abordan los problemas y el sistema se pule antes de implementarlo en las demás unidades empresariales. Esta conversión de prueba también es posible para los sistemas compartidos por muchos departamentos y lugares separados y ocurre cada vez más a menudo debido a la creciente popularidad de las redes internas y externas. 

4. Fase de Soporte La función de los profesionales de la IT no termina con la entrega del sistema nuevo. Deben darle soporte y asegurar que los usuarios lo emplean de manera satisfactoria. El soporte incluye dos responsabilidades principales: 

• El mantenimiento y la ayuda a los usuarios.El mantenimiento consiste en la depuración y la actualización (hacer cambios y adiciones) después de la implementación, lo cual incluye incorporar funciones que se consideraron al principio, pero después se pospusieron para cumplir con las limitaciones de presupuesto y tiempo. Por lo general la actualización implica el mayor esfuerzo. 

• La depuración es la corrección de los defectos o problemas en los programas que no se descubrieron durante las pruebas. La actualización es revisar que el sistema cumpla con las cambiantes necesidades empresariales que ocurren después de la fase de implementación. Por ejemplo, si una compañía recopila datos personales para análisis de mercados, los administradores pueden pensar emplear el IS para recopilar más datos, lo cual puede requerir campos nuevos en las bases de datos.

• El mantenimiento eficiente y eficaz de un sistema sólo es posible si se prepara una buena documentación mientras se desarrolla el sistema y si el código se escribe de una manera estructurada y fácil de seguir. La documentación está formada por tres tipos principales: los libros impresos, los documentos electrónicos y la documentación dentro del programa. Esta última cubre los comentarios no ejecutables en el código, los cuales sólo se ven al revisar el código fuente de la aplicación. Se puede observar este tipo de documentación cuando se recupera el código fuente de muchas páginas Web. La documentación dentro de un programa describe con brevedad lo que hace cada módulo del programa y, a veces, quién lo desarrolló. La documentación impresa y electrónica se prepara para los programadores, con el fin de que comprendan mejor cómo revisar el código y para los usuarios, quienes pretenden aprender las diferentes funciones de la aplicación.

INTEGRACIÓN DE LOS SISTEMAS.

                 

Las empresas deben luchar a menudo con ambientes altamente distribuidos y heterogéneos llenos de aplicaciones para tareas especiales, los cuales no se pueden consultar mediante los sistemas utilizados para otras tareas. Estos sistemas distintos no “se hablan” porque se ejecutan en sistemas operativos diferentes (o, como dicen los profesionales de los IS, en plataformas distintas). Gran parte de lo que hacen los profesionales de la IT es la integración de sistemas, más que el análisis y el desarrollo de un IS independiente. 

La integración de sistemas atiende las necesidades de información de una organización completa o, cuando menos, de una división importante de ella. Los analistas consideran los IS existentes, aunque a menudo disparejos y preparan un plan para integrarlos de modo que los datos fluyan con más facilidad entre las diversas unidades de la organización y los usuarios puedan consultar diferentes tipos de datos mediante una interfaz común. 

En consecuencia, muchas de las empresas de servicios de IS se llaman a sí mismas integradores de sistemas. La integración de un sistema se ha vuelto cada vez más importante, sobre todo porque cada vez más IS se conectan a sitios Web, porque se integran más bases de datos heredadas a las nuevas aplicaciones de una empresa como los sistemas SCM y ERP y por la creciente conexión de los IS entre las organizaciones. Los sistemas heredados son sistemas antiguos que las organizaciones deciden seguir usando porque la inversión en un sistema nuevo no justificaría las mejoras o porque los sistemas antiguos tienen ciertas ventajas que no se pueden obtener con los sistemas más recientes.