Está en la página 1de 14

Modelado de la

Solución
Para entrar en Contexto

La semana pasada diseñamos nuestros requisitos de mayor


nivel, los cuales se enfocaban primordialmente a los objetivos a los
cuales debería apuntar nuestra solución, para lograr que estén
alineados a los procesos fundamentales.

¿Qué sigue ahora?, muchos pensaran “especificar los requisitos


funcionales y no funcionales derivados de cada uno de los procesos
fundamentales”. Pues bien, esto aunque a simple vista no lo parezca,
no es en sí una buena práctica. ¿Por qué?, la respuesta es sencilla y
se responde con otra pregunta: ¿cómo está concebida nuestra
solución?, si no se tiene clara la concepción de la misma, entonces
simplemente lo que se hará es una enorme lista de requisitos
funcionales (luego los no funcionales) que pueden que se nos vayan
ocurriendo a la medida que escribimos.

De lo anterior, creo que queda justificado entonces afirmar que


no es la mejor manera de hacer las cosas, ¿o me equivoco?. Dicho
esto, lo lógico es concebir nuestra solución y para ello vamos a hacer
uso del Concepto de Cadena de Valor.

Concibiendo la Solución

Dentro de la gestión de procesos exsiten aspectos tales como:


Cadena de Valor, Procesos Fundamentales, Procesos de Apoyo y
Mapa de Procesos; ahora bien, les pregunto ¿por qué no podemos
aplicar dichos conocimientos para la concepción de la solución?.
Algunos pensarán “la verdad no se me había ocurrido”, pues bien, eso
es precisamente lo que vamos a hacer ahora: concebir nuestra
solución, partiendo de nuestra cadena de valor y luego el mapa de
proceso para cada uno de los fundamentales.

Cadena de Valor de la Solución

En la Cadena de Valor se muestran los procesos fundamentales


y los procesos de apoyo de una organización o gestión. En este
sentido, lo que vamos a hacer acá es lo mismo: mostrar los procesos
fundamentales y los de apoyo, pero ya no de la gestión sino de
nuestra solución informática.

Gran parte de los procesos fundamentales de la solución


informática no debería representar problema alguno para nosotros, ya
que ¡correponden al modelado de objetivos!, lo cual es obvio,
puesto que está siendo concebida precisamente para ello: apoyar a
los procesos de negocios, entonces nuestra cadena de valor de la
solución en un primer momento queda así

Lo siguiente que vamos a hacer es identificar procesos de


apoyo, los cuales no tienen que ver con los de la gestión (al menos no
en su mayoría). Para determinar estos recordemos la definición: “dar
soporte a los procesos de fundamentales”. Quizás pensemos “quedé
en la misma, sigo sin verlo”, bien, pregunto lo siguiente ahora ¿nuestra
aplicación tiene tablas básicas?, obviamente que sí, muchas, ahora
pregunto ¿en qué proceso fundamental se deben llenar?, algunos
expondrán “depende, se llenan de acuerdo al proceso que lo
necesiten”, bien, pregunto ahora ¿y si la usa más de uno?. La cosa se
complica, al menos en apariencia.

En este sentido, resulta obvio tener un proceso (o un módulo) de


registros de tablas básicas), pues, dicho módulo es precisamente un
proceso (o gestión) de apoyo. En otro orden de ideas, toda aplicación
informática que se precie debe tener un módulo de configuración, que
permita, tal como su nombre lo indica configurar y/o parametrizar la
aplicación de acuerdo a las necesidades que se vayan suscitando
sobre la marcha, De allí que entonces tengamos otro proceso de
apoyo: Configuración de la Aplicación(es).

Asimismo, considero que no hace falta ahondar mucho en acotar


que debe existir un módulo que maneje la seguridad funcional de la
solución. En este sentido, debe existir un módulo que permita la
creación de usuarios, la creación de roles y la asignación de la
permisología de acceso a las distintas funcionalidades de la aplicación
de acurdo al rol que se tenga. Lo pensaron bien: ¡éste también es un
módulo de apoyo!.

Con la explicación de los párrafos anteriores se les hace más


fácil deducir otros módulos de apoyo, quizás ya lo estén pensando:
Utilidades de Base de Datos (respaldo, recuperación, depurar, manejo
de históricos, entre otros).
Acá ustedes lo que deben hacer entonces es personalizarla de
acuerdo lógicamente a sus procesos fundamentales, y de igual
manera, a aquellos procesos de apoyo de la gestión que incluyan en la
solución.

Recordemos el ejemplo de la semana pasada: nuestra aplicación


de gestión de logística. En ella, se definió un proceso de apoyo de
inspección de calidad que agregaría un valor agregado. En este
sentido, la cadena de valor de dicha solución sería
Llegado a este punto ya estaremos pensando en los requisitos.
No desesperar, falta algo más, vamos a ello. No es un secreto que
hoy en día la solución puede estar constituida por más de una
aplicación. Por ejemplo, se puede tener una Aplicación tipo Portal
Web en donde los clientes realicen sus pedidos en línea, los cuales
son vistos y atendidos por el personal de la empresa a través de una
aplicación interna. Por otro lado, puede existir una aplicación móvil
para los despachadores quienes acceden a través de ella, a la
información necesaria para repartir aquellos pedidos hechos por los
clientes. Del mismo modo, dichos despachadores pueden introducir
registros necesarios para el rastreo de entrega, los cuales, pueden ser
consultados por los clientes en el portal web a través del número de la
factura (o guía).

