Principios de la construccin de modelos

1

INTRODUCCION
La planificacin del modelo es el primer paso para producir un modelo slido.
El paso siguiente consiste en asegurarse de que el contenido del plan se traduce en un modelo que
cumple las especificaciones. Esto se puede conseguir siguiendo algunas reglas sencillas. El propsito de
este artculo es sentar las bases de un sistema de este tipo. Centraremos nuestro estudio en las hojas de
clculo, que son especialmente relevantes en este caso por el hecho de que los modelos basados en hojas
de clculo son los que ms problemas plantean por falta de estructuracin.
Suelen presentarse una serie de problemas asociados a los modelos realizados en hojas de clculo:
elevado nmero de errores lgicos
larga duracin del trabajo de creacin del modelo
es frecuente que los modelos terminados sean difciles de utilizar para el no experto
suele ser difcil interpretar y seguir los modelos
es difcil actualizar los modelos en el futuro
Las dos soluciones adoptadas ms frecuentemente para estos problemas son la documentacin y la
validacin/prueba. Muchas personas estaran dispuestas a reconocer que es lgico documentar los
modelos, sobre todo los grandes, pues la documentacin ayudar a comprender su funcionamiento ms
adelante. No obstante, aunque se suele reconocer que es bueno preparar documentacin, los creadores
de modelos pueden ser remisos a desarrollar y a mantener documentacin adecuada. La documentacin
de los modelos se considera, caractersticamente, una labor que se ha de realizar despus de la creacin
misma del modelo; y ni siquiera se considera que sea una labor muy ardua. Por lo tanto, aunque no deja
de ser importante documentar los modelos, es lgico construirlos de tal manera que se reduzcan al
mnimo los problemas derivados de la mala calidad de la documentacin, o de su inexistencia.

