Procesos de negocios

Anuncio
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
Descargar