Dicho esto, resulta claro que nos hace falta algo más, en otras
palabras, determinar el número de aplicaciones que va a tener nuestra
solución y la tecnología a emplear. Gráficamente es algo como lo que
sigue:

En nuestro ejemplo, diremos que nuestra aplicación de logística


se compone de un componente web desktop y uno móvil, en
consecuencia, sería algo como

De allí, lo siguiente a realizar es el mapa de procesos para cada


proceso fundamental de nuestra solución, así que vamos paso a paso.

Recordando, sabemos que el mapa de procesos tiene un


responsable, un objetivo, unos actores, en quien se apoya, entradas,
salidas y subprocesos. Comencemos por el objetivo. ¡A definir otro
objetivo nuevamente!, les tengo una grata noticia: ¡no!. Uno de los
objetivos específicos del modelado de objetivos de la solución es
precisamente el de uno de los procesos fundamentales. Vamos más
allá, si lo establecimos en el orden correcto entonces.

En nuestro ejemplo particular sería así (para el de logística


interna, como ejercicio repita estos pasos para el de logística externa)

Con respecto a las entradas y salidas, Tomamos como base lo


que establecimos en el Mapa de Procesos del fundamental que
corresponda. De allí se toman las que se requieren en nuestra
solución (entradas), y, especificar si se requieren adicionales. Del
mismo modo para las salidas, tomar las que suministrará la aplicación
y de ser necesario, especificar adicionales. Gráficamente.

Con respecto a los subprocesos se repite lo descrito


anteriormente. Se toman aquellos que van a ser parte de las
funcionalidades de la aplicación, y, de ser necesario, se diseñan
adicionales. Gráficamente.
Con respecto a los reglamentos, pues, necesariamente tienen
que ser los mismos. Independientemente que el proceso se ejecute
de la manera como se viene desarrollando o mediante la solución,
éste no cambia, a menos, claro está, que se diseñe una
reglamentación adicional para el uso de la solución, por ejemplo,
cuestiones propias de la seguridad de la información, la cual se
especifican en Sistemas de Gestión de Seguridad (SGS) los cuales no
escapan del alcance de este diplomado.

Con respecto al apoyo. Acá vamos a hacer uso de esta figura


que diseñamos previamente, la cual se las muestro nuevamente para
que no tengan que volver hacia arriba,

¿Cuáles de dichas Apps (1, 2 .. n) contendrán dentro de su


funcionalidad el proceso fundamental nro 1?. Puede ser más de una,
las cuales dependen de los subprocesos. Llegado a este punto,
podríamos decir por ejemplo que la App 1 contendrá dentro de sus
funcionalidades parte de los subprocesos; el resto de ellos estarán
contemplados por ejemplo en la App 2. Gráficamente nuestro Mapa
de Procesos sería:
Lo que resta ahora es determinar quién o quienes ejecutan el
proceso. Acá simplemente lo que vamos a definir son los stackholders
(los distintos actores que usaran la aplicación). Una vez hecho esto ya
tenemos entonces definido por completo nuestro Mapa de Procesos
para el proceso fundamental Nro. 1. Bajo estas consideraciones,
debemos repetir lo descrito para los procesos subsiguientes. La
gráfica siguiente muestra el Mapa completo.
Retomando nuestro ejemplo, el proceso de logística interna
sería:
Tal como vemos la logística interna se compone de dos (2)
subprocesos: la recepción de insumos y el despacho de insumos.
Como entrada se requiere la factura de proveedor (útil para la
recepción de insumos) la cual provee la información de lo que entra al
inventario de materia prima. Una orden de consumo la cual es la
entrada que justifica que se debe despachar materia prima a
producción. Como salidas se tiene una orden de despacho, la cual es
el soporte de la salida de materiales de inventario, un informe de
pedido (para reponer el inventario) y por ser una aplicación
informática, obviamente, actualizar la base de datos.

Quizás existan dos (2) entradas que no estén muy claras: el


informe de devolución y el de inspección. El informe de devolución se
puede deber a la no utilización de materiales para la producción, por lo
que regresan dichos insumos al inventario. El informe de inspección
viene dado por el proceso de apoyo que definimos en nuestra
solución. ¿Qué ocurre cuando se daña una materia prima?, pues,
debe ser removida del inventario, para ello es necesario un soporte
que justifique dicha salida, de allí se hace uso del soporte de
inspección el cual da como resultado el informe necesario para dicha
labor.

Completados los Mapas, disponemos entonces la


fundamentación para la especificación de los requisitos base para la
solución informática. En este sentido, como ejercicio, elabore el Mapa
de Procesos para la logística externa.
De la discusión anterior, se desprende la actividad de esta
semana, la cual se detalla a continuación

Tomando como referencia el Modelado de Objetivos realizado en


la Semana #2, elaborarán el Modelado de la Solución Informática
siguiendo la metodología aplicada en el recurso, para ello, harán la
concepción de la solución en donde se describan los componentes, la
cadena de valor de la solución y el mapa de los procesos
fundamentales de la solución.

Para ello, abrirán su propio espacio de discusión, adjuntan su


archivo en el foro correspondiente en la plataforma, la fecha de
entrega se indicará en la misma. De igual manera, en caso de
cualquier duda estamos a la completa disposición.