1
Adaptado de: Hogg Neil, Decisiones Empresariales Basadas en Modelos Financieros, Ediciones Folio, Barcelona, Coleccin Biblioteca de
Empresa, Financial Times, primera edicin !!", Cap#t$lo %&
La segunda solucin, la de la validacin/pruebas posteriores a la elaboracin del modelo, es tambin
una disciplina til. Pero las validaciones y pruebas son procesos largos, que, en el mejor de los casos,
slo pueden comprobar de manera incompleta la capacidad del modelo para funcionar bajo todo tipo de
condiciones.
La afirmacin de que la documentacin y la validacin del modelo son una solucin aceptable para
garantizar la calidad del mismo es una solucin demasiado superficial para los problemas principales
con que se encuentran los modelos realizados en hojas de clculo. Los problemas fundamentales son
ms profundos; se relacionan con el modo en que se construyen los modelos en las hojas de clculo. En
este artculo sentaremos una serie de principios que tendern a hacer ms fiables y comprensibles los
modelos realizados en hojas de clculo. Estudiaremos, a continuacin, el modo en que se pueden
aprovechar algunas de las funciones de los paquetes modemos de hojas de clculo para crear modelos
mejor presentados y ms manejables.
CUATRO PRINCIPIOS
La estructuracin adecuada de un modelo no tiene ningn misterio. Existen cuatro reglas bsicas
que, si se siguen, conducen a la creacin de modelos precisos, eficientes y legibles:
Construir el modelo por mdulos.
Separar por completo los datos y la lgica.
Al disear las formulas, vale ms ser claros que ingeniosos.
Procurar, siempre que sea posible, que el modelo este autodocumentado.
Ampliamos a continuacin cada uno de estos puntos.
La modularidad
EI principio de modularidad implica que cada parte discreta del modelo, como las que se ocupan de
los costos o de las ventas, este diseada de tal manera que cualquier alteracin de la lgica o de los
datos dentro de un mdulo determinado no tenga ningn efecto sobre ningn otro mdulo. Esto quiere
decir, idealmente, que cada mdulo debe escribirse como una caja negra, es decir, que acepte
entradas de datos desde un lugar definido y realice salidas hacia otro lugar definido, mientras que lo que
sucede entre la entrada y la salida de esos datos no tenga ninguna repercusin sobre el resto del modelo.
Este principio, bien establecido en la programacin de ordenadores, producir mejores modelos por
los motivos siguientes:
Reduce las posibilidades de error, reduciendo al mnimo el nmero de interrelaciones dentro del
modelo.
Permite probar ms fcilmente los modelos, pues se puede poner a prueba la lgica general del
modelo antes de introducir el grueso de los clculos; despus, los clculos detallados se pueden poner
a prueba en bloques de tamao manejable.
Permite introducir cambios con ms seguridad; por ejemplo, si decidimos modificar el mtodo de
clculo de las ventas, no debemos preocuparnos de que el balance deje repentinamente de cuadrar.
Los modelos financieros cambian con frecuencia. Es difcil, por lo tanto, reconciliar esta necesidad de
flexibilidad con el rigor necesario para definir con exactitud los enlaces entre los mdulos de tal modo
que se pueda aplicar en la prctica el principio de la caja negra. Consideremos, por ejemplo, el caso de
un clculo tpico de ventas. Los mdulos de datos pueden contener informacin sobre el tamao del
mercado y su tasa de crecimiento esperada, as como informacin sobre la cuota de mercado de la
empresa. Toda esta informacin puede estar ms desglosada, por productos y zonas de venta por
ejemplo. Si se establecieran enlaces entre estos datos y la lgica del modelo para calcular las ventas pero
se decidiera introducir un nuevo producto, entonces, si se est utilizando una hoja de clculo
convencional, podra ser necesario redisear en buena parte la estructura lgica a para acomodar el
nuevo producto. As, aunque el principio de la caja negra es el ideal, no siempre se puede conseguir
aplicarlo por completo utilizando hojas de clculo. El modo prctico en que podemos aproximarnos a un
modelo de caja negra en una hoja de clculos es avanzar a base de pasos lgicos cortos en cada modulo,
y hacer un uso frecuente de los sumarios. Para ilustrar este principio, consideremos el ejemplo del
clculo de ventas que acabamos de citar. Existen diversas maneras de abordar este problema. Una
manera es utilizar una frmula para calcular las ventas de la empresa multiplicando la dimensin total
del mercado por la tasa de crecimiento del mercado, por la cuota de mercado de la empresa, por la tasa
de crecimiento de esta cuota de mercado y por el precio unitario del producto dentro de cada zona de
ventas. Otro planteamiento consiste en utilizar ms mdulos, dar pasos lgicos ms cortos dentro de
cada mdulo y producir una serie de resultados intermedios, tales como la dimensin total del mercado,
la cuota de mercado de la empresa (en unidades vendidas), y despus calcular las ventas de la empresa
en trminos monetarios. Los pasos que se daran en este segundo planteamiento sern algo as:




Md$lo 'rigen de datos Destino de datos
Datos de mercado Fuente primaria
Dimensin de mercado y predicciones de
crecimiento
Datos de cuota de mercado y precios de la
empresa
Fuente primaria
Cuota de mercado y mdulos de precio de la
empresa
Dimensin del mercado Datos de mercado Ventas
Cuota de mercado de la empresa
(unidades)
Datos de mercado de la empresa
(unidades)
Ventas
Prediccin de precios
Datos de mercado de la empresa
(unidades)
Flujos de caja, cuenta de prdidas y ganancias
Ventas
Modelos de dimensin del mercado, cuota
de mercados y precios
Flujos de caja, cuenta de prdidas y ganancias
Flujos de caja Ventas Ninguno
Cuenta de Prdidas y ganancias Ventas Nnguno
Utilizando este planteamiento, el clculo de, por ejemplo, la cuota de mercado es una cuestin ajena al
mdulo de ventas que recibe esta informacin. El modelo se puede construir en un primer momento sin
ninguna operacin lgica en el mdulo de clculo de la cuota de mercado, que slo contendr una cifra
estimada. Si todos estos pasos se hubieran condensado en un solo mdulo, se habra creado un modelo
con:
Frmulas complicadas, ms difciles de comprender.
Mayores probabilidades de error. Esto se deber, en parte, a que las frmulas sern ms complicadas,
pero tambin a que los resultados intermedios, tales como la dimensin total del mercado (es decir, la
dimensin actual del mercado multiplicada por la tasa de crecimiento) no se pueden observar para
comprobar que se trate de valores razonables.
La multiplicidad de pginas que ofrecen las hojas de clculo brinda una oportunidad ideal para
mantener separados los mdulos. En el caso de los mdulos menores, que quizs no justifiquen el empleo
de una pgina independiente, sigue siendo posible mantenerlos separados en gran medida colocndolos
uno sobre otro. El motivo por el que no se deben colocar uno al lado de otro es que las columnas re-
presentan, caractersticamente, el tiempo, y, por lo tanto, son homogneas y es menos probable que sean
borradas que las filas. Esto quiere decir que la probabilidad de que los cambios introducidos en un mdulo
afecten a otros mdulos es inferior si se practica una ordenacin en vertical.

