MARCO TEORICO PROCESOS DE NEGOCIOS BORRADOR 2001 MARCO TEORICO El aporte que la tecnología de la información puede entregar a una organización puede ser visto en tres niveles: Procesos, Aplicaciones y Datos. Este orden es el más adecuado para abordar un proyecto de diseño o rediseño de los procesos de una organización. Sin embargo, para explicarlos se analizarán en sentido inverso. Los Datos Los datos son el nivel básico de un sistema de información, existen diversas formas de almacenarlos como puede ser el papel ó un medio magnético en cuyo caso conforman lo que se denomina archivos. Un aspecto muy importante es la forma en que estos archivos se organizan y son vistos por las aplicaciones; en la actualidad existe una indiscutible superioridad del modelo cliente−servidor utilizando como lenguaje de acceso y grabación al SQL. Un proyecto para una empresa debería tener como trasfondo la utilización del modelo cliente−servidor con SQL. Una vez declarado esto, se puede decir que, para trabajar las bases de datos del tipo relacional como son las que operan en este modelo, existen diversas tecnologías de representación de los datos. Pudiéndose utilizar, un modelo entidad−relación que permite describir muy bien los archivos (tablas en lenguaje SQL) y sus relaciones. Para este tipo de tecnología, existen indicadores que permiten ver el potencial del modelamiento de una base de datos. El potencial del modelo de datos, está en la eficacia para responder con celeridad a las aplicaciones clientes en las consultas que éstas requieran. Hay varias herramientas para manejar el modelo de datos entidad−relación. Pudiéndose utilizar el System Architect. Este software tiene la ventaja de apoyar también en la tarea de definición de las aplicaciones, y es uno de los paquetes con amplio uso en las empresas nacionales. Las Aplicaciones Este nivel también se denomina las funciones y considera todas la reglas que la empresa se dá para manejar el negocio en relación con sus datos. Dichas reglas pueden pertenecer a un manual de procedimientos o ser informales. En el caso computacional, las funciones están muy relacionadas a un algoritmo. Por ejemplo, un banco para un cierto crédito aplica tasas de interés que devengan en el monto de un dividendo. Esta lógica se concreta a través de una función que permite ver los datos del cliente (como capacidad de crédito), los datos del crédito (como plazo y monto) y relacionarlos para entregar un resultado como el monto del dividendo a pagar. Hoy día en el modelo cliente−servidor SQL se puede generar un archivo con las funciones y por lo tanto tener de esta manera no sólo un servidor de base de datos sino también tener un servidor de funciones. Esta tecnología es ampliamente conocida a través del concepto de procedimientos almacenados. Sin embargo, 1 también existen otras formas de almacenar estas funciones que no necesariamente involucran al servidor de Base de datos. Existe una parte muy significativa de las funciones, que aparece mucho más clara cuando a éste nivel se le denomina Aplicación; y se refiere a cómo la función se presenta al usuario final: la interfaz con el usuario. Es muy probable que en un futuro existan objetos computacionales que incluyan ambos elementos: algoritmo e interfaz y que éstos puedan ser almacenados en algún servidor. Los Procesos Los procesos han sido virtualmente marginados del mundo de la informática, de manera que el acercamiento que ha tenido el análisis de sistema se ha reducido a los dos niveles anteriores: Datos y Funciones. De esta manera, es común encontrar sistemas computacionales que manejan un excelente modelo de datos y una serie de funciones que los presentan y resuelven la manera en que la empresa ve estos datos, pero dichas funciones no tienen un proceso en que se inserten. Incluso éstos sistemas pueden llegar a tener una interfaz con el usuario hecha en Windows, la que deslumbra al usuario final y en una primera impresión dicho usuario tenga la impresión de estar frente un software de tecnología muy reciente. Sin embargo, el asunto del proceso es central por lo que se ilustrará a través de un ejemplo. Supóngase una empresa de atención a cliente que recibe órdenes de compra telefónicas. El depto. de informática, construyó un software que permite ingresar esta orden de compra con todos sus antecedentes, entre los cuales esta el cliente. El cliente, en los sistemas más modernos es ubicado a través de su razón social o nombre, con lo cual es posible traer el Rut, dato necesario al definir la Orden de compra. Supongamos que el cliente no está, es decir es nuevo. En este caso un sistema en la tradición datos−funciones trae a pantalla la ficha del cliente con todos sus antecedentes. Estos antecedentes no son necesarios para la Orden de compra en cuestión, pero sí lo pueden ser en trámites posteriores. Como los datos requeridos son extensos el vendedor opta por no llenar todos los datos o por no utilizar el sistema porque le entorpece su trabajo. De esta manera, o la Orden de compra sigue una deriva en papeles externa al sistema computacional o los datos de la ficha del cliente quedan incompletos restando su potencial uso en otras instancias de la empresa. Este ejemplo es el caso típico en que no se tuvo en cuenta que la creación de una ficha de un cliente es un proceso, y que ese proceso se inicia al ingresar una Orden de compra telefónica, que recoge los datos mínimos para no perturbar la venta, y que deja pendiente tareas para que otra persona de la organización complete esta tarea en otro momento. La tecnología que se hace cargo de la completitud de los procesos en la informática se denomina Workflow. Es la opinión de muchos expertos que el rediseño de los procesos de una organización debe partir por ahí, por identificar los procesos relevantes y definir para ellos las funciones y datos necesarios. Una consecuencia de esto apunta a lo siguiente: ha sido la visión limitada de ver sólo datos y funciones la que ha llevado a la gente de computación a escribir muchos más programas de los realmente son utilizados en la explotación de los sistemas. Esto porque se mira los datos y se busca luego cuales son todas la funciones de consulta, mantención, ingreso y eliminación que cada una de las tablas requiere. De esta manera, la matriz resultante datos−funciones es siempre mayor que la que se obtiene al preguntarse: ¿cuáles son los usuarios que existirán y bajo qué cirscunstancias podrán consultar, poblar, eliminar o actualizar datos?. Dicho de otra manera los procesos no son los triviales: consulta, mantención, ingreso y eliminación, sino que están insertos en una empresa que tiene definidos procesos más grandes en los cuales los de la información son parte. En el ejemplo de la Orden de compra telefónica, dado antes, se construyó la aplicación que permitía poblar la tabla de clientes, sin embargo, al no estar declarada esa función dentro de ningún proceso de la empresa, ésta función no tiene usuario y resulta inútil. Otra consecuencia que también produce la miopía de no considerar los procesos, está ligada a la estructura 2 que se da a la organización y que tiene repercusiones en la informática. Desde la revolución industrial hasta ahora se ha estructurado la empresa en una suerte de departamentos especializados. De esta manera en la empresa se distingue un departamento de contabilidad, de tesorería, de ventas, etc. El alto costo de esta especialización y división ha significado a juicio de muchos especialistas, que algunas empresas dejen de ser competitivas en el mercado; y hoy día se está haciendo un enorme esfuerzo por reestructurar la empresa en torno a sus procesos de negocios. La interpretación ofrecida aquí, coloca a la informática en un muy buen pié para colaborar dentro de esta nueva dirección. Si se hacen las funciones computacionales iluminadas por la lógica de los procesos de negocio, se avanzará en la dirección correcta. Para ilustrar este punto supongase una empresa en que se hacen Notas de venta y éstas deben ser aprobadas por un supervisor. El análisis de sistema tradicional resuelve este punto proveyendo al supervisor de: a) una consulta en el sistema de Cuentas corrientes que le permite ver el estado del cliente como: cupo máximo de crédito, morosidad, etc. b) una consulta en el sistema de inventario que le permite revisar los márgenes de los productos involucrados en la Nota de venta los cuales cotejará contra las políticas de márgenes y comisiones asociados al cliente/vendedor. Además, puede existir otro conjunto de consultas de apoyo. Lo que es importante de mostrar aquí es que probablemente el usuario supervisor de ventas deberá viajar a través de un conjunto de menús y pantallas en una deriva loca por encontrar la información necesaria para aprobar dicha nota de venta. Lo hará una vez o dos y después de fatigarse en esta gimnasia es altamente probable que no vuelva a hacerlo. En esta añeja lógica de análisis de sistema se va detrás de la organización en sus diferentes departamentos, pero con la ceguera para ver que la empresa cuando actúa no lo hace así. De nuevo el análisis matricial entre datos y funciones arrojó las consultas necesarias, pero no existe un proceso en el cuál dichas consultas sean necesarias; mientras que la consulta integral que si es necesaria para este supervisor nunca se hizo. A continuación se va a revisar más en detalle el concepto proceso y lo que se quiere decir en la interpretación que se ofrece dentro de la metodología. El concepto proceso ha sufrido una variación en su interpretación en los últimos años. Hace 40 años atrás cuando un ingeniero hablaba de procesos se refería a las modificaciones que alteraban los materiales o elementos físicos en una empresa. Durante las últimas décadas ha ocurrido que cuando se habla de procesos se considera también, toda la operación que se hace con datos y archivos, ambos tópicos relacionados a la informática. Recientemente ha aparecido el tema de los procesos con una visión más global en la que se incluyen no sólo los conceptos anteriores, sino que se agregan elementos nuevos como son: comunicaciones, personas, teléfonos, etc. Hoy la idea de procesos se entiende mucho más por la forma en que toda la organización hace algo. Uno de los instrumentos básicos que la ingeniería utiliza es el modelamiento de procesos . Ha sido una práctica recurrente la utilización de mapas y/o planos que representan gráficamente estos modelos. Asi por ejemplo se pueden encontrar en la tradición ingenieril: Cartas Gantt y Pert para estudio de proyectos, Planos de construcción de obras civiles, Diagramas de procesos industriales, Diagramas de Flujos, Flujos de datos, etc. No siempre es de sentido común decir que un mapa es un instrumento de navegación, más usual es verlos como descriptores del mundo. Esto tiene que ver con la educación tradicional, que habla de la necesidad y capacidad que se tendría de describir el mundo real y deja de lado que el mapa es el mundo visto con una interpretación. Y que esta interpretación siempre tiene un propósito que se ajusta a una particular y única intención del observador que lo construye. Los mapas de la ingeniería también son instrumentos de navegación, son una interpretación del fenómeno que describen con una cierta intencionalidad. Ellos han conseguido una aceptación general y universal, tienen asociados elementos cuantificadores y tienen una capacidad de diseño y de predicción de aquello que representan. Hasta hace poco habían sido mapas útiles para navegar en el mundo de los negocios. 3 Ya no son útiles, porque como la interpretación que son, omiten al principal actor de los discursos de hoy día: las personas, y aunque éstas son tomadas en cuenta por otras ciencias como la sicología, la sociología, éstas no nos proveen de un mapa ingenieril, es decir medible, repetible. Los mapas tradicionales de la ingeniería no muestran cómo se producen las coordinaciones de las actividades en los procesos, o sea, las acciones y prácticas de las personas que realizan los procesos que se grafican. Los mapas actuales interpretan los procesos enfocándolos principalmente en los movimientos de papeles o datos, o en las transformaciones de materiales y su movimiento, pero ocultan el proceso global donde se insertan. Para mejor entender esta última observación se definirán tres tipos de procesos. Estos procesos son formas de interpretar las organizaciones y los negocios en general. Los dos primeros, los procesos materiales y los de información, han sido exitosos para entender situaciones estructuradas, pero hoy son ineficientes cuando se quiere considerar los aspectos humanos, como motivación, innovación, etc. a) Procesos materiales. Estos son el tema tradicional de la ingeniería y se refieren a aquel proceso en que la visión se centra en los materiales, en cómo éstos se transforman, se transportan, se construyen, se almacenan, etc. Observa las acciones físicas de los procesos. Muchas de las ingenierías se definen asumiendo los nombres de los procesos con que esas prácticas se identifican (ingeniería mecánica, eléctrica, industrial etc.). Hace unos 40 años atrás no existía (no se veían) otro tipo de procesos. b) Procesos de información. Son aquellos procesos que miran el traspaso, transformación, almacenamiento, comunicación, etc. de elementos de información. Estos procesos se han visto también como controles de los procesos materiales y utilizan una diagramación que les es propia: Diagramas de flujo, modelo de datos, diagrama de funciones, Flujo de datos, etc. c) Procesos de negocios. Lo central en este tipo de procesos es que se observan los negocios y las organizaciones como una red de compromisos y de coordinación de acciones entre la gente y que es al fin y al cabo, la que hace que los dos procesos anteriores ocurran. Los elementos de trabajo aquí son propios de los seres humanos, tales como: roles, compromisos, solicitudes, satisfacción del cliente. Esta interpretación nos permite observar y modelar cómo la coordinación y los compromisos se orientan hacia la satisfacción del cliente, cómo se innova, cuando se desmotivan los responsables de los diferentes roles. En suma entrega respuestas a las preguntas relevantes de hoy para los negocios. Es más, los procesos de negocios entregan la posibilidad ingenieril de rediseñar las organizaciones orientándolas hacia el cliente, además de ir aprendiendo de la propia práctica, dejando un espacio a los miembros de la organización para innovar. Procesos de negocios. 4 Los procesos de negocios o de coordinación también tienen una herramienta gráfica o mapa con el que trabajar. Para presentarla se mostrará la molécula básica de esta interpretación. (este esquema está tomado del trabajo de BDA y aparece en el libro de Peter Keen "Construyendo el futuro") Toda actividad donde participan dos personas puede ser representada por este diagrama o loop. Además, todo trabajo colaborativo puede ser descompuesto en actividades entre dos actores: el solicitante o cliente y el ejecutor o proveedor. De esta manera una red de trabajo organizada para un cierto proceso puede ser vista como un conjunto de estos `loops' interconectados. Gráficamente se puede ver como en la figura siguiente: 5