Es preciso tener en cuenta dos reglas ms al construir mdulos:
Siempre que sea posible, deben reservarse las columnas para representar el tiempo; por ejemplo, la
columna D sera el ao X, y as sucesivamente. As resulta ms fcil copiar frmulas y, por lo tanto, se
reduce el tiempo de creacin del modelo.
Del mismo modo, todos los mdulos que sirven datos a otro mdulo deben tener un mismo formato,
pues tambin as se facilita mucho la copia y la construccin de frmulas.
Separacin de los datos y de la lgica
La modularidad supone una separacin bsica entre los datos y la lgica. Pero existe, no obstante, la
tentacin de introducir directamente factores de ltima hora. Por ejemplo, si se predice que los costos de
personal van a aumentar un 5% al ao, la frmula ser: costos de personal
t
= costos de personal
t-1
x 1,05.
Pero si, como suele suceder, se conoce con mayor certidumbre la cifra del ao siguiente, entonces suele
parecer mas fcil ajustar la tasa de crecimiento del 5% para ese ao, o sustituir la frmula por una cifra.
Cualquiera de estos ajustes sera un arreglo rpido, pero tambin es probable que la persona que ha
realizado el arreglo lo olvide, y que otra persona que toma el modelo por primera vez no lo detecte. Las
hojas de clculo facilitan estos arreglos, pero su empleo socava la solidez fundamental de los modelos.
La regla fundamental, que deber seguirse sin excepcin, es la de no mezclar datos con relaciones lgicas
en una misma frmula. Los ejemplos siguientes ilustran lo que es aceptable y lo que no lo es.
Contenidos de celdas (Aceptable) Moti*o
!"#1 $% $lo &ormula, sin datos
!"#1!'( No
$e me)cla &ormula con
datos
*$("+*",,-$%-,-No-) $%
Frmula m.s te/to es
acepta0le
*$("+*",,'(,#() No
$e me)cla &rmula con
datos
*$("+*1,-$%-,-No-) Pro0a0lemente
"cepta0le si el 112 no
3ariara y su signi&icado es
e3idente
'4((( $% $lo datos
"cti3os &ijos $% $lo te/to
*!-"cti3os &ijos (-56'5-)- $% 7e/to m.s &rmula
Si queremos tener aunque sea la menor esperanza de construir modelos slidos utilizando hojas de
clculo, deberemos seguir rigurosamente estos principios. Toda desviacin se puede olvidar fcilmente y
puede hacer que se adopten decisiones incorrectas como consecuencia del modelo. La adhesin a este
estilo de trabajo aporta a la hoja de clculo una certidumbre que le faltara de otra manera. Tambin
impone una disciplina que asegura que los arreglos ad hoc no se introducen para olvidarlos ms tarde,
sino que se exponen claramente.
Nuestro estudio se ha centrado, hasta el momento, en la necesidad de mantener separados los datos y
las relaciones lgicas dentro de una misma celda. Esta separacin deber subrayarse ms aun
manteniendo los datos y las relaciones lgicas en mdulos separados. La distincin tambin deber
ampliarse, preferiblemente, al diseo de modelos en los que los datos se puedan salvar con independencia
de los mdulos lgicos. Esto permitir cargar con mayor facilidad escenarios diferentes en el modelo, con
la seguridad de que no se estarn introduciendo cambios imprevistos en la lgica del mismo.
El diseo intuitivo del modelo
El propsito principal de la separacin de los datos y la lgica es dejar claro lo que se puede esperar en
un modelo. Los modelos intuitivos son aquellos en que no slo queda claro lo que se puede esperar, sino
aquellos en los que, adems, esas expectativas parecen razonables y lgicas a la mayora de las personas.
Como en el caso de la separacin entre los datos y la lgica, el diseo intuitivo tiene dos aspectos:
Creacin de frmulas intuitivas
Distribucin y flujo intuitivo del modelo
No siempre es fcil crear frmulas intuitivas: suele existir la tentacin de producir frmulas
geniales, como la siguiente:
=SI(SI(B2=MAX(B1,B45,B78),BUSCARV(.
Es posible que estas frmulas sean grandes logros del pensamiento intelectual, pero resulta muy difcil
comprenderlas. Las frmulas intuitivas:
son cortas
no hacen uso de funciones complicadas, a no ser que estas resulten absolutamente esenciales, o que
mejoren la claridad
estn etiquetadas claramente y/o documentadas especficamente
en ellas se evitan los anidamientos (del tipo de =SI(SI( ( ... )
se evitan tambin, siempre que sea posible, los operadores lgicos (AND, NOT, OR; sobre todo, NOT).
utilizan nombres de rangos, no referencias de celdas, siempre que sea posible
no se refieren a celdas muy distanciadas entre s
En un modelo de distribucin intuitiva:
Las frmulas son consistentes a lo largo de toda una lnea. Por ejemplo, si los costos de personal para el
ao l equivalen a +B42, entonces se podra esperar que fueran +C42 para el ao 2, +D42 para el ao 3,
y as sucesivamente. Es demasiado frecuente encontrarse con un modelo en que el ao l es +C42, el
ao 2 es +D101, el ao 3 es +A5. Si se introduce una modificacin en la lnea, lo natural es modificar
un ao y copiar a continuacin su frmula sobre los aos siguientes; pero, si las frmulas no son
consistentes, est claro que pueden producirse errores.
El flujo lgico que transcurre de la parte superior de la hoja hasta la inferior, y de la hoja/fichero A la
B, y as sucesivamente.
Todas las columnas se refieren a una misma variable, preferiblemente al tiempo.
Se pueden establecer claramente los niveles de los clculos. Por ejemplo:
sub-resultado 1
sub-resultado 2
RESULTADO A
La autodocumentacin
Los modelos se pueden hacer ms comprensibles incluyendo en ellos textos y comentarios
descriptivos. Los motivos para crear modelos autodocumentados son dobles. En primer lugar, es mucho
ms fcil incluir algunas notas mientras se va construyendo un modelo que sentarse ms tarde a escribir
una documentacin larga y aburrida. En segundo lugar, es ms fcil comprender un modelo que contiene
documentacin en la propia hoja de clculo. Por lo tanto, la regla ms segura probablemente sea la de
suponer que el modelo no se documentar por entero cuando est completo, e introducir en el, por lo
tanto, etiquetas auto documentadoras.
La auto documentacin no es ni difcil ni costosa (ni lo son tampoco los dems aspectos de la
construccin de un modelo estructurado), y pronto se llega a introducir de una manera instintiva. La
documentacin se puede aadir a los modelos de tres maneras principales:
Incluyendo una seccin descriptiva (normalizada) en la parte superior de cada mdulo, en la que se
lista el contenido del mdulo y su propsito, de dnde proceden los datos de entrada y a dnde se
dirigen los de salida; si el mdulo es complicado, se le puede aadir otro recuadro con comentarios en
formato libre.
Haciendo ms descriptivas las etiquetas de las celdas. Por ejemplo, en vez de Costos de personal, la
etiqueta podra decir: Costos de personal: sueldo base, incl. seguridad social y pensiones.
Asignar notas o comentarios a una celda determinada; en estas pueden introducirse descripciones ms
detalladas.