Libro Sistemas Automatizados de Contabilidad

SISTEMAS AUTOMATIZADOS
DE CONTABILIDAD
Dr. Jorge Barrera Ortega

…….
…….
Diciembre 2012
CONTENIDO
1 Introducción ................................................................................................................................ 3
2 El ciclo contable manual.............................................................................................................. 5
2.1 Contenido del ciclo contable ............................................................................................... 5
2.2 La recepción del documento primario ................................................................................ 6
2.3 La definición de las cuentas a afectar ................................................................................. 7
2.4 El registro en el libro diario ................................................................................................. 8
2.5 El archivo del documento primario ..................................................................................... 9
2.6 La gestión de activos y pasivos pendientes ....................................................................... 10
2.7 El registro de los asientos en los libros mayores .............................................................. 11
2.8 La conciliación de los estados de cuenta .......................................................................... 11
2.9 El balance de comprobación ............................................................................................. 12
2.10 La depuración de errores .................................................................................................. 13
2.11 La emisión de los estados financieros ............................................................................... 13
3 Niveles de automatización de los SAC ...................................................................................... 15
3.1 Producir un diario en soporte electrónico ........................................................................ 15
3.2 Transaccional..................................................................................................................... 16
3.3 Recepción de documentos primarios en soportes electrónicos ....................................... 17
3.4 Integración del SAC en un ERP .......................................................................................... 18
3.5 Interacción con otros sistemas automatizados................................................................. 19
4 Principales hitos en el desarrollo de los ERP o SAC................................................................... 23
4.1 Surgimiento de la contabilidad actual............................................................................... 23
4.2 Los equipos de tarjetas perforadas ................................................................................... 24
4.3 Las computadoras ............................................................................................................. 25
4.4 Las redes de terminales..................................................................................................... 27
4.5 Las minicomputadoras, las bases de datos y UNIX ........................................................... 28
4.6 Las PC, las fibras ópticas, Internet y los celulares ............................................................. 29
4.7 El futuro inmediato ........................................................................................................... 32
5 Componentes de los ERP o SAC ................................................................................................ 35
5.1 Los componentes .............................................................................................................. 35
5.2 Las computadoras ............................................................................................................. 36
5.3 Las telecomunicaciones .................................................................................................... 38
1
5.4 La información................................................................................................................... 43
5.5 Los programas informáticos .............................................................................................. 51
5.6 Los recursos humanos ....................................................................................................... 55
5.7 Los aspectos metodológicos ............................................................................................. 56
5.8 Los aspectos legales .......................................................................................................... 57
5.9 La organización .................................................................................................................. 58
5.10 La seguridad y protección ................................................................................................. 59
6 Clasificación y tipos de ERP o SAC ............................................................................................. 65
6.1 Características Funcionales ............................................................................................... 65
6.2 Características del software utilizado para el ERP o SAC .................................................. 69
7 Principales características de los ERP ........................................................................................ 73
7.1 Principales módulos .......................................................................................................... 73
7.2 Integración ........................................................................................................................ 74
7.3 Otras características .......................................................................................................... 75
7.4 La selección e implantación de un ERP, los riesgos .......................................................... 77
8 Principales ERP o SAC en uso .................................................................................................... 81
8.1 SABIC ................................................................................................................................. 81
8.1.1 Aspectos históricos y principales características del SABIC ...................................... 81
8.1.2 Principales servicios que brinda el SABIC .................................................................. 87
8.1.3 Principales elementos arquitectónicos del SABIC ..................................................... 91
8.1.4 Base de clientes ......................................................................................................... 95
8.1.5 Tecnologías utilizadas................................................................................................ 95
8.1.6 Requerimientos ......................................................................................................... 96
Bibliografía ........................................................................................................................................ 97
2
1 Introducción
A principios del 2011 fue necesario revisar y modificar, con cierta urgencia, el contenido de la
asignatura Sistemas Automatizados de Contabilidad (SAC), que se imparte en el segundo semestre
del cuarto año de la carrera de Contabilidad y Finanzas, de la facultad con igual nombre, de la
Universidad de la Habana.
El principal cambio en el contenido del curso consistió en revisar el tema desde la perspectiva de
los sistemas de planificación de recursos empresariales (ERP por su nombre en inglés), ya que los
mismos han absorbidos los anteriores SAC, en un proceso similar a lo sucedido con los transistores
y diodos que se incorporaron a los circuitos integrados o microprocesadores. De elementos per se,
han pasado a ser meros componentes.
Las notas para el ciclo de conferencias que se impartieron con el nuevo perfil de la asignatura,
dieron pie a la confección del presente libro, cuya primera versión estará disponible, al menos por
medios electrónicos, para el curso del 2012 – 2013.
Este libro consta, además de esta introducción, de los siguientes capítulos:
 El ciclo contable manual
 Niveles de automatización de los SAC
 Principales hitos en el desarrollo de los ERP o SAC
 Componentes de los ERP o SAC
 Clasificación y tipos de ERP o SAC
 Principales características de los ERP
 Descripción de ERPs o SACs en uso
El capítulo del ciclo contable manual describe los principales procesos, que tradicionalmente
forman parte de ese ciclo, y presenta un diagrama de bloques con el ciclo en su conjunto y
esquemas de cada proceso cuando se entiende conveniente.
Los niveles de automatización de los SAC se describen en el segundo capítulo, en un orden
cronológico, a partir de que se fueron creando las condiciones requeridas.
En los principales hitos en el desarrollo de los ERP o SAC se comentan los principales cambios
tecnológicos, y los personajes que estuvieron involucrados en los mismos, comenzando por los
inicios de la contabilidad, y recorriendo los últimos 60 año, etapa sin precedentes en el desarrollo
de los medios técnicos, las comunicaciones y, naturalmente, el software.
El capítulo de componentes de los ERP o SAC contiene una explicación sobre los aspectos a
considerar sobre cada uno de ellos (los recursos humanos, las computadoras, las
telecomunicaciones, los programas informáticos, la información, los aspectos metodológicos,
organizativos y legales, y la seguridad y protección), incluyendo, cuando procede, el estado del
arte, y sus principales interrelaciones.
La clasificación y tipos de ERP o SAC se describen principalmente los aspectos a tener en cuenta a
la hora de seleccionar uno de estos sistemas.
3
Las principales características de los ERP describen los objetivos de estos sistemas, las tecnologías
que emplean, los pasos que deben cubrirse para introducir uno de ellos y los principales retos a
manejar durante ese proceso.
Por último la Descripción de ERPs o SACs en uso, presenta una síntesis sobre el Open ERP, el
Versat, el Sabic, el Siscom, el Cedrux y el SAP.
Los capítulos II al VII fueron escritos por Jorge Barrera. La síntesis sobre los diferentes sistemas
fueron escritas por:
 OpenERP,
 Versat,
 SABIC, Jorge Barrera
 Siscom,
 Cedrux,
 SAP,
Teniendo en cuenta la velocidad actual de los cambios tecnológicos en las disciplinas que tienen
que ver con el tema de este libro, los autores consideran que el mismo deberá ser revisado y
actualizado el menos cada tres años.
4
2 El ciclo contable manual
2.1 Contenido del ciclo contable

El registro contable de una actividad cualquiera se lleva a cabo a través de la ejecución de un
grupo de procesos de forma iterativa.
Los principales procesos que conforman el ciclo contable son:
 Recepción del documento primario

 Definición de las cuentas a afectar
 Registro de los asientos contables en el libro diario
 Archivo del documento primario
 Gestión de los activos y pasivos pendientes
 Registro en los libros mayores de los asientos contables
 Conciliación de los estados de cuenta
 Emisión del balance de comprobación
 Depuración de errores
 Emisión de los estados financieros
Los primeros cuatro procesos se realizan en el momento que lo demande la llegada del
documento primario, según las exigencias de las normas contables en general y de la institución
en particular.
Las pequeñas empresas con pocos movimientos contables pueden permitirse acumular
documentos de varios días, antes de registrarlos en el libro diario. Otras entidades, como los
bancos, al tener que tomar decisiones operativas de su gestión a partir de los saldos contables, se
ven obligadas a registrar de forma inmediata, al menos algunos tipos de documentos primarios.
Una buena práctica, aceptada de forma universal, es registrar en el libro diario todos los
documentos primarios durante el mismo día que se reciben en la unidad organizativa encargada
de la contabilidad.
Los restantes procesos se realizan cada ciertos períodos, que van desde un día hasta un mes, en
dependencia también de las normas contables vigentes y de las exigencias de la institución.
La conciliación de los estados de cuenta y la emisión del Balance de Comprobación permiten la
detección de ciertos errores en el registro del diario y de los mayores. Cuando esto ocurre, es
necesario depurarlos.
El cuadro 1 muestra esquemáticamente la realización del ciclo contable.
Los procesos expuestos como parte del ciclo contable son los propios de la contabilidad clásica, en
la que una unidad de contabilidad recibe los documentos generados en las restantes áreas de la
entidad con el fin de realizar el registro contable. Como se explicará más adelante, la
introducción del procesamiento electrónico de datos ha modificado sustancialmente este ciclo, al
extremo de que algunos procesos han desaparecido.
5
REGISTRO
DOCUMENTOS Recepción documento primario DE
REGIS
ENTRADA
PRIMARIOS
Definición de cuentas a afectar
DIARO
REGIS
Registro en el diario Gestión de carteras
Archivo de documento CARTERAS
DOCUMENTOS
PRIMARIOS
NO
FIN PERIODO
SI
Depuración de errores Registro en mayor MAYOR

REGIS
Conciliación de estados de cuenta

SI
ERRORES
BALANCE
Emisión balance de comprobación DE
REGIS
COMPROBACION
SI
ERRORES
BALANCE
ESTADO
REGIS DE
Emisión de estados financieros RESULTADOS
Cuadro 1
2.2 La recepción del documento primario

La recepción del documento primario (ver cuadro 2) es un proceso que en muchos casos se
menosprecia. Cuando esto ocurre, muchos de los errores en los registros contables se deben a un
procedimiento inadecuado o incompleto para la recepción de esos documentos. En una oficina, el
extravío de un documento, ya sea porque fue a parar a un sitio al que no corresponde (“se
traspapeló”), o porque incluso se destruyó o botó, es, desafortunadamente, un hecho bastante
frecuente.
Recepción de documento primario
Almacenes
Contabilidad
Producción
DOCUMENTO PRIMARIO REGISTRO DE ENTRADA
Ventas
Recursos Humanos
Cuadro 2
6
La existencia de un registro de entrada de los documentos primarios recibidos, en el que se le dé
un número único a cada documento, se anoten sus fechas de confección y recepción, la persona
que lo entregó y la que lo recibió, así como los principales datos del documento que faciliten su
localización y el posterior tratamiento que se le vaya dando al mismo, es prácticamente
obligatoria.
El archivo temporal de los documentos a procesar es también de gran importancia. Hay quienes
afirman que los documentos que deben ser procesados no se deben guardar nunca en gavetas,
que siempre deben estar a la vista, lo cual puede ser una buena medida para volúmenes pequeños
y medios.
En todos los casos alguien debe ser responsable de, al menos una vez al día, revisar los
documentos pendientes contra el registro de entrada y explicar, si corresponde, porque aún no se
han procesado.
2.3 La definición de las cuentas a afectar

La definición de las cuentas a afectar (ver cuadro 3) para el registro de un documento es una tarea
que debe realizarse por el personal de mayor calificación contable. Esta definición se realiza a
partir del tipo de documento, el plan contable vigente y los procedimientos generales
establecidos, y debe quedar debidamente documentada.
Definición de cuentas a afectar
DOCUMENTO PRIMARIO
Maqueta de Transacción
Escaque x -> Cuenta 1 / Signo

Escaque y -> Cuenta 2 / Signo
Escaque z -> Cuenta 3 / Signo
Plan de cuentas
.
.
Escaque w -> Cuenta n / Signo
Procedimientos
Cuadro 3
Los tipos de documentos que se reciben para su contabilización son por lo general uniformes,
aunque no siempre iguales. Así, por ejemplo, una factura comercial debe contener todos los datos
que se requieren para su registro en el diario, pero no siempre con el mismo formato ni con el
mismo detalle.
El plan contable de una entidad, o clasificador de cuentas, debe partir de lo orientado por las
autoridades del país, pero puede ser más detallado con el fin de cubrir requerimientos internos.
En los casos en que el plan contable requiera ser más detallado que el establecido por las
7
autoridades, debe garantizarse que las cuentas que se añaden sean siempre un desglose de las
obligatorias, con el fin de poder obtener los saldos y movimientos de estas últimas por simple
agregación.
Los procedimientos generales existentes deben definir el flujo de los documentos, qué
información de cada uno debe registrarse contablemente, y cual debe llevarse eventualmente a
otros registros operativos.
El resultado de este proceso es la definición de una maqueta de la transacción1 que se registrará
en el diario a partir del documento primario.
Una buena definición de las cuentas a afectar, por cada tipo de documento que se recibe para su
contabilización, facilita posteriormente la automatización del registro contable. Obviamente,
siempre existirán excepciones que deben ser tratadas caso a caso por personal con suficiente
calificación.
2.4 El registro en el libro diario

El registro en el libro diario de los datos de un documento primario (ver cuadro 4), cuando existe
una maqueta de la transacción, es una labor rutinaria, en esencia de transcripción. Esta tarea
requiere, no obstante, un especial cuidado con el fin de que no se produzcan errores. En este
proceso se genera por cada transacción, adicionalmente, un comprobante que da fe de la
contabilización efectuada.
En ciertos casos, el documento primario a registrar en el diario constituye de por si un registro de
varias transacciones, que debe verse como un desglose del diario. Este es el caso, por ejemplo, de
las cintas de papel producidas por las terminales de puntos de venta, que contienen el detalle de
lo vendido y constituyen un documento primario, del cual se puede registrar sólo el valor total.
1
En el presente trabajo se utilizará el término transacción para definir el conjunto de asientos contables que deben
registrarse de forma integral en el diario para que este mantenga su consistencia. Como mínimo una transacción deberá
estar integrada por dos asientos, uno débito y uno crédito, y siempre su saldo total deberá ser igual a cero.
8
Registrar en el diario
Diario general
DOCUMENTO PRIMARIO Fecha Cuenta/Observaciones Referencia Débitos Créditos
1/1/2012 Cuentas por cobrar Factura 1 10000

Ingresos por ventas 10000
Venta a empresa XXX
Maqueta de Transacción
Comprobante
Escaque x -> Cuenta 1 / Signo
Referencia Factura 1
Escaque y -> Cuenta 2 / Signo Fecha 1/1/2012
Escaque z -> Cuenta 3 / Signo
. Cuenta Débito Crédito
. Cuenta por cobrar 10000
Escaque w -> Cuenta n / Signo Ingresos por ventas 10000
Observaciones
Venta a empresa XXX
Cuadro 4
2.5 El archivo del documento primario

El archivo del documento primario (ver cuadro 5) debe realizarse utilizando un criterio uniforme,
que permita con posterioridad su rápida localización. La existencia de un registro de entrada, que
le otorgue un número secuencial único a cada documento, proporciona un criterio simple de
archivo de los documentos primarios y sus correspondientes comprobantes de contabilización.
En lugares con un gran volumen de documentos es a veces conveniente estratificar el archivo, por
ejemplo, con carpetas por cada día contable.
No se recomienda utilizar otros criterios de archivo de los documentos primarios, como clientes,
suministradores, dependencias organizativas, etc. Cuando se emplea alguno de esos criterios,
cualquier error en el archivo de un documento es de muy difícil detección. Por otra parte, los
datos contenidos en el registro de entrada deben permitir clasificar de forma simple los
documentos primarios por cualquiera de esos criterios, con el fin de facilitar su localización.
Cuando el documento primario contabilizado deba ser objeto de algún proceso posterior, se
requiere, adicionalmente a su archivo secuencial, el archivo de una copia del documento en un
orden cronológico ascendente de las fechas en que esos documentos deben ser tratados. A este
archivo cronológico de los documentos sobre activos o pasivos pendientes (follow up en inglés)
también se le da el nombre de cartera.
9
Archivo de documentos primarios
POR NUMERO DE
REGISTRO DE ENTRADA
DOCUMENTO PRIMARIO
DOCUMENTOS
PRIMARIOS Y
COMPROBANTES
DE
CONTABILIZACION
Comprobante
Referencia TPV 12
Fecha 1/1/2012 EN ORDEN CRONOLÓGICO
Cuenta Débito Crédito
(EVENTUAL)
Efectivo 5432.34
Ingresos por ventas 5432.34
Observaciones CARTERAS
Ventas TPV 12 COPIA
DOCUMENTO
PRIMARIO
Cuadro 5
2.6 La gestión de activos y pasivos pendientes

La gestión de activos y pasivos pendientes tiene una gran importancia para la actividad financiera
de la institución, y no es más que la revisión periódica de las carteras que se conformaron con
copias de los documentos primarios procesados que requerían un posterior tratamiento, junto con
la ejecución de las acciones que sea necesario realizar en dependencia de las características del
documento, por ejemplo, enviar un recordatorio a un cliente con una cuenta por pagar.
En general, este proceso debe realizarse diariamente y, para todos los documentos que estén
vencidos o venzan ese día, se deberá: o ejecutar una acción, o decidir una fecha posterior en la
que se deberá actuar.
De modificarse la fecha de vencimiento, se reubicará el documento dentro de la cartera.
Si la demora en la ejecución del activo o pasivo implica un cambio en el concepto contable, se
modificará la cuenta y se registrará este cambio en el diario.
Así, por ejemplo, una cuenta por cobrar que tenga más de 30 días debe pasarse, según las normas
vigentes en la actualidad, de cuentas por cobrar a cuentas por cobrar vencidas, a través de su
registro en el diario.
Algo similar ocurre cuando un hecho provoca el cambio del concepto contable de una cartera. Por
ejemplo, cuando se recibe una letra como garantía del pago de una cuenta por cobrar, el
documento en cuestión, junto con la letra, deben pasar de las cuentas por cobrar a los efectos por
cobrar. Este cambio, obviamente, debe registrarse también en el diario.
10
2.7 El registro de los asientos en los libros mayores
El registro de los asientos en los libros mayores (ver cuadro 6) se hace a partir del libro diario,
permite calcular para cada cuenta su saldo y deja una traza de todos los movimientos que lo
alteraron. En un ambiente clásico de contabilidad, donde los mayores se llevan manualmente, esta
tarea es, al igual que el registro en el diario, rutinaria y básicamente de transcripción y suma,
aunque no por ello exenta de errores.
Registrar en mayores
Diario general
Fecha Cuenta/Observaciones Referencia Débitos Créditos
1/1/2012 Efectivo TPV 12 5432.34

Ingresos por ventas 5432.34
Ventas TPV 12
…..
……
1/1/2012 Cuentas por cobrar Factura 1 10000
Ingresos por ventas 10000
Ventas a Empresa XXX
Mayor Ingresos por ventas

Fecha Referencia Débitos Créditos Saldo
1/1/12 TPV 12 5432.34 5432.34
1/1/12 Factura 1 10000 15432.34
Mayor Efectivo
1/1/12 TPV 12 5432.34 5432.34
Mayor Cuentas por cobrar

1/1/12 Factura 1 10000 10000
Cuadro 6
2.8 La conciliación de los estados de cuenta

La conciliación de los estados de cuenta es uno de los procesos que mayor seguridad le da a los
registros contables. La probabilidad de que dos entidades cometan por separado el mismo error
en sus registros contables es extraordinariamente baja, por lo que comparar los saldos y
movimientos de cuentas comunes y garantizar que sean iguales, aumenta considerablemente la
confiabilidad de los datos.
Existen dos formas de conciliar los estados de cuenta: la activa y la pasiva.
La forma activa de conciliación consiste en solicitar un estado de cuenta a la contraparte, por lo
general un suministrador de productos o servicios de la entidad, y comparar ese estado de cuenta
con los registros propios.
La más utilizada de las conciliaciones activas, y una de las más importantes en general, es la
conciliación del estado de cuenta que emiten los bancos.
No es excepcional que entidades registren en el diario su cuenta de banco a partir del estado de
cuenta que este les envía. Esa práctica no es necesariamente la más sana. El estado de cuenta de
un banco no debe considerarse como un documento primario, sino como un documento para la
11
conciliación, sobre todo en los casos en que el estado de cuenta no se recibe diariamente sino, por
ejemplo, una vez al mes.
Exigirle al banco notas de débito o crédito cada vez que se mueve la cuenta bancaria y utilizar
estas como documento primario para el registro contable, dejando el estado de cuentas para la
conciliación, debe producir mejores resultados.
La forma pasiva de conciliación se utiliza normalmente con clientes de la entidad y consiste en
elaborar un estado de la cuenta del cliente y enviárselo, solicitándole que comunique sus
discrepancias o conformidad con el mismo en un plazo razonable.
2.9 El balance de comprobación

El balance de comprobación (ver cuadro 7) se emite a partir de los libros mayores.
Emitir Balance de Comprobación

Mayor Ingresos por ventas
Mayor Efectivo
1/1/12 TPV 12 5432.34 5432.34
1/1/12 TPV 12 5432.34 5432.34
1/1/12 Factura 1 10000 15432.34
Mayor Cuentas por cobrar

1/1/12 Factura 1 10000 10000
Balance de comprobación
Cuentas Saldo inicial Débitos Créditos Saldo final
Activos
Pasivos
Capital
Total 0 XXXXX XXXXX 0
Cuadro 7
Generalmente, el balance de comprobación contiene una lista de todas las cuentas de la entidad
con cuatro posibles valores: saldo inicial, que es el saldo del último balance de comprobación
cuadrado, débitos, con la suma de todos los débitos que se han registrado en la cuenta durante el
período, créditos, con la suma de todos los créditos que se han registrado en la cuenta durante el
período, y saldo final, con el saldo de la cuenta al momento de emitirse.
Si no se han producido errores en el registro del diario y de los mayores, la suma de las columnas
saldo inicial y final debe ser cero y el total de la columna débitos debe ser igual al de la columna de
créditos. Cuando esto no es así, deben revisarse el diario, los mayores y en ciertos casos hasta los
documentos primarios, con el fin de localizar los errores y corregirlos.
12
2.10 La depuración de errores
La depuración de errores es un proceso que puede descomponerse básicamente en tres tareas: la
detección del error, la localización de las causas que lo provocaron y la corrección del mismo.
Las principales fuentes de detección de errores, como ya se ha explicado, son la conciliación de los
estados de cuenta y la emisión y cuadre del balance de comprobación.
La localización de las causas que provocaron un error determinado se logra normalmente con una
mezcla de conocimiento, experiencia, algo de arte y bastante esfuerzo.
En general, la mejor fórmula es ir acumulando información sobre los procesos que dieron origen a
los datos discrepantes, hasta que la causa del error se haga evidente.
En un sistema contable, cuando el error se origina en el registro del diario, la corrección debe
realizarse siempre reversando los asientos originales, a través de su registro con signo contrario, e
introduciendo nuevamente la transacción con los datos correctos.
2.11 La emisión de los estados financieros

La emisión de los estados financieros, básicamente el balance general y el estado de resultados, se
puede realizar a partir del balance de comprobación o de los libros mayores, una vez que se han
depurado los posibles errores.
Las normas de contabilidad vigentes condicionan el formato de los estados financieros que deben
ser entregados a la autoridad fiscal y que son objeto de auditoría. Frecuentemente las entidades
tienen otros formatos de estados financieros, más detallados y ajustados a sus requerimientos de
análisis y toma de decisiones.
13
PAGINA DEJADA INTENCIONALMENTE EN BLANCO
14
3 Niveles de automatización de los SAC
3.1 Producir un diario en soporte electrónico

La automatización del ciclo contable en el marco de la elaboración de un Sistema Automatizado de
Contabilidad (SAC) ha pasado por diversos estadios y aun no puede darse por concluida
totalmente.
En una primera etapa (ver cuadro 8), a partir de las posibilidades de los medios de computación
existentes en aquel momento, el esfuerzo se concentró en producir un diario en soporte
electrónico que permitiera la automatización de algunos procesos posteriores. Ya con el uso de
equipos de tarjetas perforadas, a partir de los años 20 del pasado siglo, este nivel de
automatización era factible.
Los procesos que en este estadio quedaron totalmente automatizados fueron el registro en los
mayores, la emisión del balance de comprobación y la emisión de los estados financieros. La
gestión de las carteras en esta etapa sólo pudo automatizarse parcialmente, con la emisión de
reportes periódicos sobre las partidas vencidas.
Los principales efectos de este primer paso de la automatización de la contabilidad fueron: la

eliminación de los errores de transcripción y suma que se cometían en el trabajo manual, y la
notable disminución del tiempo requerido para la emisión de los estados financieros.
REGISTRO
REGIS
ENTRADA
PRIMARIOS
Definición de cuentas a afectar Gestión de carteras
DIARO
Registro en el diario
CARTERAS
Archivo de documento DOCUMENTOS

PRIMARIOS
NO
FIN PERIODO
SI

SI
ERRORES
BALANCE
REGIS
COMPROBACION
SI
ERRORES
BALANCE
ESTADO
REGIS DE
Cuadro 8
En este primer estadio de la automatización, el registro en el diario se continuaba haciendo

asiento por asiento, con lo que el cuadre total no estaba garantizado.
15
3.2 Transaccional
Con el desarrollo de los medios de computación y las posibilidades de su programación, se pasó a
un segundo estadio, en el que la maqueta de una transacción se incluye en la lógica del programa
de captación de los datos del documento primario. Utilizando esos programas, una vez
introducidos los datos y verificada su validez formal, se generan los asientos contables
correspondientes (ver cuadro 9).
REGISTRO
REGIS
ENTRADA
PRIMARIOS

DIARO
(incluye la lógica de
las transacciones) CARTERAS

PRIMARIOS
NO
FIN PERIODO
SI

SI
ERRORES
BALANCE
REGIS
COMPROBACION
BALANCE
ESTADO
REGIS DE
Cuadro 9
Debido a que el trabajo de una computadora puede interrumpirse en cualquier momento, para
que el fichero diario no quedara en ningún momento incoherente por la actualización parcial de
los asientos que componen una transacción, los medios de programación, y en particular las bases
de datos, tuvieron que evolucionar hasta el punto de garantizar que el conjunto de actualizaciones
de ficheros requeridas para registrar una transacción, o se hiciera en su totalidad o no se hiciera.
Esta característica de las bases de datos se le da el nombre de atómica, por el hecho de que la
transacción se considera como un átomo indivisible.
Un segundo aspecto a resolver por las bases de datos fue que la transacción garantizara el
cumplimiento de un grupo de reglas formales declaradas previamente. Por ejemplo, el código de
un cliente al que se le quiere registrar una cuenta por cobrar debe estar previamente definido en
la tabla de clientes, en la que se encuentran todos los datos necesarios sobre el mismo.
Para garantizar esta consistencia en la base de datos, es necesario que cuando una transacción
incumpla alguna de las reglas formales definidas, la misma sea rechazada en su totalidad, en
correspondencia con la característica de atomicidad explicada previamente.
16
Con la inclusión de la maqueta de la transacción en los programas para la actualización del diario,
fue posible garantizar totalmente el cuadre contable desde un inicio, obviamente siempre y
cuando estos programas no tuvieran errores.
Una consecuencia de este avance es que la emisión del balance de comprobación para la
detección de posibles errores de cuadre se hace innecesaria, ya que el conjunto de los saldos de
las cuentas del mayor se conforma sumando los asientos de las transacciones a la cuenta que
corresponda, y si cada transacción está cuadrada, la suma de ellas tiene que estarlo también
forzosamente.
3.3 Recepción de documentos primarios en soportes electrónicos

El siguiente paso en la automatización de los registros contables de una entidad se produjo con la
recepción de los documentos primarios en soportes electrónicos (ver cuadro 10).
Existen múltiples alternativas técnicas para lograr este objetivo, que van desde utilizar soportes
externos (cintas magnéticas y discos flexibles en un inicio, DVDs, memorias flash, etc. en la
actualidad) que se entregan manualmente, hasta que los clientes internos y externos de la
entidad, que realizan las operaciones que deben registrarse contablemente, interactúen
directamente con el sistema contable.
DOCUMENTOS
Recepción documento primario REGISTRO
DE
PRIMARIOS
ENTRADA

DIARO
las transacciones) CARTERAS

PRIMARIOS
NO
FIN PERIODO
SI

SI
ERRORES
BALANCE
REGIS
COMPROBACION
BALANCE
ESTADO
REGIS DE
Cuadro 10
El acceso simultáneo al sistema contable por múltiples usuarios introdujo la necesidad de que los
sistemas de bases de datos garantizaran que no se produjeran interferencias entre las
transacciones que en un mismo momento se estaban ejecutando. A esta característica de las
bases de datos se le da el nombre de aislamiento (isolation en inglés). La misma garantiza que las
diferentes transacciones se ejecuten finalmente siempre de forma secuencial, una tras la otra.
17
Por último, para que las bases de datos pudieran ser el soporte de las operaciones vitales de una
entidad las mismas tuvieron que garantizar que en ningún momento se perdieran datos ya
registrados (durabilidad de las actualizaciones). Esta característica se logra de múltiples formas,
entre las que se destacan las salvas totales de ciertos estados de la base de datos y las bitácoras de
todo lo hecho, almacenadas en medios físicos diferentes.
Con las posibilidades actuales de la comunicación y las computadoras no es raro que, para
aplicaciones importantes, se actualice en paralelo y en tiempo real una copia de la base de datos,
ubicada físicamente en otra localidad, con lo que se logra una seguridad casi total.
Cuando un sistema de gestión de bases de datos cumple los cuatro requisitos explicados
anteriormente se dice que el mismo pasa la prueba A.C.I.D., por el nombre de esas características
en inglés (Atomicity, Consistency, Isolation y Durability) (ver 1).
3.4 Integración del SAC en un ERP

El siguiente estadio en la automatización del ciclo contable está dado por la integración del
sistema contable en el sistema automatizado de toda la actividad de la entidad en cuestión.
El surgimiento de sistemas para la planificación de los recursos de una empresa (ERP por sus siglas
en inglés, Enterprise Resource Planning) es el resultado de esta etapa de la automatización, no ya
del sistema contable, sino de toda la actividad empresarial.
El cuadro 11 muestra el esquema del ERP SAP R/3, que mantiene un liderazgo indiscutible en este
tipo de aplicación.
ERP SAP R/3

Integración en Extensa
SD FI
tiempo real Comercial Gestión funcionalidad
financiera
MM CO
Materiales Control
Abierto y
flexible
PP
Producción
R/3 TR
Tesorería Arquitectura
modular
QM Client/Server PS
Proyectos
Arquitectura
Cliente/Servidor
Calidad
PM ABAP/4 WF
Mantenimiento
Flujo de
trabajo
HR
Recursos
IS
Soluciones
humanos sectoriales
Modelo de Multi...
gestión
Cuadro 11
18
En SAP, las funciones que pudieran considerarse propias de un sistema de contabilidad, son parte
de cuatro módulos (Gestión financiera, Control, Tesorería y Proyectos), todos integrados entre sí y
con los demás módulos automatizados de la empresa.
Los ERP garantizan, entre otros aspectos, que toda la información de una entidad tenga una
fuente única definida, con lo que se elimina la redundancia en los datos, que siempre es el primer
paso hacia las contradicciones entre los mismos.
3.5 Interacción con otros sistemas automatizados

Por último los sistemas automatizados, ya sean sólo de contabilidad o ERP, son en la actualidad
capaces de interactuar con sistemas automatizados de otras entidades, con el fin de ejecutar
operaciones de forma automática, o enviar y recibir datos requeridos para sus procesos.
La generalización de estas posibilidades pasa por la existencia de normas detalladas que definan
formalmente la interacción entre sistemas automatizados para resolver ciertas tareas.
A diferencia de los humanos, los sistemas automatizados no tienen, al menos por el momento, la
capacidad de improvisar, por lo que todas las posibles acciones a realizar y los datos a
intercambiar en una interacción entre ellos, tienen que estar totalmente previstos y formalizados.
Se le da el nombre de protocolo al conjunto de definiciones que permite que dos equipos de
computación o comunicación intercambien información de forma ordenada.
Con las posibilidades que brinda la interacción entre sistemas automatizados es factible eliminar
en gran medida la gestión de las carteras, así como la conciliación de los estados de cuenta del
flujo contable explicado al inicio (ver cuadro 12).
REGISTRO Recepción documento primario DOCUMENTOS

PRIMARIOS
DE
ENTRADA
OTROS
DIARO S
I
las transacciones) CARTERAS S
T
E
PRIMARIOS M
NO
FIN PERIODO A
S
SI

AUTO-
MATIZA-
Conciliación de estados de cuenta DOS
SI
ERRORES
BALANCE
REGIS
COMPROBACION
BALANCE
ESTADO
REGIS DE
Cuadro 12
19
En la realidad actual de Cuba, la mayor parte de los sistemas contables automatizados,
representan una mezcla del segundo y tercer nivel de automatización explicados anteriormente.
La tendencia cada vez más fuerte a nivel mundial es, sin embargo, que en las entidades se utilicen
ERP, donde el sistema automatizado contable sea, como ya se comentó, un módulo del ERP o
partes de distintos módulos de este.
De igual forma se impone, en una marcha sin retrocesos, la interacción de los sistemas
automatizados de diferentes entidades. Este proceso se ha potenciado en los últimos años por el
vertiginoso desarrollo de INTERNET.
En los últimos 30 años ha surgido un grupo importante de entidades, a niveles regional y mundial,
que definen formalmente las posibles interacciones entre sistemas automatizados en diferentes
ramas, y otras que brindan el servicio de pasarelas de datos entre estos. A continuación algunos
ejemplos.
 La sociedad mundial para las telecomunicaciones financieras interbancarias (SWIFT por las
siglas de su nombre en inglés, Society for Worldwide Interbank Financial
Telecommunications), creada a inicios de la década de los 70 del pasado siglo. SWIFT se
constituyó como una compañía sin ánimos de lucro, en la que los usuarios de sus servicios
(bancos exclusivamente en un inicio) estaban obligados a comprar acciones de la misma, y
eran por lo tanto también sus dueños.
Los servicios que ofertó SWIFT desde el principio fueron: la estandarización de los formatos de
mensajes a intercambiarse entre bancos para distintas operaciones (transferencia de fondos,
cartas de crédito, etc.), lo que permitió que los sistemas automatizados pudieran tratar
directamente los mensajes recibidos; y una plataforma de comunicaciones con las debidas
medidas de seguridad y protocolos de acceso bien definidos, para el intercambio de esos
mensajes entre los bancos asociados.
En la actualidad a SWIFT están conectados más de 10000 bancos en 212 países, y a través de
sus redes de comunicación se intercambian unos 26 millones de mensajes financieros diarios
(ver 20).
 Los sistemas de liquidación bruta en tiempo real (SLBTR), que normalmente existen en cada
país o área geográfica. Estos sistemas son operados por el Banco Central del país en cuestión,
o por una entidad subordinada a este, y les permiten a los bancos, utilizando mensajes
estandarizados, en muchos casos según las mismas normas de SWIFT, realizar de forma
automatizada las transacciones entre los bancos que pertenecen al sistema. Adicionalmente a
los servicios que brinda SWIFT, los SLBTR ofrecen también el servicio de actualizar las cuentas
de los bancos en el banco central correspondiente, cerrando así totalmente el ciclo del
movimiento de fondos (ver 19).
20
 EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport)
auspiciado por Naciones Unidas (ver 25) y ANSI X12 en EEUU (ver 38). Tanto EDIFACT como
ANSI X12 proponen los formatos de los documentos más utilizados en las relaciones
comerciales entre empresas (solicitud de oferta, oferta, contrato de compraventa, lista de
empaque, conocimiento de embarque, factura comercial, etc.), y representan un soporte del
comercio electrónico.
 Bolero (Bill of Lading Electronic Registry Organisation). Bolero se creó como compañía en
septiembre de 1999. Sus principales accionistas fueron la ya nombrada SWIFT, el TT-Club que
es una asociación de entidades que funcionan en el ámbito de la transportación marítima, a la
que pertenecen más de las dos terceras partes de estas, y un grupo de inversores privados.
Como su nombre lo indica el principal objetivo de Bolero es mantener un registro electrónico
de conocimientos de embarque (Bill of Lading), de tal forma que las operaciones relacionadas
con este importante documento del comercio internacional puedan realizarse de forma
automatizada. Entre sus resultados hasta el momento puede citarse la emisión de un libro de
reglas (Rule Book), que deben aceptar los que participen en Bolero y que, a partir de aplicar el
principio legal de la primacía de la voluntad de las partes, supera las posibles discrepancias
legales entre las legislaciones de los distintos países (ver 21). Por otra parte un grupo de
plataformas y aplicaciones se han puesto a punto y se ofertan para su uso (ver 22).
La propuesta de Bolero tiene sin dudas un alto potencial de éxito en el comercio internacional,
sin embargo, resulta significativo que, en sus ya más de trece años de existencia, no haya
alcanzado aún un volumen importante de transacciones, sin el cual su tecnología no podrá
imponerse.
21
22
4 Principales hitos en el desarrollo de los ERP o SAC
4.1 Surgimiento de la contabilidad actual

Generalmente se acepta que el inicio de la contabilidad moderna, y por lo tanto de los SAC, se
remonta al trabajo de Luca Pacioli, monje franciscano que nació en Sansepolcro, Italia, en 1445 y
falleció en el mismo lugar presumiblemente en 1517 (ver 2).
Pacioli fue en su época un hombre eminente, amigo de importantes intelectuales, entre otros,
Leonardo da Vinci, con el que compartió largos años de trabajo y que fue incluso quien realizó los
dibujos que ilustraron su obra “Divina proportione”, y de León Batista Alberti, en cuya casa vivió
algunos meses al llegar por primera vez a Roma.
Además del estudio de las matemáticas desde muy temprana edad, en su formación influyeron los
años que, a sus veinte, pasó en Venecia trabajando para el rico comerciante Rompiasi, como su
ayudante en los negocios y tutor de sus tres hijos.
Pacioli nunca pretendió que el contenido de sus escritos fuera original, el mismo decía que sus
libros eran básicamente una recopilación de los conocimientos y usos de la época.
Su principal obra, llamada “Summa de Arithmetica, Geometrica, Proportione et Proportionalita”,

fue publicada en italiano en 1494.
El tratado XI de este libro, que lleva el nombre de “Particularis de Computis et Scripturis” (ver 3),
presenta una descripción detallada de cómo registrar los hechos económicos de un negocio, según
las costumbres existentes en Venecia en esa época. El mismo contiene los principales elementos
formales de los sistemas de contabilidad que se utilizaban ya en esa época, y que son válidos hasta
el día de hoy, a saber:
• La ecuación fundamental de la contabilidad

Activos = Pasivos + Capital
• Las siguientes reglas
– No hay deudor sin acreedor
– La suma que se adeuda a una o varias cuentas, ha de ser igual a lo que se abona
– Todo el que recibe debe a la persona que da o entrega
– Todo valor que ingresa es deudor y todo valor que sale es acreedor
– Toda pérdida es deudora y toda ganancia acreedora
23
Durante siglos, los registros contables se llevaron de forma manual, siguiendo normas que fueron
perfeccionándose en cada país2, pero que en esencia mantuvieron la construcción formal
explicada por Pacioli.
4.2 Los equipos de tarjetas perforadas

No fue hasta finales de la década del 20 del pasado siglo cuando se produjeron cambios
importantes en este estado de cosas. En aquellos años se comenzó a generalizar el uso de equipos
de tarjetas perforadas, que habían sido empleados por primera vez para el procesamiento del
censo de Estados Unidos de 1890.
Estos equipos utilizaban una codificación especial en tarjetas, que permitía representar las 26
letras y los 10 números en una columna de 12 posibles perforaciones, y leían los datos a través de
contactos eléctricos.
El estadounidense Hermann Hollerith fue quien inventó la codificación para las tarjetas y fue
también de los primeros en desarrollar equipos para su procesamiento (ver 4). En 1896 creó la
“Tabulating Machine Company”, predecesora de la principal empresa a nivel mundial de equipos
de procesamiento de datos durante muchos años, la “International Business Machines” (IBM).
Entre las décadas de los 30 y los 50 del pasado siglo, se introducen y utilizan ampliamente los
equipos de tarjetas perforadas para apoyar los sistemas de contabilidad, así como los llamados
equipos de saldo directo y las calculadoras mecánicas y eléctricas.
Los equipos de tarjetas perforadas permitían ya en aquellos años lograr el primer nivel de
automatización antes esbozado, debido a que, una vez que los asientos contables hubieran sido
registrados en tarjetas (lo que equivalía a hacer las anotaciones en el diario), la emisión de los
mayores, balances de comprobación y estados financieros, así como la revisión de los
vencimientos de las carteras, podía hacerse de forma automatizada, utilizando procedimientos
diseñados y “programados”3 en los diferentes equipos que componen los sistemas de tarjetas
perforadas (ver recuadro “Componentes de los sistemas de tarjetas perforadas”).
Los equipos de saldo directo automatizaban, hasta cierto punto, la mecanografía del pase a los
mayores, a partir de los documentos primarios o los comprobantes de registro en el diario. Con
estos equipos los mayores quedaban en cartulinas, que detallaban todos los movimientos e
incluían el cálculo de los saldos después de cada partida.
2
El hecho de que cada país defina las normas contables, que deben ser respetadas por todos las entidades que actúan
en el ámbito económico tiene como causa, desde tiempos inmemorables, poder garantizar un soporte documental, que
pueda ser inspeccionado, para el cobro de los impuestos que se deben pagar.
3
Cada uno de los equipos de tarjetas perforadas tenía una pizarra con una matriz de contactos. La
programación de un equipo determinado se hacía conectando los diferentes contactos, con cables
diseñados para eso, según las funciones que les correspondían. Cada equipo podía tener varias pizarras que
se utilizaban, en dependencia del proceso que se estuviera realizando, en un momento determinado. Para
cada proceso existía un diagrama de flujo que especificaba el movimiento de los lotes de tarjetas (ficheros) a
través de los diferentes equipos y las pizarras a utilizar.
24
Las calculadoras se utilizaban fundamentalmente para realizar la suma de muchas partidas con
gran seguridad, ya que producían un listín con todas las cifras introducidas y los totales calculados,
el cual facilitaba posteriormente la comprobación de las operaciones realizadas4.
Los sistemas de tarjetas perforadas
Un sistema de tarjetas perforadas estaba compuesto normalmente por los siguientes equipos:
Perforadora. Equipo que reproducía la información que se introdujera a través de un teclado, en

una tarjeta con 80 columnas. Cada columna podía tener hasta 12 perforaciones que permitían,
utilizando un codificación específica, representar o un número o cualquiera de las 26 letras del
alfabeto.
Verificadora. Equipo similar a la perforadora pero que comparaba lo que se tecleaba con el
contenido de una tarjeta ya perforada. Si detectaba alguna diferencia la señalaba y rechazaba la
tarjeta.
Clasificadora. La clasificadora procesaba un lote de tarjetas y colocaba en diferentes bolsillos las

tarjetas que en determinadas filas tuvieran igual valor. Las tarjetas que habían caído en los
diferentes bolsillos se fusionaban posteriormente de forma manual y en orden. A través del
trabajo de la clasificadora y con la participación de un operado, un lote de tarjetas, en principio de
cualquier tamaño, podía clasificarse de forma ascendente o descendente según el contenido de
varias filas, dándole un pase en la clasificadora al lote completo para cada fila.
Intercaladora. La intercaladora procesaba dos lotes de tarjetas y los mezclaba siguiendo un orden
ascendente o descendente según el contenido de varias filas. Este proceso servía por ejemplo para
intercalar en un fichero con los movimientos de un cliente, su nombre, que estaba registrado en
otro lote de tarjetas von un formato distinto al de los movimientos.
Calculadora. La calculadora era capaz de realizar operaciones aritméticas entre cifras que
estuvieran codificadas en una tarjeta, perforando en las columnas que se le indicaran el resultado.
Tabuladora. La tabuladora era una impresora especializada, que podía, además de imprimir el
contenido de una tarjeta con un formato preestablecido, calcular totales a distintos niveles, a
partir del contenido de ciertos campos, e imprimirlos al final de cada nivel.
4.3 Las computadoras
4
Los ábacos, instrumentos que permiten realizar sumas a mano a una gran velocidad, y los cálculos
mentales, que eran las posibilidades que existían antes de las calculadoras con impresión, tienen la
desventaja de que cuando hay errores hay que rehacer totalmente la suma.
25
Ya en la segunda mitad de la década de los 50 del pasado siglo surgen computadoras, de la
llamada segunda generación, especializadas en el procesamiento de datos. Estados Unidos, Rusia y
Francia fabricaron, entre otros países, computadoras de este tipo.
De Estados Unidos el sistema de segunda generación más popular fue el IBM serie 1400. La Unión
Soviética Produjo, entre otros, el equipo Minsk 22 y Francia la SEAT 4000, de la cual Cuba adquirió
dos unidades a finales de la década del 60.
Todos estos equipos de la segunda generación, especializados en procesamiento de datos5, tenían

lectores de tarjetas perforadas, almacenamiento en cintas magnéticas, impresoras de alta
velocidad, compiladores para lenguajes de programación, en su mayoría muy elementales, y una
memoria interna del orden de los 16 kilobytes (una memoria flash actual tiene un millón de veces
la capacidad de aquellos pioneros).
En esta primera etapa del uso de las computadoras en los SAC, lo que fundamentalmente
permitían estas era realizar, de una forma más eficiente y sin la manipulación física de las tarjetas,
los mismos procesos que se ejecutaban hasta ese momento en equipos de tarjetas perforadas.
La actualización de los mayores y la emisión del balance de comprobación y los estados

financieros, a partir de un diario que existe en un soporte procesable por medios
electromecánicos o electrónicos, puede realizarse siempre con una combinación de procesos de
clasificación, fusión, cálculo y tabulación de los artículos que componen el diario. Como ya se
explicó, los sistemas de tarjetas perforadas tenían ya equipos especializados para estas funciones.
Uno de los primeros lenguajes de programación para computadoras desarrollado por IBM fue el
Report Program Generator RPG6 (Ver 5), que permitía describir un proceso sistematizado para
equipos de tarjetas perforadas y, a partir de esa descripción, generar programas para
computadoras que ejecutaban las mismas acciones.
A inicios de la década de los 60 del pasado siglo, surgen las computadoras de la tercera
generación, entre las que se destaca la línea de equipos IBM 360.
Esta línea IBM 360 ofrecía compatibilidad entre todos los modelos, tanto para los programas,
como para los periféricos; contaba con un sistema de explotación que incorporaba los adelantos
del momento, un buen sistema de gestión de ficheros y compiladores para los lenguajes de
programación más avanzados en ese entonces (Cobol, Fortran, PL/1, etc.) .
5
Las generaciones de computadoras se clasificaron en general a partir del componente electrónico utilizado
para su construcción. Así, las computadoras de la primera generación utilizaban tubos de rayos catódicos,
las de la segunda transistores, las de la tercera circuitos integrados y las actuales microprocesadores. Los
equipos de la segunda generación estaban especializados en cálculos científicos o procesamiento de datos.
6
Las dificultades que se generan cuando se quieren modificar sistemas automatizados de gran dimensión,
que están en funcionamiento, son de tal magnitud que el lenguaje RPG, con sus modernizaciones claro está,
se utiliza aun en algunas aplicaciones contables en computadoras IBM, que han venido arrastrando la
codificación original por más de 60 años.
26
Los modelos de la línea IBM 360 iban desde pequeñas computadoras, hasta los equipos más
potentes del momento.
Los equipos de la tercera generación, y en particular la línea IBM 360, provocaron la sustitución
masiva de los sistemas de tarjetas perforadas7.
No obstante, debido a que al igual que con los sistemas de tarjetas perforadas y las computadoras
de la segunda generación, el procesamiento de los datos se realizaba enviando los documentos
primarios a un centro de cálculos, donde se procesaban por lotes (diarios, semanales, etc.) para
obtener los resultados, que se entregaban normalmente uno o varios días después, el nivel de
automatización que ofrecían estos primeras computadoras de la tercera generación no se
diferenció de lo alcanzado hasta ese momento.
El procesamiento por lotes tiene la desventaja de que aísla totalmente el usuario del sistema de
procesamiento, básicamente con el objetivo de mantener una especialización y garantizar la
eficiencia y la delimitación de responsabilidades. La comunicación entre el centro de
procesamiento y el usuario es siempre sobre la base de documentos.
Sólo para depurar los errores contenidos en los datos, con un volumen de 10000 artículos y una
tasa de error del 1%, se requieren cinco intercambios de documentos entre el centro de
procesamiento y los usuarios (entrega de los documentos que generan los 10000 artículos,
devolución de lista de 100 errores, entrega de corrección de 100 errores, entrega de listado con un
error, entrega de corrección del error).
Si debido a razones tecnológicas del centro de procesamiento, que por lo general no atiende a un
sólo sistema, los resultados requieren de varias horas o incluso un día, se puede imaginar lo
dilatado del proceso en su conjunto.
Debido a sus altos costos, las pequeñas y medianas empresas, salvo excepciones, no tenían acceso
aun a esta tecnología.
4.4 Las redes de terminales

A finales de la década de los 60 del pasado siglo los equipos de computación adquieren la
capacidad de atender redes de terminales. Hasta ese momento la interacción con la computadora
se realizaba exclusivamente a través de una consola para operarla.
La utilización de redes de terminales permitió que varias personas pudieran interactuar con la
computadora al mismo tiempo, resolviendo tareas independientes o colaborando en una misma
tarea.
Para que un conjunto de terminales pudiera conectarse a una computadora era necesario utilizar
tecnologías de multiprocesamiento y tiempo real. Las altas velocidades que habían adquirido las
computadoras ya en ese momento, y el crecimiento de sus memorias operativas, les permitían
realizar varias tareas al mismo tiempo, dando la sensación de que todas se ejecutaban en paralelo
7
IBM, además de ser el fabricante y comercializador único de las IBM 360, era el principal arrendador y
suministrador de equipos de procesamiento de tarjetas perforadas, por lo que lo que promovió fue sustituir
esos equipos con sus nuevas computadoras.
27
(multiprocesamiento). Por otra parte, la capacidad de interrumpir un proceso a partir de un
evento externo, permitía que las tareas que lo requirieran tuvieran prioridad sobre otras y
pudieran ejecutarse en los plazos requeridos (tiempo real). Por razones psicológicas (ver 6), la
respuesta de la computadora, al recibir una orden del operador a través del teclado u otro
periférico, no debe sobrepasar cierto tiempo8.
La conexión de múltiples terminales a una computadora permitió por primera vez llevar las
capacidades de estos equipos a los puestos de trabajo de los especialistas. Este paso de avance en
la tecnología permitió eliminar el procesamiento por lotes y les dio acceso directo al SAC a los
empleados de las áreas de contabilidad, para introducir los datos de los documentos primarios, y
consultar ciertas tablas desde sus puestos de trabajo.
Por otra parte, con la captación directa de los datos en tiempo real, se hizo posible formalizar en
un programa las maquetas de las transacciones, garantizando la validación formal de los datos en
el momento de su captación. Esta posibilidad, además de eliminar las iteraciones requeridas para
eliminar los errores en el procesamiento por lotes, acelerando extraordinariamente todo el
proceso, permitió además que el registro en el diario estuviera siempre libre de errores formales,
incluyendo el cuadre.
4.5 Las minicomputadoras, las bases de datos y UNIX

La década de los años 70 del pasado siglo fue testigo de importantes desarrollos en los medios de
computación, el software y los medios de comunicación.
En este período vieron la luz las minicomputadoras, que permitieron, por una parte, que las
medianas empresas y algunas pequeñas tuvieran acceso a medios de computación, y por otra, que
las grandes empresas pudieran construir sistemas a varios niveles. En estos sistemas, los niveles
inferiores se cubrían con minicomputadoras y redes de terminales, que recolectaban los datos y
los transmitían por medios electrónicos a centros con computadoras grandes, donde se realizaba
el procesamiento principal.
En junio de 1970 Edgar Frank Codd, científico de origen inglés que trabajaba en el Laboratorio de
Investigación de IBM en San José, California, publicó un artículo sobre el uso de la teoría
matemática relacional, aplicada a las bases de datos (Ver 7), que proporcionó el fundamento
teórico de los modernos sistemas de gestión de bases de datos.
Antes del trabajo de Codd, las dos estructuras más utilizadas en las bases de datos eran la
jerárquica y la de redes. Estas estructuras no garantizaban la recuperación de todas las
combinaciones posibles de los datos almacenados, requerían de una habilidad especial, cercana al
arte, para obtener ciertos resultados, no resolvían los problemas de posibles incoherencias que
provoca la redundancia de datos, y obligaban a que el que trabajaba con la base de datos
conociera exactamente la forma en que físicamente se encontraban almacenados.
8
Estudios psicológicos realizados a finales de la década del 60 mostraban que el tiempo óptimo de
respuesta de una computadora a una persona que interactúa con ella, está entre 2 y 15 segundos en
dependencia de la tarea. Si el tiempo es menor que los 2 segundos puede confundir al operador, a partir de
los 15 segundos se genera ansiedad.
28
El trabajo de Codd demostró que cualquier combinación posible de datos, almacenados en una
base de datos que utilizara una estructura relacional, podía ser recuperada de una forma
relativamente simple sin tener que conocer como físicamente estaban estos almacenados, y que,
sometiendo esas relaciones a un proceso que llamó de normalización, los problemas de
redundancia se podían resolver plenamente. Este artículo presentó, además, una primera
aproximación a un lenguaje universal para el tratamiento de datos que posteriormente evolucionó
hacia el actual Structured Query Language (SQL).
En este período de tiempo se desarrolló también el sistema de explotación UNIX (Ver 8).
Concebido para el trabajo en régimen de multiprogramación y tiempo real, fue utilizado
inicialmente de forma preponderante en las minicomputadoras y los ambientes universitarios y,
como se conoce, su arquitectura lidera hoy en sus distintas versiones el mundo del software libre.
4.6 Las PC, las fibras ópticas, Internet y los celulares

La década de los 80 del pasado siglo no fue menos prolífera que su antecesora.
En 1981 IBM saca al mercado su primera computadora personal, la IBM/PC (Ver 9), que
revoluciona por completo el uso de las computadoras, llevándolas en pocos años, al puesto de
trabajo de cada empleado y al cuarto de cada estudiante en los países desarrollados.
IBM había sufrido una notable pérdida en su participación en el mercado de las computadoras en
la década anterior, al no vislumbrar a tiempo las posibilidades de las minicomputadoras. Cuando
los directivos de IBM analizaron las primeras computadoras personales desarrolladas a finales de
la década del 70, no quisieron que les sucediera lo mismo que con las minicomputadoras y,
rompiendo buena parte de los paradigmas9 y esquemas que hasta ese momento habían dominado
la empresa, organizaron el desarrollo de la IBM/PC, la cual se anunció aproximadamente un año
después de haberse decidido su fabricación y obtuvo un éxito indudable.
En 1980 el departamento de defensa de Estados Unidos adopta el protocolo TCP/IP, para usarlo en
sus redes de computadoras, después de un largo proceso de perfeccionamiento del mismo, que
tenía sus orígenes en 197310 con la publicación de un artículo llamado “Una especificación parcial
de un protocolo Internacional de transmisión”. Ya en ese momento se había desarrollado la
9
Con la IBM/PC IBM por primera vez: En el plano organizativo, creó una unidad de negocios totalmente
independiente, hasta ese momento IBM se caracterizaba por ser una empresa con una alta integración
vertical. En el plano técnico utilizó componentes que no habían sido desarrollados por sus laboratorios, en
particular el procesador central de la firma INTEL, incluyó varios elementos de software desarrollados
también por terceros, siendo el más famoso el sistema de explotación MS-DOS de la en ese entonces
pequeña empresa Microsoft, y publicó toda la documentación técnica, registrando sólo el BIOS (basic imput
output system) como de su propiedad. Con estos pasos invitaba a toda la comunidad de desarrolladores de
periféricos y software a que sus diseños fueran compatibles con la IBM/PC, lo cual logró, desencadenando
una progresión geométrica en el uso de estos equipos.
10
En 1977 utilizando la versión 2 de TCP, en aquel entonces como un solo protocolo, se conectaron 3 redes
de computadoras que intercambiaron información a través de una distancia de más de 150000 kilómetros.
En 1978 se publica la versión 3 del protocolo que ya se separaba en dos: TCP para dividir en y unir los
paquetes, controlar los errores, y eventualmente retransmitir, e IP para enrutar los paquetes a través de la
red.
29
recomendación de OSI11 sobre un modelo de siete niveles12 (ver cuadro 13) para la interconexión
entre computadoras (ver 23).
MODELO OSI DE 7 CAPAS

USUARIO USUARIO
EQUIPO 1 EQUIPO 2
APLICACIÓN N7 PROTOCOLO N7 APLICACIÓN N7
PRESENTACION N6 PROTOCOLO N6 PRESENTACION N6
SESION N5 PROTOCOLO N5 SESION N5
TRANSPORTE N4 PROTOCOLO N4 TRANSPORTE N4
RED N3 PROTOCOLO N3 RED N3
ENLACE N2 PROTOCOLO N2 ENLACE N2
FISICO N1 PROTOCOLO N1 FISICO N1
MEDIO FISICO
DE COMUNICACION
cuadro 13
TCP/IP puede verse como una versión del modelo OSI, que mostró su eficiencia y se fue
generalizando cada vez más. La actual INTERNET utilizó prácticamente desde el inicio el protocolo
TCP/IP y en buena medida debe su éxito a las bondades del mismo.
También en el campo de los medios técnicos la década de los 80 del pasado siglo marcó un
importante hito con el desarrollo e instalación de las primeras redes de comunicación que
utilizaban fibra óptica (Ver 11), como soporte de la transmisión de datos.
Con este avance se lograban velocidades inalcanzables con las anteriores tecnologías (cobre y
ondas de radio), y se resolvían también dos importantes problemas: uno, de seguridad, al ser
prácticamente imposible interceptar los datos que se transmiten a través de una fibra óptica, y
otro, de robustez, ya que el funcionamiento de la fibra óptica no se altera con condiciones
adversas en la atmósfera (truenos, lluvias, nubosidad, etc.), como sucede con el cobre y la
transmisión por ondas radiales.
11
Open Systems Interconnection (OSI) es una agencia de Ia International Standards Organization (ISO)..
12
Los niveles en un protocolo de comunicaciones no son más que conjuntos de programas que resuelven
tareas específicas, y que en su funcionamiento existen para atender las necesidades del nivel inmediato
superior, y se sirven de los servicios del nivel inmediato inferior. Por otra parte, cada nivel en uno de los
equipos se comunica virtualmente con su igual en el del otro equipo, cumpliendo un protocolo e ignorando
lo que pasa en los niveles inferiores. Con la aplicación de estos principios, el problema de la comunicación
entre computadoras se puede descomponer en tareas, que van desde lo más general que es atender a un
usuario, hasta lo más detallado que es generar o interpretar los pulsos eléctricos o luminiscentes
30
La década de los años 90 del pasado siglo fue testigo de la maduración y empleo masivo de un
grupo de tecnologías de computación y comunicaciones que se habían desarrollado en los 20 años
que le precedieron.
Siguiendo un pronóstico realizado a inicios de los años 70 por uno de los fundadores de INTEL
Gordon Moore (ver 12), conocido posteriormente como ley de Moore, la cantidad de transistores
que puede contener un microprocesador se había duplicado cada dos años, permitiendo que los
equipos de computación y en particular las computadoras personales pudieran aumentar su
potencia de cálculo y capacidad de almacenamiento a valores nunca antes imaginados.
En estos años 90 se produjo la instalación masiva de fibra óptica entre nodos de comunicación, a
nivel nacional e internacional. INTERNET que había comenzado a funcionar a principios de los 90,
creció desde 0 a 250 millones de usuarios en esta década.
También en estos años comienza el desarrollo masivo de la telefonía celular que, unida al resto de
las tecnologías ya descritas, cambiaría en poco tiempo la forma en que las personas se comunican
y trabajan.
Durante la primera década del presente siglo no han cesado los desarrollos tecnológicos que de
una u otra forma influyen en la evolución de los SAC. Los principales son:
 La integración de los SAC en los ERP. Este proceso que comenzó a mediados de los 80 del
pasado siglo se ha consolidado de forma definitiva en la primera década del siglo XXI. Hoy en
día es totalmente anacrónico hablar de un sistema automatizado de contabilidad,
independiente del sistema general de la empresa.
 La introducción del comercio electrónico, tanto en la modalidad entidad – entidad, como en

la de entidad – persona natural.
El comercio electrónico entre entidades facilita llegar al último nivel de automatización antes
descrito, al permitirle a sistemas automatizados interactuar entre ellos e intercambiar toda la
información requerida para sus registros, la gestión de carteras y la conciliación de cuentas.
Una forma particular de este comercio electrónico es la Banca a distancia, que permite
ordenar transacciones directamente desde el sistema automatizado de la entidad al banco, así
como recibir las notas de débito y crédito y los estados de cuenta de forma automática.
El comercio electrónico entidad – persona natural, además de facilitar la adquisición de bienes
y servicios por parte de las personas, elimina totalmente la necesidad de captar documentos
en esas transacciones, ya que la propia información requerida para realizar la operación
comercial es la fuente del registro contable.
 La tecnología web en los sistemas automatizados. La presencia universal de INTERNET y la
evolución de las tecnologías que le son propias, ha permitido que el acceso a los ERP, y como
parte de estos a los SAC, se haga más sencillo desde prácticamente cualquier localidad. Esta
posibilidad de acceso remoto a través de internet resuelve varios problemas de los SAC, en
particular la replicación de datos y programas, requerida para esquemas de varios niveles, y la
31
posibilidad de aumentar la seguridad del sistema al concentrarse los medios técnicos en un
solo punto.
 Un último desarrollo a nombrar, y no por ello el menos importante, es el uso masivo de la

tecnología de teléfonos celulares para acceder a los SAC.
Los actuales teléfonos inteligentes superan sin dudas la capacidad de procesamiento de las
primeras computadoras de la tercera generación. Las velocidades de transmisión de datos
entre estos teléfonos y los sistemas automatizados han venido creciendo sistemáticamente. La
tecnología de red Long Term Evolution (LTE), que utiliza el Iphone-5 de Appel, permite
velocidades de 300 Mbps desde la red hacia el teléfono y de 75 Mbps desde el teléfono hacia
la red. Estas capacidades permiten que el sistema pueda utilizarse en cualquier momento y en
cualquier lugar, algo que desafortunadamente atenta frecuentemente contra el equilibrio
psicológico del personal que las emplea.
4.7 El futuro inmediato

En cuanto al futuro, cualquier predicción corre el riesgo de no tomar en cuenta desarrollos no
divulgados masivamente que aún se encuentran en un estado embrionario, pero que pudieran
revolucionar los sistemas automatizados, como ha ocurrido con algunas tecnologías durante los
últimos 40 años.
Muchos analistas, e importantes firmas de equipos de computación y comunicaciones, así como
de software (ver 13, 14, 15, 16, 17 y 18) coinciden total o parcialmente, sin embargo, en que las
siguientes tecnologías marcarán el rumbo en el desarrollo de los próximos años:
 El así llamado procesamiento en la nube (cloud computing), que plantea que el tratamiento de
los datos se brinde como un servicio, al que se tiene acceso a través de Internet. Esta
alternativa apuesta por la total centralización, y en buena medida tercerización, de los
servicios informáticos, con lo que los usuarios particulares no dispondrán de un software que
se ejecute en su computadora, sino utilizando un explorador tendrán acceso a sitios Web
donde se pueda interactuar con los diferentes sistemas.
Así, no se tendría una versión del Office en la PC, sino que Microsoft brindará el uso de
servidores ubicados en cualquier lugar del mundo, que realizarán las mismas funciones.
Este esquema fue puesto en explotación en junio del 2011 por Microsoft, con el producto
Office 365.
De igual forma los sistemas ERP pudieran ejecutarse en servidores de la propia compañía que
desarrolló el software, y sólo se instalarían de forma particular en las compañías más
poderosas, que brindarían a sus empleados el uso de los mismos, también a través de
Internet.
32
Si bien esta alternativa promete ventajas considerables, los problemas de seguridad y
privacidad deberán resolverse de forma convincente, tanto desde el punto de vista
tecnológico como legal, antes de que esta sea una solución universal.
 El procesamiento en memoria (in memory computing) es otra de las tendencias que
potencialmente puede cambiar radicalmente la forma en que los sistemas automatizados
actuales trabajan. Los discos duros han sido durante décadas el principal soporte para el
procesamiento de grandes volúmenes de datos. La capacidad actual y la que se vislumbra para
las memorias electrónicas permiten que buena parte del procesamiento se realice
directamente sobre estas, sin la participación de los discos duros.
Muchos programas y en particular los sistemas de gestión de base de datos han basado sus
procedimientos en optimizar el uso de las características y restricciones de los discos duros.
Además del aumento de velocidad en la lectura de un dato, al eliminar las memorias
electrónicas el tiempo requerido para moverse de un dato a otro, no despreciable en los
discos duros, los algoritmos y procedimientos de estos programas deberán ser revisados y
rediseñados, y las posibilidades de los mismos podrán crecer exponencialmente.
 La movilidad es otra de las características que marcará el rumbo de los sistemas
automatizados de los próximos años.
Ya hoy en día existen unos 5000 millones de conexiones de celulares en el mundo y se

mantiene una alta tasa de crecimiento. Los teléfonos inteligentes tienen las mismas
capacidades de las PC de hace algunos años y las redes inalámbricas crecen por día en
velocidad y cubrimiento de área.
 Por último cabe señalar la explosión de datos como una de las características de los sistemas
automatizados de los próximos años.
Algunos analistas plantean que la cantidad de datos almacenados en los sistemas llegará a
duplicarse cada 18 meses. Este hecho, sin duda, propiciará el desarrollo de nuevos equipos
que soporten ese crecimiento y el perfeccionamiento de las tecnologías de minería de datos13,
(Data mining) imprescindibles para manejar eficientemente tales volúmenes (ver 24).
13
Se le llama minería de datos al proceso de analizar grandes volúmenes de datos desde distintas
perspectivas, interrelacionadas entre ellas, con el fin de resumirlos de una forma útil para la toma de
decisiones.
33
34
5 Componentes de los ERP o SAC
5.1 Los componentes

Los sistemas automatizados en general, y los ERP o SAC en particular, no pueden verse como un
conjunto de programas y procedimientos solamente. Para que un ERP o SAC funcione
correctamente tienen que acoplarse, y trabajar como un todo, un grupo de componentes de
características muy disímiles.
Ya en los años 80 algunas metodologías para el desarrollo de los sistemas automatizados de
procesamiento de datos (SAPD), definían a estos como un conjunto de subsistemas funcionales,
que resuelven las tareas como tal, y un conjunto de subsistemas de aseguramiento, que se
encargan de que los subsistemas funcionales trabajen adecuadamente (ver 33 y 35). Esta división
sigue teniendo total validez, y de hecho constituye un enfoque metodológico para introducir y
explotar un SAPD.
No obstante, con el objetivo de utilizar una fraseología más acorde con el argot actual, en lo
adelante se le utilizará la denominación de componentes de los ERP o SAC14, en sustitución del
término subsistemas de aseguramiento de aquel enfoque metodológico.
El cuadro 16 muestra un esquema con una agrupación generalmente aceptada de esos
componentes.
COMPONENTES DE LOS ERP o SAC
SEGURIDAD Y PROTECCIÓN
COMPU-
TADORAS
TELECOMU-
NICACIONES INFORMACIÓN
RECURSOS
HUMANOS
PROGRAMAS
INFORMÁTICOS
ORGANIZACIÓN
ASPECTOS
METODO- ASPECTOS
GICOS LEGALES
CUADRO 16
14
La agrupación de componentes utilizada en este trabajo difiere de la utilizada en los años 80 para los
subsistemas de aseguramiento en los siguientes aspectos: el aseguramiento técnico se separó en los
componentes computadoras y telecomunicaciones, el aseguramiento tecnológico, que se ocupaba de definir
la tecnología de trabajo de un centro de cálculos se elimina, ya que en su mayoría esas funciones o no
existen o se han automatizado.
35
5.2 Las computadoras
En la actualidad las computadoras requeridas para un ERP o SAC pueden agruparse en las
siguientes categorías:
 Servidores
 Puestos fijos de trabajo
 Equipos móviles
Los servidores no sólo ejecutan los programas principales de la aplicación como tal, sino que sirven
también para realizar servicios, sin los cuales el sistema no trabajaría adecuadamente. Los más
importantes de estos servicios son:
 Almacenamiento de respaldo (backup) de los datos.
 Gestión de la red de computadoras (controlador de dominio).
 Gestión del correo electrónico.
 Gestión de las bases de datos.
 Cortafuegos para proteger las conexiones externas.
 Hospedaje y suministro de servicios WEB.
Los puestos de trabajo que tienen acceso al sistema están constituidos en la actualidad por PCs
que están conectadas a la red de área local con acceso a los servicios del ERP o SAC y, en general,
pueden realizar otras tareas de oficina, como elaborar documentos, tablas de cálculo, acceder al
correo electrónico o a Internet, etc.
En ciertos ambientes, donde la información del sistema es confidencial o muy sensible, las PCs
conectadas al ERP o SAC no deben tener acceso a Internet, con el fin de proteger físicamente el
sistema de ataques externos desde esta red.
En los últimos años ha venido ganando cada vez más popularidad el acceso, a los sistemas
automatizados en general, y a los ERP o SAC en particular, desde equipos móviles.
Como ya se comentó anteriormente los actuales teléfonos inteligentes tienen capacidades de
memoria y procesamiento muy similares a las de las PCs.
El iPhone 5, anunciado por Apple en septiembre del 2012, tiene, por ejemplo, las siguientes
características en su versión más potente (ver 26):
 Pantalla de 4 pulgadas en la diagonal
 Memoria para datos de hasta 64 Gbytes
 Procesador A6 dual-core, con triple-core para gráficos
 1 Gbyte ram
 Cámara de 8 megapixels
 GPS (Global Position System) incluido
 Posibilidad de conexión a redes Wi-Fi, en particular a la red inalámbrica de transmisión de
datos LTE (Long Term Evolution), que tiene velocidades de 300 Mbps bajando datos desde la
red y 75 Mbps subiendo datos a la red
36
Por otra parte, encabezados por Apple, los fabricantes de computadoras han inundado el mercado
en los últimos años con las llamadas tabletas (tablets en inglés), que no son más que una pantalla
táctil15, un poco más pequeña que una hoja de papel normal de 8 ½” X 11”, con procesador,
memoria, cámara de televisión, en ocasiones disco duro, y acceso a redes inalámbricas.
El iPad de Apple tiene, en la versión disponible en el mercado en octubre del 2012, las siguientes
características (ver 27):
 Tamaño del equipo 7,31 x 9,5 x 0,37 pulgadas

 Pantalla de 9,7 pulgadas en la diagonal
 Procesador A5X dual-core, con quad-core para gráficos
 1 Gbyte ram
 Memoria para datos de hasta 64 Gbytes
 Cámara de 5 megapixels
 Posibilidad de conexión a redes Wi-Fi, incluyendo LTE
 Posibilidad de funcionar como un teléfono
Con estas capacidades, las únicas diferencias significativas actuales entre una PC y un teléfono
inteligente o una tableta, son: el teclado, que indiscutiblemente sigue siendo el medio más
productivo para la introducción masiva de información alfabética o numérica, y el tamaño de la
pantalla, que en ciertas aplicaciones requiere dimensiones, que por su carácter de portabilidad, no
se pueden alcanzar con las tecnologías hoy disponibles, para las tabletas y teléfonos inteligentes16.
Además de las computadoras en sí, al diseñar o perfeccionar un SAC, es necesario tener en cuenta
los requisitos sobre otros medios muebles e inmuebles, imprescindibles para que las
computadoras funcionen adecuadamente y que, por conveniencia, se incluyen en este acápite17.
Los más importantes son:
• Los equipos periféricos (impresoras, escáneres, lectores de códigos de barra, lectores de
tarjetas con bandas magnéticas, lectores de tarjetas inteligentes, equipos especiales de
medición18, etc.).
• Los armarios para los servidores. No es una excepción que el SAC o el ERP de una entidad
mediana o grande tenga que explotar decenas de servidores (y en algunos casos centenas),
15
Pantallas táctiles son aquellas que detectan los movimientos de los dedos sobre su superficie y los
interpretan de manera similar, aunque mucho más sofisticada, que los desplazamiento de un ratón en la
pantalla normal.
16
Existen investigaciones para el desarrollo de teclados virtuales que funcionan sobre cualquier superficie
con un haz luz láser y un escáner que detecta los movimientos de los dedos sobre las diferentes posiciones
del teclado. También se investiga sobre pantallas que puedan plegarse, de tal forma que sin perder el
carácter de portable puedan alcanzar, una vez desplegadas, los tamaños requeridos para las aplicaciones
más exigentes.
17
No se incluyen aquí los equipos de comunicación, que por su importancia se tratan de forma
independiente.
18
Los SAC o ERP que manejan la facturación de servicios públicos, como la electricidad, el gas y el agua
pueden tener como periféricos equipos especiales para medir mensualmente, casa a casa el consumo, y
después en un acceso a la red local, o por redes inalámbricas, transmitir la información al sistema central.
37
interconectados entre ellos y con los medios de comunicación, con actualizaciones bastante
frecuentes. El gestionar físicamente esas instalaciones de servidores (servers factories), sin los
muebles adecuados se puede convertir, y desafortunadamente se convierte con frecuencia, en
una maraña de cables impenetrable, origen de múltiples interrupciones.
• Los locales donde se instalarán los armarios de servidores tienen también que seleccionarse y
prepararse adecuadamente. Aun cuando con la tecnología actual no se requiere un monitor y
un teclado para cada servidor, sino que un monitor y un teclado puede conectarse a varios
servidores, el espacio para desplazarse en el local de los servidores, con el fin de sustituir o
incorporar nuevos equipos, debe ser lo suficientemente amplio para no provocar dificultades
en su gestión.
Por otra parte el acceso y las condiciones del ambiente (temperatura y humedad) en esos
locales tienen que tener un mínimo de control, con el fin de que no se produzcan
interrupciones indeseadas.
5.3 Las telecomunicaciones

Como ya se habrá podido apreciar, el tema de las telecomunicaciones es vital en los actuales ERP o
SAC.
El componente telecomunicaciones puede desglosarse en los siguientes elementos:
 Los enlaces entre locales en distintas ubicaciones geográficas
 Las redes de área local
 Los equipos que permiten que las redes se comuniquen entre ellas
 Los elementos de seguridad y protección
Los enlaces entre locales en distintas ubicaciones geográficas pueden ser propios, o
suministrados por una red pública de transmisión de datos (RPTD).
Los enlaces propios pueden ser la única opción en aplicaciones donde la protección de la
información sea de vital importancia. La utilización de RPTD tiene siempre un riesgo sobre la
confidencialidad de los datos que se transmiten y los posibles ataques desde el exterior19.
Cuando las distancias no son muy grandes, los puntos geográficos a conectar no son muchos, y el
grueso del tráfico es interno, la instalación de enlaces propios, ya sea con fibras ópticas, o con
transmisión por radio20, pueden representar una alternativa con ventajas económicas. Claro está,
estas ventajas económicas dependen en primer lugar de las tarifas que apliquen las compañías
que brinden los servicios de RPTD.
19
Existen equipos que permiten simular una red privada dentro de una red pública (VPN por su nombre en
inglés, virtual private network), pero su uso no es recomendable en aplicaciones de mucha importancia.
20
No se incluye la posibilidad de enlaces por cobre entre locales ya que, aunque posible, es muy vulnerable
a las descargas eléctricas de la atmósfera, causando no pocas averías cuando se producen.
38
La instalación de una red propia de datos entre locales debe tomar en cuenta, adicionalmente a
los costos de la inversión inicial, los costos de mantenimiento, que en muchos casos no son
despreciables.
En cualquiera de las dos alternativas, las características de los enlaces requeridos deben ser
determinadas y proyectadas para una perspectiva de no menos de 3 años.
Los parámetros fundamentales de los enlaces a distancia son:
Tipo de conexión: radio enlace, fibra óptica propia, línea de RPTD arrendada, que a su vez puede
ser: frame relay, dirección IP, transmisión de datos sobre líneas de celulares, etc. Cada uno de
estos tipos de conexión tiene sus ventajas, limitaciones y costos. El análisis para la selección de
uno de ellos debe basarse en los volúmenes, la frecuencia de uso, el tamaño de los paquetes, los
requisitos de confidencialidad y, obviamente, el presupuesto disponible.
El ancho de banda requerido es uno de los elementos que más frecuentemente se subvalora. Si el
sistema sólo transmite y recibe datos alfanuméricos, los requisitos no serán muy altos para las
tecnologías existentes en la actualidad. En cuanto se requiera transmitir imágenes o sonidos, el
ancho de banda necesario puede ser que tenga que multiplicarse al menos por 10.
Los protocolos de comunicación a emplear fueron en un momento tema de análisis y toma de
decisiones. En la actualidad con la presencia casi universal de TCP/IP, es poco probable que se
seleccione otra opción.
Por último en los enlaces a distancia debe revisarse con detenimiento los equipos a instalar en los
extremos (módems, enrutadores, etc.). Si el enlace se le contrata a una empresa proveedora del
servicio, las características de ese equipamiento y las responsabilidades de mantenimiento y
reparación, deben quedar claras en el contrato que se firme con esta. Si los equipos son propios,
debe preverse la existencia de repuestos suficientes para no tener que suspender el servicio por
mucho tiempo en casos de roturas.
Las redes de área local deben diseñarse cuidadosamente, sobre todo en el tendido de los cables.
Existen en la actualidad tecnologías de cableado estructurado, que facilitan la asimilación de los
cambios de ubicación física que frecuentemente se producen en un ambiente de oficinas.
Una buena práctica es proyectar el cableado de las redes de área local junto con las redes
requeridas para las conexiones de los teléfonos, de tal forma que no se duplique esa
infraestructura.
En los últimos años se han venido introduciendo, cada vez con más fuerza, las redes inalámbricas,
que eliminan todos los problemas que, con los movimientos físicos de los puestos de trabajo, se
crean con las redes con cables. El principal problema de las redes inalámbricas es el de la
protección de los datos, algo que con ese medio no tiene ni tendrá una solución definitiva.
39
Los equipos básicos de una red de área local son los concentradores, los conmutadores y los
puentes21 (hubs, switchs, y bridges respectivamente en inglés) y las tarjetas de red que se
conectan a las computadoras.
Los concentradores, conmutadores y puentes se conocen como equipos de nivel 2, porque
trabajan en el nivel de enlace (nivel 2 del modelo OSI).
Los concentradores son equipos a los que se conectan un grupo de computadoras, y permiten el
intercambio de información entre estas, al reenviar cada paquete que recibe a todas las demás.
Los concentradores se utilizan en redes que no tengan más de 16 computadoras conectadas entre
sí y que en general no requieran conectarse con otras.
Los conmutadores tienen básicamente las mismas funciones que los concentradores, pero realizan
su trabajo de una forma más eficiente, ya que mantienen actualizada una tabla con las direcciones
de todas las máquinas que se le conectan y cuando reciben un paquete para una de ellas no se lo
mandan a las restantes. Los conmutadores permiten normalmente la conexión entre varios de
ellos, para crear así redes de área local con cientos, o incluso miles, de puestos de trabajo (ver
cuadro 14).
Los puentes son equipos muy similares a los conmutadores, pero que se especializan en unir dos o
más redes entre ellas, funcionan básicamente utilizando software y están limitados a 16 puertos.
Las tarjetas de red vienen en la actualidad incluidas en la configuración de prácticamente todas las
computadoras personales, y en general no son ya tarjetas en sí, sino microprocesadores
especializados incorporados a la tarjeta madre de la computadora, o como parte de otros
microprocesadores.
En cuanto al protocolo a utilizar a nivel de red de área local, el de Ethernet, por su universalidad
no parece tener rival en estos momentos, aunque también se utiliza otro llamado Token Ring.
Las velocidades de transmisión a nivel del último segmento de la red son normalmente de 10 o
100 Mbps, aunque pueden ser de 1 Gbps. Los enlaces entre conmutadores deben tener como
mínimo una velocidad de 1 Gbps.
21
La La clasificación dada aquí para los equipos de redes es la clásica, algunos fabricantes suministran
modelos de equipos para redes que reúnen varias de las capacidades que en lo adelante se describen para
los equipos básicos, incluyendo los enrutadores explicados en el siguiente acápite.
40
RED DE ÁREA LOCAL
CONMUTADOR
LEYENDA
CONMUTADOR FIBRA ÓPTICA
UTP-6
PUESTO DE
TRABAJO
CONMUTADOR
Cuadro 14
El cable a utilizar para los enlaces entre las computadoras y los concentradores o conmutadores es
normalmente UTP-622, para los enlaces entre conmutadores se utiliza con mayor frecuencia fibra
óptica.
El largo del cable entre la computadora y el concentrador o conmutador está restringido a 100
metros. La fibra óptica para la conexión entre conmutadores puede alcanzar por lo general una
distancia de 400 metros.
Existe también la posibilidad de establecer una red de área local sin cableado, utilizando las ondas
de radio para el transporte de las señales, básicamente a través del protocolo Wi-Fi. Para
aplicaciones con ciertos requisitos de protección, esta alternativa no es recomendable como ya se
comentó anteriormente.
Los equipos que permiten que las redes se comuniquen entre ellas, son conocidos como
enrutadores, (routers en inglés).
Los enrutadores son equipos que trabajan en el nivel de red (nivel 3 del modelo OSI), y se ocupan
de enviar los paquetes que reciben a la red que corresponda (ver cuadro 15).
22
UTP (unshielded twisted par) es un cable no protegido que tiene 8 hilos trenzados de dos en dos. Existen
para varias categorías que definen sus características. En las redes actuales se utiliza mayormente la
categoría 6 (UTP-6).
41
RUTEADORES
CONMUTADOR
RED 1
RUTEADOR R1 LEYENDA
OTROS CONMUTADORES
Y PUESTOS DE TRABAJO RED 1 FIBRA ÓPTICA
INTERNET O
ENLACE EXTERNO
INTRANET
UTP-6
OTROS CONMUTADORES PUESTO DE

TRABAJO
Y PUESTOS DE TRABAJO RED 2
RUTEADOR R2
CONMUTADOR
RED 2
Cuadro 15
Para garantizar los enlaces entre redes, los enrutadores utilizan el protocolo IP, que es
prácticamente universal para este nivel en la actualidad, tanto en los accesos a nodos de Internet,
como en la interconexión de redes privadas, conocidas también como “intranets”.
El principal adelanto en la transmisión de datos se produjo cuando se pasó de conmutación de
circuitos a conmutación de paquetes.
En la conmutación de circuitos cada extremo debe estar unido por un enlace físico, que puede
tener n segmentos, y cada segmento con su tecnología (cable de cobre, fibra óptica, ondas de
radio), pero unidos físicamente durante todo el tiempo que dure la comunicación. La velocidad de
transmisión en este esquema depende del segmento con menor capacidad, y las capacidades de
cualquier otro segmento que sean superiores se subutilizan.
En la conmutación de paquetes, por el contrario, la información a transmitir, ya sean datos,
sonidos o imágenes, se divide en pedazos (paquetes) que se envían uno a uno a la red, y toman
por el camino que en ese momento esté disponible y sea más eficiente. Los paquetes así
transportados a su destino, son ensamblados nuevamente allí y se entregan al usuario como si
hubieran viajado juntos.
Los posibles caminos de un punto a otro en una red cuyos nodos tienen varias conexiones con
otros nodos, son múltiples, y utilizando algoritmos de enrutamiento dinámico sofisticados, se
puede optimizar tanto el camino de cada paquete, como el uso de las capacidades de los
diferentes enlaces.
Los enrutadores son computadoras especializadas que aplican esos algoritmos, por lo que tienen
que tener una gran potencia en nodos con muchos enlaces.
42
5.4 La información
La información constituye la materia prima, el principal activo fijo intangible, la herramienta, y el
producto final de todo ERP o SAC.
Como materia prima la información está contenida en formularios (en papel o electrónicos),
mensajes y ficheros que recibe el sistema.
Como producto final la información se materializa en reportes (también en papel o electrónicos),
en mensajes y en ficheros que entrega el sistema.
La documentación de todos los elementos del sistema representa la herramienta más utilizada en
su explotación.
Las bases de datos que se crean y actualizan, constituyen el principal activo fijo intangible que se
produce y utiliza con los ERP o SAC.
En los últimos años se ha introducido el concepto de almacén de datos (data warehouse), como
colecciones de bases de datos, que se actualizan de forma diferida, para apoyar la inteligencia
empresarial, a través de la así llamada minería de datos (data mining).
Todos estos elementos deben ser diseñados y actualizados con el debido cuidado. A continuación
se comentan algunos aspectos a tener en cuenta para cada uno de ellos.
Los formularios, tanto los que se imprimen en papel, como los que se llenan en la pantalla de una
computadora, deben diseñarse buscando que sean fáciles de completar, y que garanticen la
máxima calidad de los datos que se capten. Algunas reglas generales son:
• El orden de los campos debe seguir una secuencia lógica.
• Los nombres de los campos a llenar deben ser lo suficientemente explícitos para que no
surjan confusiones. Una explicación de cada campo en el propio formulario en papel, o la
posibilidad de acceder a una ayuda en el caso de las computadoras, pueden ser de gran
utilidad.
• Los campos deben tener el tamaño adecuado para que quepa toda la información que se
solicita.
• En los casos en que un campo solo pueda tomar el valor de algunas pocas alternativas, es
preferible enumerarlas y pedir que se marque la que corresponda. Esta posibilidad se
potencia cuando el formulario debe llenarse de forma electrónica, ya que se puede
mostrar una lista de nombres y captar el código asociado al que se seleccione. En este caso
debe cuidarse que la lista de elementos a seleccionar no sea demasiado grande y que, si el
que está completando el formulario conoce el valor a introducir, lo pueda hacer sin tener
que consultar la lista.
• La redundancia entre campos debe evitarse, ya que puede producir errores innecesarios.
Sólo cuando la redundancia se utilice para comprobar la validez de vario campos
introducidos manualmente, como es el caso de las cifras de cuadre, esta es aceptable. Así
43
por ejemplo, si se pide la fecha de nacimiento no hay porque solicitar la edad, o si se pide
un código de algún objeto registrado en el sistema, no hay porque solicitar su nombre.
• Debe quedar explícito que campos son de obligatorio cumplimiento y cuales son
opcionales.
• La fecha en que se capta la información y la persona que lo cumplimenta, debe aparecer
en todos los casos y ser de obligatorio llenado, en los formularios en papel. Cuando el
formulario se capta por una pantalla, la fecha del sistema y la identificación del operador
deben ser campos de la tabla donde se registren los datos del formulario.
• No deben solicitarse datos para los que su uso no está claro, mientras menos información
se pida, mejor será la calidad del proceso de captación.
• En los formularios que se captan por pantallas, la validación de los datos debe hacerse,
cuando sea posible, dato a dato. Los errores que se detecten deben informarse de
inmediato, con una explicación clara de la causa del error y permitirse su rectificación.
Además del formato del formulario, debe diseñarse su flujo, desde que se confecciona hasta que
se archiva. Para cada paso del flujo se deberá definir el responsable y las acciones a realizar sobre
el formulario.
El intercambio de mensajes entre sistemas automatizados es la forma más utilizada para procesar
transacciones que tienen que ver con más de un sistema.
Así, por ejemplo, si un cajero automático está procesando una solicitud de efectivo, le envía un
mensaje al ente autorizador, el cual trata el mensaje recibido como una transacción en sus
registros contables y envía la respuesta correspondiente. El cajero finalmente al recibir la
autorización (o rechazo) de la solicitud, completa la transacción solicitada por el cliente.
Los mensajes entre sistemas automatizados están altamente estandarizados. Para mensajes
financieros existe, por ejemplo, la norma ISO-8583, que define los mensajes a intercambiar en
transacciones financieras.
ANSI X12 y EDIFACT son otros ejemplos de normas sobre mensajes a intercambiar entre sistemas
automatizados, en este caso fundamentalmente para la gestión de abastecimientos de las
empresas, incluyendo la transportación de productos.
Los estándares para intercambio de mensajes deben definir para cada mensaje, entre otros
aspectos: las posibles respuestas, los códigos a emplear, los formatos de los campos, el alfabeto
admisible, los campos que son obligatorios y la forma de comprobar la integridad del mensaje.
Lamentablemente, a pesar de la estandarización existente, muchos sistemas automatizados, sobre
todo de entidades que tienen un amplio dominio de su mercado, tienen sus propios mensajes que,
frecuentemente, no son más que modificaciones de las normas existentes, pero que obligan a
particularizarlas para poderse conectar a ellos.
El diseño de los reportes debe hacerse con una activa participación de los usuarios finales de los
mismos.
44
Esto no quiere decir que se acepten, sin razonarlos, todos los detalles que se soliciten.
Frecuentemente, sobre todo cuando se está diseñando un nuevo sistema, los usuarios no tienen
toda la información sobre como cambiará su contenido de trabajo, y tienden a solicitar los mismos
reportes que utilizaban antes de existir el nuevo sistema, algo que en muchas ocasiones no es
necesario y en algunos casos puede ser incluso imposible.
Las sesiones de trabajo con los usuarios para definir los reportes deben utilizarse, por esta razón,
para que los diseñadores comprendan los detalles del trabajo específico de la entidad que se
automatiza, y los usuarios reciban información sobre las características del nuevo sistema.
La definición detallada de los reportes que deben emitirse, permite detectar errores de diseño en
el nuevo sistema, por lo que no debe dejarse para el último momento23.
El diseño final de los reportes va a depender en buena medida de las herramientas que estén
disponibles para su programación.
Algunas recomendaciones específicas para los reportes son las siguientes:
 La fecha de confección, el número de páginas y la persona que lo solicitó debe aparecer
siempre en el reporte.
 El final del reporte debe informarse explícitamente en la última página.
 Debe permitirse seleccionar el soporte en el que se emitirá el reporte que se solicita. En
general las alternativas son: pantalla, impresoras gráficas, impresoras de matriz de puntos,
tabla Excel, documento (Word o Pdf), XML.
 El reporte emitido en cualquiera de esos formatos, o los elementos que posibiliten su nueva
emisión, con los mismos datos originales, debe guardarse en la base de datos por un período,
con el fin de facilitar su reimpresión. Recuérdese que muchos reportes se hacen con una
fotografía instantánea de la base de datos, que momentos después puede haber cambiado.
 Cuando un mismo reporte puede emitirse para varios subconjuntos de datos, los criterios para
seleccionar el subconjunto que se desee, deben definirse como parte del diálogo que se
establezca para solicitarlo. Ejemplos: la definición de las fechas de inicio y fin para la emisión
de reportes sobre cierto período, la definición de uno, varios o todos los componentes de un
conjunto que forma parte de un reporte, etc.
 Si el conjunto de datos para emitir un reporte está vacío por cualquier razón, debe informarse
este hecho de forma explícita.
 Los reportes que se emiten en papel deben poder reimprimirse en cualquier intervalo de
páginas.
23
Algunas metodologías de diseño de sistemas parten de los reportes que se requieren, y definen “hacia
adentro” el resto de las características del nuevo sistema. Debido a que un nuevo sistema automatizado no
debe por lo general mimetizar el existente, sino realizar una verdadera reingeniería de los procesos, estas
metodologías son sólo válidas en casos muy particulares.
45
Los ficheros a intercambiar con otros sistemas están en muchos casos estandarizados, por lo que
no siempre es necesario su diseño.
A diferencia de los mensajes, que se utilizan normalmente para realizar, en tiempo real,
transacciones que involucran varios sistemas, el intercambio de ficheros se utiliza para enviar
conjuntos de datos que pueden ser tratados de forma diferida, como lotes.
Cuando el intercambio de ficheros enfrenta un caso particular, para el que no se tiene un
estándar, el diseño tiene que ser muy meticuloso, ya que se trata de una interacción entre
sistemas automatizados que, como ya se dijo, no admite improvisaciones.
Los códigos a emplear, los formatos de los campos, el alfabeto admisible, los campos que son
obligatorios y, en algunos casos, los lenguajes de programación que se utilizarán en ambos
extremos, deben definirse con precisión.
En todos los casos, el sistema que recibe un fichero deberá comprobar que las reglas acordadas en
su diseño se cumplen con exactitud, antes de proceder a su procesamiento.
El nombre de los ficheros, o algún campo de su contenido, debe permitir que se controle que no
se cometan errores de omisión o repetición de ficheros en su tratamiento.
La inclusión de campos redundantes con elementos de criptografía, que permitan controlar que no
se afectó la integridad del fichero, es una práctica saludable en el intercambio de estos.
Cuando la entrega del soporte que contiene los ficheros es manual, se deberá emitir un
comprobante escrito sobre su recepción que tenga suficiente información. Este comprobante
debe contener como mínimo, el nombre de quien lo entregó y de quien lo recibió, el nombre del
fichero, la fecha y hora en que se produce la entrega, y el propio campo que permite comprobar la
integridad del fichero comentado en el párrafo anterior.
A la documentación de todos los elementos del sistema debe prestársele la mayor atención.
Una buena documentación se caracteriza por ser exhaustiva, estar actualizada y ser de simple
utilización.
Todo elemento del ERP o SAC que no esté correctamente documentado, representa un riesgo
potencial para el correcto funcionamiento del mismo.
Los sistemas y sus elementos están sujetos a constantes actualizaciones, las mismas deben
reflejarse en la documentación correspondiente, o está última se volverá con el tiempo
inutilizable. Al personal que le da mantenimiento al sistema debe exigírsele que cumpla con este
requisito.
Lograr que una documentación sea simple es una tarea que requiere un gran esfuerzo. El
expresarse por escrito con claridad, y el poder de síntesis, no son de las cualidades más comunes
y, desafortunadamente, normalmente escasas en el personal de diseño y programación.
En entidades con gran complejidad y volúmenes, debe revisarse la posibilidad de especializar
personal en esta tarea, tanto para su confección, como para exigir la calidad de los documentos
que obligatoriamente tendrán que elaborar otros especialistas.
46
Las bases de datos como ya se dijo constituyen el principal activo fijo intangible de los ERP o SAC.
Para los ERP o SAC, por su carácter transaccional y de procesamiento de información altamente
estructurada, los sistemas de gestión de bases de datos que utilizan el modelo relacional (SGBDR)
son sin dudas la tecnología apropiada.
Una base de datos relacional (ver 28) está constituida por un conjunto de tablas, cada una con una
o varias columnas. Las tablas se pueblan con filas, cuya cantidad varía normalmente de forma
dinámica y, en un momento dado, puede ser cero.
El diseño de una base de datos es un trabajo que requiere, por una parte, una alta calificación
técnica en ese campo, y por otra, un profundo conocimiento de las organizaciones que serán
objeto de automatización.
El resultado final del diseño de una base de datos es un conjunto de tablas interrelacionadas.
Para cada tabla se deben definir las columnas que contiene, de ellas las que componen las llaves
primarias24 y externas; las relaciones con otras tablas y las reglas formales que deben cumplir
todas las filas.
En ciertos casos se pueden y deben definir, adicionalmente, las acciones a tomar cuando una tabla
se actualiza, ya sea insertando, modificando o eliminando una fila.
Existen herramientas para facilitar el diseño de las bases de datos, entre ellas, el modelo entidad
relación25 puede ser de gran utilidad para los ERP o SAC.
El modelo entidad relación fue propuesto por vez primera por Peter P. Chen en 1976 (ver 30),
brinda una metodología para definir la estructura de una base de datos y normalizarla (ver 31), y
cuenta con varias implementaciones en software para apoyar ese proceso.
El cuadro 17 muestra un esquema entidad relación de un subconjunto de tablas de la base de
datos del SABIC.
24
La llave primaria de una tabla está compuesta por el conjunto de columnas que identifican unívocamente
cada fila de la tabla. Por esta razón la combinación de valores de esas columnas no puede repetirse. Las
llaves externas son combinaciones de columnas que representan llaves primarias en otras tablas.
47
DIAGRAMA ENTIDAD – RELACIÓN DE LAS CUENTAS EN EL SABIC
0..n BANCOS
0..1
1 MONEDAS
1..n 0..n 0..n
PERSONAS 0..n 0..n CUENTAS 0..n
1..n 1..n
1
CUENTAS/
SUBCUENTAS
0..1
0..n CLIENTES
cuadro 17
En ese esquema los cuadros representan entidades, las líneas indican relaciones entre tablas y los
números en los extremos definen la cardinalidad de la relación.
Las relaciones persona – banco y persona – cliente significan que la persona es un empleado del
banco o del cliente en cuestión.
La relación persona – cuenta puede tener los significados de firmante o tramitador de una cuenta,
en su carácter de empleado de un cliente o de un banco, o de poseedor de cuentas para las
cuentas de personas naturales.
La cardinalidad 0..n que está al lado de la entidad bancos, en la relación personas – bancos,
significa que una persona no tiene porqué ser empleada de un banco, o que puede ser empleada
de n bancos al mismo tiempo, algo factible por ejemplo en empleados de bufetes que representan
a varios bancos al mismo tiempo.
Un posible diseño del caso presentado en el cuadro 17, en una base de dato relacional, pudiera ser
definir una tabla por cada entidad, que contenga los datos específicos de esa entidad y los que
precisen sus relaciones.
De hacerse así, habría que resolver el problema de cuantas columnas definir en la tabla personas
para registrar los bancos y clientes a los que pertenece y las cuentas que posee, ya que para cada
persona sólo debe existir una fila, si no se quiere repetir la información que está asociada a cada
una de ellas (nombre, número de identidad, dirección, etc.).
De forma similar, en las tablas clientes, bancos y cuentas, habría que definir la cantidad de
columnas que se reservarían para registrar las personas que se le asocian.
48
Como se podrá entender con facilidad, esta solución corre el riesgo de definir insuficientes
columnas para una relación, con el peligro de tener que modificar su estructura en un futuro; o
demasiadas columnas para cubrir este riesgo, con lo que se desperdiciaría bastante espacio de
almacenamiento26.
Este tipo de problemas tiene que abordarse como parte del diseño de las bases de datos, y es uno
de los que se resuelven con la así llamada normalización de la base de datos (ver recuadro).
NORMALIZACIÓN DE UNA BASE DE DATOS

Primera forma normal: Todas las filas de una tabla tienen que tener la misma cantidad de
columnas. Cada columna debe corresponderse con un solo atributo.
Segunda forma normal: Todos los campos que no son llave deben ser una función del campo llave.
Tercera forma normal: Ningún campo que no sea llave puede ser función de otro campo no llave.
Cuarta forma normal: Una fila no puede contener dos o más hechos independientes con múltiples
valores sobre una entidad.
Quinta forma normal: Un artículo no puede reconstruirse con varios tipos de artículos más
pequeños.
El cuadro 18 muestra una solución a esta dificultad. Como se puede apreciar en el mismo, se han
introducido 3 nuevas entidades, las personas por banco, las personas por cuenta y las personas
por cliente.
Con esta solución la cantidad de personas por banco, por ejemplo, serán 0 o n filas de la tabla
“personas por banco”, y en las tablas bancos y personas no tendrá que registrarse esa relación. Lo
mismo sucede con las tablas clientes y cuentas en su relación con la tabla de personas.
26
Con la tecnología actual el espacio que ocupen todas las columnas de una tabla debe reservarse en disco
para cada fila, contenga o no información.
49
DIAGRAMA ENTIDAD – RELACIÓN DE LAS CUENTAS EN EL SABIC
NORMALIZADO
1
BANCOS
0..n
0..1
PERSONAS
POR BANCO
0..n
1 MONEDAS
1 0..n 0..n
1 PERSONAS 0..n
PERSONAS CUENTAS
0..n POR CUENTA 1
1 1..n 0..n
CUENTAS/
0..n 1
SUBCUENTAS
PERSONAS
POR CLIENTE
0..n 0..1
1
CLIENTES
cuadro 18
En la actualidad existen múltiples SGBDR27, que garantizan el trabajo con transacciones y cumplen
con la prueba A.C.I.D. explicada en el capítulo 3 de este libro.
El lenguaje de manipulación de datos que se ha impuesto es el SQL (Structured Query Language),
sobre todo a partir de 1984 cuando IBM anunció que pondría en explotación una base de datos
relacional que lo utilizaba (ver 29).
A los diseños iniciales de los SGBDR se le han añadido en los últimos 30 años un grupo importante
de mejoras, que les han permitido apoyar la solución de problemas cada vez más complejos. De
ellas, la más abarcadora parece ser la inclusión de código como parte de la base de datos, bajo la
forma de funciones definidas por los usuarios, procedimientos almacenados y procedimientos,
llamados disparadores, que se ejecutan cuando se produce una actualización de la tabla (user
defined functions, stored procedures y triggers, en inglés).
La mayor parte de los ERP o SAC que existen en la actualidad tienen una estructura de la base de
datos previamente definida, que sólo admite ciertas extensiones para incorporar nuevas tablas o
campos a tablas existentes. La comprensión del diseño de esas bases de datos es de vital
importancia para la correcta implementación y mantenimiento de esos sistemas.
Los almacenes de datos han tenido en los últimos años una gran divulgación en los medios
especializados. Un almacén de datos no es más que una o varias bases de datos, que se
reestructuran con el objetivo de facilitar la búsqueda de información relevante para la toma de
decisiones.
27
Entre los SGBDR más utilizados en la actualidad se encuentran ORACLE, SQL-server y Progres, este último
de código abierto.
50
Recuérdese que una base de datos normal para un ERP o SAC, debe priorizar la facilidad de su
actualización en tiempo real en modo transaccional y la emisión de reportes periódicos ya
establecidos, por lo que su estructura no necesariamente facilita la obtención de informaciones
interrelacionada sobre ciertas entidades, que están contenidas en la base de datos.
Tómese por ejemplo una tabla histórica sobre los registros contables que se han producido en una
base de datos de un SAC. Esa tabla debe contener toda la información contable que se ha
generado desde que se implantó el sistema, incluyendo lo ocurrido en el tiempo, con cada cliente,
en cada centro de costo, o con cualquier otro criterio en el que se detalle la contabilidad en
cuestión.
La tabla existe en la base de datos, pero su acceso, con el fin de establecer relaciones y análisis
estadísticos sobre esos objetos y sus relaciones, no sería normalmente recomendable, debido a
que por razones de eficiencia esas tablas no incluyen muchos índices, ni se deben someter a
recuperaciones que consuman mucho tiempo, o produzcan un gran volumen de datos.
La solución idónea es crear un almacén de datos con esa y, eventualmente, otras tablas de la base
de datos del SAC, o de otros sistemas automatizados de la empresa, y estructurarlo de tal forma
que se facilite la recuperación de información para la toma de decisiones.
Los almacenes de datos no tienen obviamente que cumplir con los requisitos de actualización en
tiempo real en modo transaccional. Su actualización se realiza con una periodicidad nunca inferior
a un día, en procesos que corren de forma autónoma en los servidores, normalmente en horarios
de poca carga, y que pueden durar muchas horas.
La minería de datos abarca un conjunto de técnicas de exploración del contenido de los
almacenes de datos, para buscar correlaciones y patrones entre decenas de campos, con el fin de
elaborar información relevante para la toma de decisiones.
Estas técnicas permiten analizar los datos desde diferentes dimensiones o ángulos, categorizarlos,
y resumir las interrelaciones detectadas.
5.5 Los programas informáticos

Los programas informáticos que se requieren para el funcionamiento de un ERP o SAC pueden
agruparse en las siguientes categorías:
• Sistemas de explotación
• Sistemas de gestión de bases de datos relacionales (SGBDR)
• Programas del ERP o SAC
• Compiladores y otras herramientas de programación
• Otros programas utilitarios
Los ERP o SAC utilizan normalmente varios sistemas de explotación, especializados en el trabajo
de servidores, de puestos de trabajo, de equipos móviles y, eventualmente, de equipos de
comunicación.
51
Para los servidores y puestos de trabajo las opciones más utilizadas en la actualidad son Windows
y Linux. Ambos sistemas tienen sus ventajas y desventajas.
Windows tiene el aval de un gran número de programas con un alto nivel de prestaciones. Para los
ERP y SAC, el SGBDR SQL-server y el paquete de Office (Word, Excel, PowerPoint, Outlook,
InfoPath, etc.) son de gran utilidad y contienen lo más avanzado del mercado en sus
especialidades.
Windows es propiedad de Microsoft quien, al ser ese su negocio, exige el pago de licencias y no
publica el código fuente de sus programas.
El no poder conocer exactamente lo que ocurre dentro de esos programas y depender de las
decisiones de esa empresa, que persigue a toda costa aumentar sus ganancias totales, aun cuando
se afecte una parte de sus clientes, representan desventajas de esos programas.
Quizás la única ventaja que tiene el bloqueo económico de los Estados Unidos contra Cuba, es que
no se les paga las licencias por el uso del software. De hecho el software producido por empresas
de Estados Unidos no puede utilizarse en Cuba según las leyes de ese país. Sin embargo, los
canales de distribución del software para computadoras personales son tan amplios, que bloquear
su adquisición es prácticamente imposible.
El no tener acceso al código fuente del sistema de explotación y de los demás paquetes de
programas de Microsoft, le da a esa empresa una ventaja competitiva, a la hora de desarrollar
aplicaciones que los utilizan o se interrelacionan con ellos. La posibilidad de incluir en esos
programas rutinas que les permitan, a quienes las conozcan, entrar a las computadoras que los
utilizan de forma oculta es otra desventaja de los mismos.
Un ejemplo de la actitud de Microsoft de maximizar sus ganancias a toda costa, lo constituye el
abandono de VisualFoxpro como herramienta de desarrollo de aplicaciones, después de haberla
adquirido 5 o 6 años antes.
VisualFoxpro tenía una comunidad de usuarios nada despreciable en el campo de los ERP y SAC,
pero era una competencia directa de otros productos de Microsoft, por lo que lo descontinuaron.
Linux, que no es más que una versión de UNIX escrito nuevamente desde cero, con el fin de poder
publicar el código fuente, representa una buena alternativa y es el sistema de explotación que
encabeza el así llamado software libre28.
28
La corriente de software libre surgió con la Fundación de Software Libre (FSF por su nombre en inglés) y el
proyecto GNU a mediados de los 80 del pasado siglo. El principal objetivo de este proyecto era proveer un
conjunto de programas que permitieran realizar cualquier aplicación sin tener que utilizar programas cuyo
código fuente no era conocido. La idea original proclamaba cuatro libertades: la de estudiar el código
fuente, la de compartir el software con otras personas, la de modificar el comportamiento del software, y la
de publicar libremente el código modificado. GNU publicó posteriormente una licencia general pública (GPL
por su nombre en inglés). Esta licencia le da el derecho a los usuarios a utilizar, copiar, modificar y distribuir
los programas, mientras prohíbe imponer cualquier restricción sobre los que distribuyan. GPL se conoce
también como “copyleft” en contraposición al conocido copyright. En la actualidad existen múltiples
programas que utilizan la idea básica del software libre pero no son parte de la licencia GNU-GPL.
52
El módulo central (kernel en inglés) de Linux puede utilizarse en prácticamente todas las
computadoras, desde las supercomputadoras hasta los teléfonos inteligentes.
El servidor de servicios web más utilizado en el mundo (Apache) se programó inicialmente para
Linux.
Prácticamente todos los SGBDR importantes funcionan sobre Linux, y existen varios que también
tienen la filosofía del software libre.
El Open-ERP es un ERP completo que funciona bajo el esquema de software libre y corre bajo
Linux.
Los paquetes de programas del tipo de Office en software libre son, sin embargo, muy inferiores al
de Microsoft.
Las empresas que mantienen versiones de Linux en funcionamiento obtienen sus ingresos de
donaciones, fundamentalmente de gobiernos, y del cobro de servicios de consultoría asociados al
uso de ese sistema.
La discusión software libre contra propietario, a nivel de sistema de explotación de servidores y
puestos de trabajo no ha culminado. Las ventajas estratégicas del software libre parecen inclinar la
balanza a su favor. Sin embargo el nivel de negocio de software propietario es de tal magnitud que
las inversiones en ese campo han logrado, y pueden lograr en un futuro aun, productos que por
sus prestaciones sean los que se impongan.
En los equipos móviles la lucha entre Windows y versiones de Unix también existe, aunque en este
campo las versiones propietarias de Unix son más populares, debido fundamentalmente al
predominio de Apple y su sistema de explotación que se deriva de Unix.
Algo similar sucede con los sistemas de explotación de los equipos de comunicación, donde las
versiones propietarias que inicialmente desarrollaron los principales fabricantes de estos equipos,
se han venido sustituyendo por módulos centrales del tipo Unix.
En el campo de los SGBDR, aun cuando la lista de productos sobrepasa la centena, el mercado
para los ERP y SAC está bastante concentrado en 6 productos (ver 32).
Oracle
Microsoft SQL-Server
IBM DB2
Sybase
MySQL
PostgreSQL
Los cuatro primeros productos son totalmente propietarios y es necesario pagar por su licencia.
Las prestaciones de estos productos son bastante similares y, en general, cuando alguno saca una
nueva funcionalidad los demás la incluyen en sus versiones en pocos meses.
53
Oracle fue la primera empresa en comercializar SGBDR y mantiene un predominio en el mercado,
basado fundamentalmente en lo robusto de sus productos y el nivel de asistencia técnica que
brinda.
MySQL y PostgreSQL son del campo de software libre.
MySQL es un SGBDR pensado inicialmente para el desarrollo de aplicaciones en SQL. En la
actualidad ha crecido y contiene buena parte de las funcionalidades requeridas en un ERP o SAC.
Aunque Oracle compró hace un par de años los derechos de MySQL , hasta ahora ha respetado su
carácter se software libre y apoyado su desarrollo y utilización. Como negocio, Oracle se ha
concentrado en la venta de módulos que complementan las capacidades de MySQL.
PosgreSQL por su parte siempre ha sido de los SGBDR más potentes, goza de un buen prestigio en
su utilización para grandes bases de datos, y tiene una comunidad bastante amplia que soporta su
desarrollo y asistencia técnica. La versión actual de PostgreSQL es la 9.2 que incorpora
importantes funcionalidades.
Al igual que en los sistemas de explotación la discusión entre productos propietarios y de software
libre está aún abierta y puede ser que se mantenga en los próximos años.
Los programas del ERP o SAC pueden ser propietarios o de software libre. A la hora de seleccionar
un ERP o SAC es importante tener en cuenta los siguientes criterios:
 Las funcionalidades que se requieren. Muchos ERP o SAC funcionalidades que no siempre se
necesitan en una entidad determinada. Algunos las agrupan en módulos que se pueden
adquirir de forma independiente, otros obligan a adquirir la totalidad del sistema.
La adquisición del ERP o SAC debe partir en todos los casos de un análisis objetivo de los
requisitos y posibilidades de la entidad en cuestión.
 Correspondencia con la organización de la entidad. Algunos ERP o SAC se han diseñado a partir
de una organización determinada de la entidad donde se aplicarán. Este aspecto debe ser
revisado con cuidado, ya que si la estructura existente no es compatible con la pensada para el
sistema, y no se tienen intenciones de modificarla, los beneficios de su utilización pueden
disminuir considerablemente.
 Proceso de carga inicial del sistema. La carga inicial de un sistema es un proceso que requiere
un extraordinario esfuerzo, ya que la entidad donde se implantará el mismo, tiene que seguir
funcionando de forma estable durante el período de implantación. Algunos suministradores
de ERP o SAC se desentienden de este paso, y solicitan que se les entregue un conjunto de
datos formalizados según los requerimientos del nuevo sistema. Requerimientos de este tipo
deben rechazarse. La carga inicial debe hacerse con la participación de especialistas del nuevo
sistema y de la entidad donde se implantará. Este proceso debe utilizarse además como una
primera etapa de formación del personal.
 La prueba del sistema antes de su implantación debe planificarse de forma cuidadosa. Su

realización debe estar a cargo del personal más calificado de la entidad donde se implantará.
54
En entidades de una alta complejidad es normalmente imposible, o muy costoso, realizar una
etapa de implantación en paralelo, duplicando todo el trabajo. Por esta razón, deberá
garantizarse que, antes de la implantación, todos los módulos a utilizar hayan funcionado con
datos reales y en distintas condiciones.
 La formación del personal propio es otra de los requisitos que se deben exigir en un ERP o SAC.
En general se necesitará personal propio para la explotación, el mantenimiento y la ampliación
del sistema. Los perfiles de los técnicos correspondientes y su formación es particular en cada
caso.
 Los servicios postventa tienen que garantizarse desde el contrato inicial. El tiempo de
respuesta ante solicitudes de solución de errores, de consultas sobre la evolución del sistema,
y añadir funcionalidades debe quedar explícito en el contrato inicial. Las condiciones del
suministro de versiones posteriores debe también preverse desde un inicio.
Los ERP o SAC son sistemas con un ciclo de desarrollo que obliga a su constante mantenimiento.
Los Compiladores y otras herramientas de programación sirven a este fin. La selección de estos
productos está totalmente condicionada por las tecnologías utilizadas en los programas del propio
ERP o SAC.
Algunos ERP, como SAP, incluyen su propio lenguaje de programación y compiladores para apoyar
el mantenimiento del sistema. Otros facilitan el trabajo con funciones definidas por usuarios o
procedimientos catalogados de la base de datos, así como subrutinas que permiten realizar ciertas
tareas.
En todos los casos contar con un ambiente de prueba, que simule las condiciones reales de
ejecución, es de suma importancia.
Por último, para que un ERP o SAC funcionen adecuadamente es necesario contar con otros
programas utilitarios que complementan el trabajo del sistema.
Paquetes del tipo de Microsoft Office, con procesadores de textos, programas de comunicación y
tableros electrónicos, entre otros, son imprescindibles. El acoplamientos de estos programas con
el ERP o SAC debe garantizarse.
5.6 Los recursos humanos

Ningún ERP o SAC puede funcionar correctamente, sin que los recursos humanos de la entidad
donde se utiliza tengan el talento, la pericia, la disciplina y la organización requerida.
Estas cualidades del personal no se alcanzan de un día para otro, por lo que la cultura existente en
la entidad puede ayudar o entorpecer la introducción de un nuevo sistema, y optimizar sus
resultados o subutilizar sus potencialidades.
El talento, disciplina y organización de los recursos humanos de una entidad es el resultado de un
largo y constante proceso de selección, captación y adiestramiento, sobre el cual no se abundará
por no ser objeto de este libro.
55
La formación del personal en los requerimientos y características del nuevo sistema debe ser un
elemento de la mayor prioridad en su implantación.
Una buena fórmula para la formación del personal de utilización del nuevo sistema, en entidades
con varias sucursales o agencias que desarrollan el mismo trabajo, pero en regiones diferentes, es
poner en explotación inicialmente el sistema en una o varias de estas agencias o sucursales, y
rotar por esas al personal de las sucursales o agencias que lo utilizarán posteriormente.
La transmisión de información entre los propios usuarios del sistema durante su explotación, es
una de las vías más efectivas para que logren la pericia requerida.
Contar con aulas donde los futuros usuarios puedan interactuar con el sistema en condiciones
similares a las reales, auxiliados por instructores que los orienten y puedan despejar sus dudas, es
otra vía efectiva para el entrenamiento del personal que lo utilizará.
Para la formación del personal de diseño y programación, que se encargará posteriormente del
mantenimiento del ERP o SAC, la mejor alternativa es que participe en sus posibles adaptaciones y
en todo el proceso de carga inicial de los datos.
Obviamente, los cursos conceptuales sobre la arquitectura del sistema, la estructura de los datos,
las interfaces entre módulos y con otros sistemas y el contenido de la documentación, son
imprescindibles para el personal que se encargará de su mantenimiento.
Un último aspecto, pero quizás el más importante, sobre los recursos humanos de cara a un nuevo
ERP o SAC, es que la máxima dirección de la entidad debe estar totalmente involucrada en el
proceso de implantación del sistema, y exigir el riguroso cumplimiento del plan de trabajo que con
este fin se acuerde.
La tarea de implantación de un nuevo sistema es tan compleja, y tiene que superar normalmente
tantos obstáculos objetivos y subjetivos, que sólo con un plan correctamente elaborado y una
exigencia del máximo nivel sobre su cumplimiento es posible garantizarla en un tiempo razonable.
5.7 Los aspectos metodológicos

Los aspectos metodológicos incluyen tanto los procedimientos a tener en cuenta en el desarrollo,
mantenimiento y explotación de los ERP o SAC, como la definición detallada de los procesos a los
que se deben someter los datos que trata el sistema.
Existen múltiples enfoques metodológicos, y para cada uno de ellos varias metodologías para el
desarrollo e implantación de un nuevo ERP o SAC. La selección de la metodología a emplear con
este fin, va a depender básicamente del sistema que se pretenda desarrollar o implantar, de los
especialistas y demás recursos con que se cuente, y del grado de transformación de la entidad que
se pretenda alcanzar.
Ejemplos de procedimientos para el mantenimiento y explotación de un sistema, que deben
formar parte de su manual de explotación, son:
 Los pasos a dar para introducir una modificación al sistema, incluyendo los responsables de las
distintas tareas y los que las aprueban y revisan.
56
 Buena parte de las medidas de seguridad y protección de los datos y programas, reflejadas en
instrucciones que deben ser cumplidas por el personal que opera los servidores y que utiliza el
sistema.
 El procedimiento a utilizar para la sustitución de cualquier elemento que forme parte de las
computadoras o los medios de comunicación de un ERP o SAC.
 Los acciones a emprender ante errores en el funcionamiento del sistema, desde su detección,
hasta su total solución.
Con el aumento del nivel de automatización de los SAPD, muchos de los aspectos que
anteriormente tenían que describirse de forma detallada en los manuales de procedimientos, para
que se ejecutaran manualmente, han pasado a ejecutarse automáticamente, y los procedimientos
correspondientes están incorporados a los programas informáticos. La documentación de esos
programas debe incluir, de forma legible para los no informáticos, las decisiones del negocio que
se han incorporado a cada programa y su posible configuración.
Así, por ejemplo, cuando los sistemas no estaban automatizados, el manual de procedimientos
tenía que definir qué hacer cuando una cuenta de cliente en un banco se sobregira, si la operación
se debe aceptar o no, y, si se acepta, que interés cobrar por el importe sobregirado. En un sistema
automatizado todas estas opciones forman parte de los programas, por lo que su documentación
debe explicar que hacen y como particularizar cada caso.
La definición de los procesos a los que se someten los datos que trata el sistema, debe
concentrarse en los flujos de los documentos físicos que se reciben y emiten por el sistema, en las
diferentes alternativas que admite el tratamiento de los datos en el momento de su captación
manual, y en las alternativas para realizar diferentes procesamientos o emitir resultados. Todos
estos elementos deben incluirse en un manual del usuario del sistema.
5.8 Los aspectos legales

Los aspectos legales están constituidos por las leyes, los decretos, las resoluciones, los contratos, y
las reglas procesales existentes en el país y, en algunos casos, a nivel internacional, que atañen
directamente al funcionamiento del ERP o SAC.
Las disposiciones materializadas en leyes, decretos y resoluciones sobre los registros contables,
sobre el envío de información al fisco u a otros organismos que tengan autoridad para solicitarla,
sobre las medidas de seguridad y protección a incluir en el sistema, y sobre la fuerza laboral deben
revisarse en todos los casos con cuidado con el fin de cumplimentarlas, a la hora de elaborar e
implantar un ERP o SAC.
En los casos en que la entidad a automatizar realice operaciones de comercio internacional,
deberá revisarse la legislación vigente sobre los temas correspondientes. Esta legislación se
materializa mayoritariamente en reglamentos u acuerdos internacionales, a los que uno se
adhiere por voluntad propia, como el caso de las reglas y usos uniformes sobre las créditos
documentarios emitidas por la Cámara Internacional de Comercio.
57
Cada rama tiene adicionalmente instrumentos legales impuestos por entidades externas con la
autoridad requerida, o resoluciones de la propia entidad, que tienen que conocerse y tratarse
consecuentemente en el ERP o SAC.
Las resoluciones internas de la entidad deben revisarse con el fin de determinar si mantienen su
vigencia con el nuevo sistema, si deben ser modificadas, o incluso, si es necesario, emitir alguna
nueva para garantizar su correcto funcionamiento.
En cuanto a los contratos, es necesario conocer a tiempo el contenido de aquellos que pueden
tener incidencias en el diseño del sistema, tales como los contratos de cuentas corrientes con los
bancos o los contratos de comercio electrónico. El resto de los contratos con suministradores para
la procura de bienes o servidos, o con clientes para la venta de la producción de la entidad, deben
también ser estudiados, básicamente para garantizar que los formatos y períodos establecidos en
los mismos se cumplan adecuadamente por el ERP o SAC.
En los casos en que se requiera una certificación determinada para la explotación del sistema se
deberán tomar todas las medidas que se requieran para garantizar su obtención, o, si no es
posible de forma inmediata, solicitar una dispensa temporal y elaborar un plan detallado que lo
garantice en un tiempo prudencial.
5.9 La organización
La organización de una entidad se materializa en una estructura de mando de las áreas de trabajo
permanentes, y un conjunto de órganos colegiados que elaboran recomendaciones o toman
decisiones.
En general toda organización tiene al menos dos estructuras de mando: la que se presenta en los
organigramas y la que funciona en la vida real.
El funcionamiento de estructuras de mando, y con el tiempo la propia estructura, dependen en
buena medida de las características personales de quienes ocupan las distintas responsabilidades.
La estructura ideal, que no tiene en cuenta las características de las personas que la pondrán en
funcionamiento, presenta por lo general dificultades en su operatoria.
Debido a que las personas que ocupan los distintos puestos cambian con bastante frecuencia, con
el tiempo el funcionamiento real de una estructura se aleja de su diseño original.
Por otra parte, la mayoría de las entidades que utilizan o utilizarán un ERP o SAC, modifican en el
tiempo sus objetivos y funciones, y no siempre actualizan su organigrama, sino que quitan y
asignan funciones a unidades existentes, o crean unidades temporales o grupos de tarea que
funcionan frecuentemente por tiempo indefinido.
Conocer quien toma realmente las decisiones en cada área, es de vital importancia a la hora de
diseñar un nuevo sistema, con el fin de garantizar de forma dirigida su apoyo al nuevo proyecto, y
garantizar que sus expectativas sean cumplidas de forma racional con este.
Algunos ERP o SAC, y en particular el SAP, parten de una estructura general de la entidad a
automatizar, que debe cumplirse para que el sistema funcione adecuadamente. Este enfoque sólo
58
es válido para elementos estructurales muy generales, en entidades de producción de bienes o
servicios. En cualquier otro caso, adaptar la estructura organizativa a reglas que dicta el ERP o SAC
debe traer resultados desfavorables.
Los requerimientos de los órganos colegiados de una entidad, tanto de los que elaboran
recomendaciones, como de los que toman decisiones, deben tomarse en cuenta en el diseño del
nuevo sistema, sobre todo como consumidores importantes de la información que se procesa.
La periodicidad de las sesiones de esos órganos marca por lo general límites en el procesamiento
de las informaciones.
5.10 La seguridad y protección

La seguridad de un sistema puede definirse como el conjunto de medidas y medios que garantizan
su continuo funcionamiento, durante los períodos requeridos por la actividad de la entidad que lo
utiliza.
La seguridad tiene que ver básicamente con la robustez de los componentes que se seleccionen
para el trabajo y la posible redundancia que se introduzca.
La protección de un sistema abarca el conjunto de medidas y medios que garantizan que el
sistema y sus componentes no podrán ser utilizados, o alterados, por personas que no estén
debidamente autorizadas.
Aun cuando todos los componentes de un ERP o SAC tienen que ver de una u otra forma con las
medidas de seguridad y protección, en lo adelante se comentarán sólo las relacionadas con las
computadoras, las telecomunicaciones, la información y las personas, por ser los decisivos en
estos temas.
De forma general, hay que recordar que tanto la seguridad como la protección tienen que
analizarse desde una perspectiva de costo / beneficio, tomando en cuenta los aspectos financieros
y funcionales.
En un extremo un sistema sin protección ni seguridad puede ser el más barato y tener las mayores
funcionalidades, pero demasiado vulnerable ante los imprevistos y los ataques externos. En el otro
extremo el sistema más seguro y protegido puede costar mucho más que los fondos disponibles o
no ser nada funcional.29
Tanto para las computadoras como para las telecomunicaciones los elementos a tener en cuenta
en cuanto a la seguridad del sistema son los siguientes:
• El suministro ininterrumpido de energía, que debe preverse para los equipos de
telecomunicaciones, los servidores, las estaciones de trabajo, y los equipos vitales de
climatización.
29
Muchas de las dificultades que tienen que enfrentar en la actualidad los sistemas tienen que ver con su
carácter de trabajo en tiempo real e interconectado. Si estas funcionalidades se eliminan, indiscutiblemente
aumentarán las posibilidades de protección y seguridad, pero no se podrán resolver algunas tareas con igual
eficiencia.
59
Como se puede comprender fácilmente, garantizar un suministro de energía estable es
imprescindible en el caso de los equipos de telecomunicaciones, los servidores y sus locales.
En instalaciones de mucha importancia, es usual que exista un respaldo electrónico de energía
con la capacidad que requieran los servidores. Este respaldo electrónico garantiza que cuando
la corriente externa falle los servidores no se interrumpan. En esas instalaciones es también
usual que exista, adicionalmente, una planta eléctrica autónoma, que entra en
funcionamiento cuando el fallo del suministro externo es superior a cierto tiempo, siempre
menor que lo que pueden soportar los respaldos electrónicos. Estas plantas eléctricas
alimentan también a los equipos de telecomunicaciones y de climatización imprescindibles.
• Por muy robusto que sea un equipo siempre existe una probabilidad, mayor que cero, de que
en un momento determinado sufra una rotura. La instalación de equipos redundantes, que
puedan entrar en funcionamiento cuando se produce una rotura debe planificarse y
ejecutarse cuidadosamente.
Los equipos redundantes pueden sustituirse, cuando se rompen, en frio o en caliente.
Se considera que un equipo se sustituye en frio, cuando la tarea que venía realizando dentro
del sistema puede interrumpirse por un tiempo. Este es normalmente, por ejemplo, el caso de
las estaciones de trabajo, las impresoras, etc.
La sustitución en caliente de un equipo se realiza cuando el sistema tiene suficientes reservas
en funcionamiento del tipo de equipo en cuestión, para asimilar el trabajo del defectuoso,
hasta que se sustituya, sin que tenga que detenerse el funcionamiento del sistema.
Existen esquemas de almacenamiento de datos en discos duros redundantes, que permiten
seguir trabajando cuando uno de los discos se daña. Su sustitución y puesta en explotación se
realiza igualmente cuando se utilizan estos esquemas sin tener que detener el funcionamiento
del sistema.
Como se podrá comprender, la sustitución de un equipo en caliente requiere de un apoyo
importante de software, y provoca una baja de la confiabilidad del sistema en su conjunto,
durante el intervalo de tiempo que se requiere para la sustitución.
Con las posibilidades de las fibras ópticas, es posible tener en la actualidad dos instalaciones
de servidores que sean totalmente redundantes y que funcionen en paralelo en locales
distantes entre ellos, algo imprescindible si se requiere que el trabajo no se interrumpa aun
cuando se produzcan daños físicos de magnitud (terremoto, incendio, etc.) en una de las
instalaciones de servidores30.
30
Al igual que para las restantes medidas de seguridad, la decisión del nivel de redundancia de las
computadoras debe tomarse sobre una base de costo / beneficio. En instalaciones muy importantes, el
costo de una interrupción, ya sea en activos físicos o financieros, en bienes intangibles como el prestigio, o
incluso en vidas humanas, puede ser tan alto, que valga la pena invertir en los medios técnicos más
sofisticados que existan, para reducir al máximo la probabilidad de que ocurra. Tal puede ser el caso, por
ejemplo, de los sistemas que llevan el control de los vuelos en un aeropuerto, o de los servidores que
autorizan millones de transacciones bancarias en un día.
60
 Los conmutadores pueden y deben ser redundantes en redes locales de alta importancia, al
igual que los enrutadores.
 La seguridad de los enlaces con otros locales no es siempre simple de garantizar, sobre todo
cuando se utilizan los servicios de una RPTD. En redes de mucha importancia es necesario
exigirle a la empresa que suministra este servicio que las conexiones físicas, al menos del
último tramo sean distintas.31
En cuanto a la protección, las principales medidas a tomar, a nivel de medios técnicos, se
relacionan con la configuración de los enrutadores y los servidores especializados en funciones de
cortafuegos, y a nivel informativo y de programas, con todos los temas de autenticación de las
personas, definición de sus atribuciones y registro de trazas. A continuación se comentan.
 En los enrutadores y cortafuegos se toman medidas activas para prohibir la conexión desde y
hacia ciertos enlaces, o permitir la conexión sólo desde y hacia ciertos enlaces. Estos equipos
confeccionan bitácoras con todos los intentos de conexión y conexiones efectivas, que
permiten revisar a posteriori lo que pasó, con el fin de poder diseñar y tomar medidas para
que en un futuro no se repitan los accesos indeseados que se detecten en esas bitácoras.
 Cuando una máquina local tiene una conexión hacia el exterior, a través de un modem, ese
punto se convierte en un lugar de alta vulnerabilidad, ya que, en principio, se puede leer y
escribir desde una máquina de la red local en cualquiera de las otras a las que esté conectada
y, en ese caso, la conexión externa no pasa a través del enrutador ni del servidor que funcione
como cortafuego para poder filtrarla.
Otro elemento a considerar en la actualidad, es la alta capacidad de las memorias flash que,
sin tener que acceder desde el exterior a la red, pueden extraer grandes volúmenes de
información sensible, sin dejar muchas evidencias.
En sistemas que tengan que mantener una alta protección de los datos, es recomendable
deshabilitar toda posibilidad de acceder a los puestos de trabajo, adicional al teclado, el
mouse, el monitor y la red de área local.
 Un sistema automatizado tiene que ser capaz de autenticar una persona u otro sistema
automatizado. En la práctica también las personas tienen que autenticar personas y sistemas,
pero estos casos no se tratarán por apartarse de los objetivos de este trabajo.
 De forma general la autenticación de una persona en el marco de un sistema automatizado se

basa en las posibles combinaciones de:
o Algo que sabe
o Algo que tiene
o Algo que es
o Algo que hace
31
En las RPTD existen frecuentemente tramos que tienen una alta velocidad y que son únicos.
61
El principal ejemplo de algo que sabe la persona es el número de identificación personal o PIN,
por sus siglas en inglés, que se utiliza como clave de acceso. Las claves de acceso tienen el
atractivo de que no se requieren equipos especializados para su comprobación, cualquier
teclado sirve para ello, aunque si medidas de criptografía que permitan la gestión y seguridad
de las propias claves.
En general las claves pueden utilizarse para:
 Autenticar directamente al que la conoce

 Encriptar cierta información, utilizando la clave y un procedimiento
Las claves llevan una gestión, normalmente compleja, y al menos una de ellas, como se verá
en lo adelante, tiene que ser conocida sólo por su titular.
La seguridad del proceso de encriptación y/o autenticación no puede depender de que el
procedimiento que se emplee sea secreto. Por lo general estos procedimientos son públicos, o
su divulgación es muy difícil de evitar.
Las claves pueden ser sincrónicas o asincrónicas.
Las claves sincrónicas son aquellas que tienen el mismo valor en los dos extremos. Con las
claves sincrónicas ambas partes pueden encriptar datos y autenticarse mutuamente, pero por
su naturaleza la relación tiene que ser uno a uno.
Las claves asincrónicas se componen de una clave pública que, como su nombre lo indica, no
tiene que ser resguardada, y una clave privada que sólo la conoce su titular.
La clave pública sirve para encriptar datos, que sólo puede desencriptar el que posee la clave
privada, mientras que la clave privada sirve para encriptar datos que se pueden desencriptar
con la llave pública correspondiente.
La autenticación utilizando llaves asincrónicas puede realizarse, entre otros, a través de los
siguientes pasos:
 En un primer momento el que debe autenticar a una persona, una vez recibido su nombre,
le envía una cadena de caracteres totalmente aleatoria y única para esa sesión.
 El que desea autenticarse encripta la cadena de caracteres recibida con su llave privada y
se la manda al que está autenticando
 Por último, el que está autenticando comprueba que, al desencriptar la cadena recibida
con la llave pública del que se quiere autenticar, esta coincide con la cadena enviada
inicialmente.
Las claves asincrónicas soportan adecuadamente las relaciones varios a uno.
Otra acción que se puede realizar con las claves asincrónicas es la firma de un documento.
Para esto se realizan normalmente los siguientes pasos:
62
 Se calcula con una función hash32 una cadena de caracteres que caracterice el documento
en su totalidad con la fecha y hora en que se realiza la acción al final.
 Se encripta la cadena de caracteres obtenida en el paso anterior utilizando la clave privada

del que firma el documento.
 La cadena de caracteres así obtenida es única para el documento con esa fecha y esa hora,
y puede constituir por lo tanto una firma electrónica del mismo.
Existen procedimientos de encriptación y autenticación que involucran ambos tipos claves.
Sólo por citar un ejemplo, imagínese que una persona quiere recibir una información
encriptada y, obviamente autenticada, de alguien para el que sólo conoce la clave pública.
Para resolver esta necesidad, simplemente le envía una clave sincrónica a utilizar por una sola
vez en un mensaje encriptado con la clave pública, de tal forma que el receptor pueda
encriptar su mensaje con la clave recibida, debidamente firmado con su clave privada, y
enviárselo a quien lo solicitó, que será el único que podrá desencriptarlo.
Como se podrá haber apreciado con lo hasta aquí explicado sobre las claves para autenticar y
encriptar, el tema va mucho más allá de las aplicaciones comerciales en los ERP o SAC, por lo
que la mayoría de los Estados le dedican recursos humanos, de gran talento y calificación, para
estudiar y desarrollar procedimientos seguros y poder quebrar los procedimientos elaborados
por otros.
Las tarjetas con bandas magnéticas y las que tienen chip incorporado, son ejemplos de algo
que tiene la persona que se quiere autenticar. En este caso, como en los dos siguientes, el
sistema que autentica tiene que poseer un dispositivo especial que permita leer las tarjetas.
Cuando la autenticación de la persona se realiza por medios automatizados (no cara a cara), es
normal que la posesión del medio de autenticación tenga que complementarse con otro
elemento, por ejemplo un PIN.
El ADN, las huellas dactilares, la retina de los ojos, el tamaño de los huesos de la mano, o los
rasgos de la cara, son todas características únicas de cada persona, o sea, algo que es.
La firma, el sonido de la voz, o la cadencia de escritura en un teclado, son ejemplos de
acciones de las personas que pueden identificarlas por algo que hace.
Los equipos que comprueban las características de las personas (lo que son o lo que hacen)33,
tienen, al menos con la tecnología actual, una probabilidad de error, tanto para aceptar un
caso que no se debía aceptar (un positivo falso), como para rechazar un caso que debía ser
32
Las funciones hash suministran una cadena de caracteres, normalmente con un tamaño de entre 8 y 32
bytes, cuyo contenido varía para cualquier modificación de la cadena de caracteres, de cualquier tamaño,
que representa el documento al que se le aplica. El código cíclico redundante, CRC por sus iniciales en inglés,
es un ejemplo de una función hash.
33
Lo que aquí se afirma se refiere a la autenticación operativa, inmediata, que normalmente se realiza para
autorizar a una persona a utilizar ciertas funciones de un sistema, no a la forense, para la que se dispone de
un tiempo mucho mayor, de días o quizás semanas, y en la que en muchos casos se puede establecer la
identidad prácticamente sin errores.
63
aceptado (un negativo correcto). Normalmente para disminuir la probabilidad de los positivos
falsos es necesario aumentar la probabilidad de los negativos correctos, por lo que la
configuración del equipo debe hacerse en función de que es más importante en la aplicación
en cuestión.
 La autenticación entre sistemas automatizados debe realizarse normalmente en los dos

sentidos, ya que por lo general ambas partes deben estar seguras de con quien están
interactuando. Existen varios protocolos para la autenticación automática entre sistemas,
entre ellos:
 Kerberos
 Secure Socket Layer (SSL)
 IP SEC
En general todos estos protocolos utilizan varios intercambios de información entre los
sistemas que se están autenticando mutuamente y, en algunos casos como en el de Kerberos,
los servicios de servidores especializados en brindar claves temporales u otros servicios
criptográficos.
En las referencias bibliográficas 36 y 37 se encuentran breves descripciones de estos
protocolos y referencias a trabajos con explicaciones detalladas de los mismos.
Por último, aunque con la mayor importancia, es necesario tener en cuenta que los hombres, en
sus papeles de diseñadores, programadores, usuarios, administradores, etc., son siempre el
principal elemento dentro de los sistemas automatizados, y que para que estos funciones, hay que
otorgarles facultades que, unidas a su ingenio e imperfección en la acción, les permiten quebrar
en ciertas circunstancias prácticamente cualquier medida de seguridad o protección, de forma mal
intencionada o accidental.
Por estas razones, todo plan de seguridad y protección tiene que tener como uno de sus
principales componentes la selección, el adiestramiento y el continuo control del personal que
opera el sistema.
64
6 Clasificación y tipos de ERP o SAC
En algún momento de la vida profesional de un contador, un economista, o un informático, es

probable que tenga que participar en la selección de un ERP o SAC para una entidad determinada.
Un proceso de selección de este tipo requiere el análisis detallado de las alternativas disponibles
con el fin de contrastarlas con los requerimientos reales de la entidad, tomando en cuenta, claro
está, el presupuesto disponible.
El presente capítulo tiene por fin brindar una guía para la clasificación de los ERP o SAC, de tal
forma que la comparación con los requisitos de la entidad en cuestión pueda ser más objetiva.
Los ERP o SAC pueden clasificarse utilizando múltiples criterios. A continuación se agruparan los
criterios de clasificación de los SAC según:
 Sus características funcionales

 Los volúmenes que puedan procesar
 Las características del software utilizado para su desarrollo
6.1 Características Funcionales

Según las características funcionales del sistema los criterios de clasificación de los ERP o SAC
pueden ser:
 El conjunto de módulos funcionales que abarca. Prácticamente todos los ERP o SAC permiten
registrar contablemente cualquier operación, sobre la base de definir explícitamente todos los
asientos contables que la componen.
El principal aporte de estos sistemas es, sin embargo, la tipificación de operaciones de tal
forma que: en algunos casos se puedan ejecutar automáticamente, como por ejemplo el
cálculo de intereses y su cobro o pago, o que la captación de las transacciones
correspondientes sea sencilla y garantice que no se cometan errores formales.
Tanto la captación de las transacciones tipificadas, como los procesos que se ejecutan
automáticamente, y la captación de información de referencia requerida, se agrupan
normalmente en módulos, funcionales.
Una lista de módulos para el SAC de una empresa productiva normal, pudiera ser:
o Activos líquidos (depósitos en bancos y efectivo)
o Cuentas por cobrar
o Medios básicos
o Medios de rotación
o Cuentas por pagar
o Nómina
o Clientes
o Ingresos y egresos
o Tesorería
65
o Emisión de estados financieros
Si la selección tiene que hacerse de un ERP, a esa lista de módulos deben agregarse como
mínimo los siguientes:
o Recursos humanos
o Comercial
o Materiales (compra, inventarios, etc.)
o Producción (planificación, órdenes de producción o servicio, etc.)
o Mantenimiento
o Gestión de proyectos
La cantidad de módulos que tenga un ERP o SAC particular, y el alcance de cada uno de estos,
es una de las principales características a comparar con los requerimientos de la entidad, a la
hora de decidir una adquisición.
Los aspectos requeridos que no se cubran por el sistema seleccionado, tendrán que
ejecutarse, o por procedimientos no muy productivos, como el de registrar uno a uno todos
los asientos de una transacción con todos sus datos, como se señaló anteriormente, o por
otros sistemas que se acoplen al ERP o SAC seleccionado, lo que siempre implica esfuerzos y
costos adicionales.
Por otra parte, si el ERP o SAC seleccionado tiene módulos que no se requieren en la entidad
que lo selecciona, puede ser que se incurra en un gasto innecesario, y/o que se pierda
eficiencia a la hora de explotarlo.
 Desglose por moneda de los registros contables. En algunas entidades, en especial las del
sector financiero, es recomendable que los registros contables se realicen en la moneda real
en que se produce el hecho económico. Esta característica de los sistemas contables no es
muy común, por lo que, cuando se requiere, deberá investigarse a fondo la solución que le da
el ERP o SAC a seleccionar.
 Recepción de documentos primarios generados dentro de la entidad en soporte electrónico.
En el caso en que se esté analizando un SAC para la solución contable solamente, es necesario
tomar en cuenta que buena parte de los documentos primarios, que se reciben para realizar el
registro contable, se generan dentro de la propia entidad.
Permitir que los datos correspondientes lleguen al SAC en un formato electrónico, que se
produzca como subproducto de su confección primaria, puede ser de gran utilidad en ciertas
aplicaciones. De hecho esta es la solución que brindan los ERP.
 Interfaces con otros sistemas. Toda entidad tiene intercambios de datos con otras. Como se
explicó en el capítulo II, el mayor nivel de automatización se alcanza cuando el sistema de una
entidad puede interactuar con otros sistemas automatizados.
En particular una interface con el (los) banco(s) de la entidad es siempre importante. En la
medida que exista comercio electrónico, tanto entidad – entidad, como entidad – personas,
66
contar con las interfaces para apoyarlo puede ser un requisito decisivo a la hora de seleccionar
un ERP o SAC.
 Registros centralizados o descentralizados. En entidades con varios establecimientos surge

siempre la interrogante de cómo llevar el registro de los datos: de forma centralizada en un
solo lugar, o en cada uno de los establecimientos.
Cuando todo se llevaba a mano y en papeles, el registro en cada establecimiento era la única
alternativa viable en entidades que, como los bancos, requerían que los mayores, de al menos
algunas cuentas, estuvieran actualizados prácticamente de inmediato34.
El envío de documentos desde los establecimientos al centro para su registro, corre siempre
un peligro de extravío o excesiva demora, y tiene adicionalmente la desventaja que, si al
momento del registro se detecta alguna incoherencia, dilucidar su solución se hace complejo
por la no presencia del que lo confeccionó originalmente.
Como en general los establecimientos de una entidad tienen relaciones entre ellos, que deben
registrarse por el sistema, si el registro se lleva en cada establecimiento, es necesario
formalizar ese intercambio de información. Para los datos contables lo usual es establecer las
así llamadas cuentas de tránsito, que permiten registrar por partida doble toda transacción
inter-establecimiento en los dos extremos.
Las cuentas de tránsito deben obviamente irse a cero, en el momento que se consolidan los
balances, cuando el registro contable se realiza correctamente en los dos extremos. Cuando
los volúmenes de transacciones inter - establecimientos es muy grande y frecuente, es normal
que el consolidado de las cuentas de tránsito tengan un saldo. En esos casos, la conciliación de
las cuentas de tránsito se convierte en un problema de primera importancia.
Desde otro ángulo, la obtención de estados financieros de la entidad, así como de otras
informaciones operativas y estadísticas, se dificulta con la existencia de registros
descentralizados.
El tener el registro de los datos en cada establecimiento tiene, por último, consecuencias
negativas en los costos y en los temas de seguridad y protección del sistema en su conjunto.
Desde el punto de vista de costos, cuando el registro de los datos es descentralizado, se
necesita tener personal calificado y los medios técnicos requeridos en cada establecimiento.
En cuanto a la seguridad y protección, siempre será más sencillo y eficiente tomar todas las
medidas requeridas en un solo punto, que en varios.
Por lo hasta aquí expuesto, se podrá coincidir en que, con las posibilidades actuales de los
medios de computación y las comunicaciones, es siempre preferible evitar la descentralización
del registro de los datos.
34
El saldo de la cuenta de un cliente es una información imprescindible para decidir operativamente si una
extracción de efectivo pude autorizarse o no. Todos los registros que alteren ese saldo deben por lo tanto
realizarse lo antes posible.
67
La centralización de los registros, para que sea realmente efectiva, requiere que en cada
establecimiento existan módulos que permitan la interacción con el sistema central, tanto
para el registro de las operaciones, como para realizar las consultas que se requieran.
El problema técnico que tiene que enfrentar un sistema centralizado con muchos
establecimientos no debe menospreciarse. Las capacidades y estabilidad de los medios de
comunicación son aún, al menos en nuestro país, bajas, por lo que los sistemas tienen que
estar preparados para enfrentar interrupciones y optimizar las capacidades.
Por otra parte, cuando la gestión de los establecimientos depende del registro de los datos, es
necesario tomar medidas que permitan que continúen funcionando al menos parcialmente
cuando las comunicaciones se interrumpen.
En cuanto a los volúmenes a procesar, las pruebas de los sistemas que se quieren adquirir deben
hacerse siempre con las cargas máximas previsibles en un horizonte de no menos de 5 años.
Las capacidades de los medios técnicos crecen cada año y, en muchos casos, un aumento de la
carga de trabajo se puede compensar con equipos más potentes. Sin embargo, esto no siempre es
así.
Los picos de trabajo y los tiempos de respuesta necesarios deben ser considerados
cuidadosamente. En algunos casos existe un tiempo máximo de respuesta que, de sobrepasarse,
invalida la transacción.
El efecto de alcanzar el límite de la capacidad del sistema no siempre es el mismo. En ocasiones el
resultado puede ser solamente que las respuestas se demoren algo más, pero no es inusual que el
sistema en su conjunto colapse cuando se sobrepasan los límites de su capacidad.
Baste el ejemplo de los procesos que hay que realizar diariamente en el horario en que las oficinas
no trabajan. Para estas tareas se dispone normalmente, como máximo, de unas 14 horas (de 18:00
a 08:00 del otro día). Si por el crecimiento del volumen de los datos, estos procesos requieren 16
horas diarias, el sistema es totalmente inutilizable.
Las pruebas deben hacerse no sólo en las computadoras centrales, sino también en los canales de
comunicación con estas.
La saturación de las capacidades de los canales de comunicación, por su uso simultáneo en la
transmisión de datos del ERP o SAC como tal, del correo electrónico, y de navegación en Internet,
ocurre frecuentemente cuando alguien envía o recibe correos con anexos muy voluminosos, o
descarga ficheros muy pesados desde internet. En la medida que sea posible, los canales de
transmisión de datos para el ERP o SAC deben ser independientes de los de otras aplicaciones.
Al igual que para otros criterios de selección, los volúmenes que deba soportar el sistema,
teniendo en cuenta tanto el software como las computadoras y medios de comunicación, deben
ser lo más objetivos posibles, y la selección consecuente con los mismos.
El sobredimensionamiento de los medios siempre implica gastos innecesarios, mientras que
explotar un sistema en el límite de sus capacidades es correr un riesgo innecesario.
68
6.2 Características del software utilizado para el ERP o SAC
En cuanto a las características del software utilizado para el desarrollo del ERP o SAC los aspectos a
tener en cuenta son:
 El nivel de adaptabilidad
 La transparencia
 La arquitectura del sistema
 La plataforma de explotación
El nivel de adaptabilidad de los ERP o SAC va desde sistemas que son totalmente rígidos, que
obligan a que las estructuras y procedimientos se adapten a ellos, hasta los que se desarrollan a la
medida de la entidad, pasando por una amplia gama de sistemas que pueden configurarse y
ampliarse con el fin de asimilar características específicas de la entidad donde se utilizarán.
Sobre los sistemas rígidos y hechos a la medida no es necesario abundar. Como sus nombres lo
indican el grado de adaptabilidad es, o nulo, o total.
En cuanto a los que se pueden configurar y ampliar, las técnicas para su desarrollo son varias,
teniendo cada una ventajas y desventajas. A continuación se comentan las principales:
 Una primera alternativa de configurar un sistema, es la de contar con un conjunto de datos

sobre la aplicación particular (parámetros o metadatos), que permiten desarrollar módulos
generales que se particularizan con el uso de esos parámetros.
Así, por ejemplo, si una aplicación necesita varias tablas, compuestas todas por un código y
varios atributos que se asocian al mismo, se pueden definir las características de cada uno de
los campos de cada una de esas tablas en una tabla de parámetros. Esa tabla de parámetros
permitirá desarrollar programas generales para la captación, consulta y listado de todas las
tablas que estén descritas en ella.
De igual forma, si la captación de los datos primarios se hace a partir de formularios, se puede
crear un modelo genérico de un formulario, definiendo que siempre tienen un encabezado
que contiene X campos, junto con un cuerpo que contiene Y filas, cada una con Z campos. Los
parámetros del formulario describirían, además de las características formales de cada campo,
si estos son obligatorios o no, las interrelaciones entre ellos, etc.
Al igual que en el caso anterior, esos parámetros permitirían elaborar programas generales
para la captación, consulta, e impresión de los formularios.
La principal ventaja de esta técnica es que los programas generales son normalmente muy
estables y que las modificaciones al sistema pueden hacerse de forma bastante ágil. Su
principal limitación está dada por los propios modelos de objetos que deben definirse, que en
general se convierten en una restricción importante para la solución de ciertas tareas.
Esta alternativa se utiliza frecuentemente para el desarrollo de los módulos centrales de la
tercera alternativa de arquitectura, que más adelante se explica.
69
 Una segunda alternativa es, utilizando también parámetros o metadatos, generar de forma
automática programas específicos para cada objeto particular. Esta solución tiene
prácticamente las mismas ventajas y desventajas que la de los programas generales.
La principal diferencia es que facilita la inclusión de tratamientos específicos, a través de
permitir incorporar código en ciertas partes de los programas generados.
Esta solución tiene sin embargo la desventaja de que los programas generados, a los que se les
añade código, no suelen ser tan estables en su funcionamiento como los de la primera
alternativa, que prácticamente no se modifican.
 La tercera alternativa, normalmente utilizada en los actuales ERP o SAC, consiste en un

módulo central, que contiene la funcionalidad general del sistema, parametrizable en cierta
medida con el uso de metadatos, y herramientas para, si es necesario, desarrollar módulos
específicos.
Esta es, por ejemplo, la arquitectura del SAP, del OpenERP y del SABIC.
El módulo central de estos sistemas contiene la lógica que normalmente es invariable.
Por ejemplo, los asientos de una transacción tienen que cuadrar por cuentas reales y
nominales, y, si el registro de las contingencias es por partida doble, por cuentas contingentes.
Este cuadre tiene que cumplirse por fecha contable y fecha valor, y, por último, si el sistema es
multimoneda, el cuadre tiene que cumplirse también por cada una de ellas.
La lógica requerida para controlar que estos cuadres se cumplan y, cuando no se detectan
errores, registrar los asientos contables en las tablas que corresponda, se encuentra
normalmente como parte de ese módulo central de estos sistemas.
Los procedimientos para calcular y aplicar los intereses, las acciones a tomar cuando llega el
vencimiento de una cartera, o cuando llegan las fechas contables o fechas valor, de registros
que se hicieron con antelación, son también normalmente acciones que están programadas
como parte del módulo central de esos sistemas.
En cuanto a las herramientas para desarrollar nuevos módulos, SAP proporciona un lenguaje
de programación específico para ese sistema (ABAP/4), que permite tanto programar nuevas
tablas de salida, como implementar procedimientos para el cálculo de indicadores o la
validación de datos.
El OpenERP, se basa en Python como lenguaje de programación y se apoya en dos ambientes
de trabajo (frameworks): OpenObject y OpenERP para facilitar el desarrollo de nuevos
módulos y la ampliación de los existentes.
Aun cuando el OpenERP se basa en la filosofía de software libre, el código de los programas
que componen su módulo central puede revisarse y estudiarse, pero no debe modificarse.
Cualquier nueva funcionalidad o modificación de una existente, tiene que realizarse por la vía
de incorporar nuevo código.
70
Por su parte el SABIC, en su versión actual, se basa en VisualFoxpro como lenguaje de
programación, permite el uso de procedimientos catalogados en SQL, y proporciona un buen
número de funciones y subrutinas que facilitan el desarrollo de nuevas transacciones,
procesos independientes y reportes.
En todos los casos existen facilidades para la puesta a punto de los programas que se
desarrollen.
En cuanto a la transparencia, sólo los sistemas que se basan en los principios del software
libre son realmente transparentes, sin necesidad de tomar medidas adicionales.
Una de las condiciones que algunas empresas, normalmente muy poderosas, ponen para la
adquisición de un sistema, es que se entregue el código fuente de su módulo central,
obviamente con las debidas protecciones contractuales sobre no divulgación y uso indebido.
En la práctica, aun cuando no se tenga el código fuente del sistema a utilizar, la transparencia
del mismo puede suplirse con una adecuada documentación y un servicio eficiente de
consultoría para la solución de nuevas tareas.
La arquitectura del sistema juega un papel importante en aplicaciones para entidades con
muchos establecimientos.
Cuando la entidad radica en un solo local, la arquitectura cliente – servidor, que prácticamente
soportan todos los ERP o SAC modernos es suficiente.
Si la entidad cuenta con varios establecimientos, separados entre sí por distancias
importantes, es necesario revisar la arquitectura del sistema a seleccionar, y asegurarse que
funciona adecuadamente con las facilidades de comunicación y los medios técnicos con que se
contarán.
Las dos arquitecturas más utilizadas en la actualidad son las de puesto de trabajo (desktop), y
las aplicaciones WEB.
En las aplicaciones que funcionan en la arquitectura de puesto de trabajo, en la computadora
local debe residir una buena parte de los programas, fundamentalmente los que tienen que
ver con mostrar en pantalla los diferentes formularios y captar los datos. Esta arquitectura
simplifica por lo general el proceso de programación, pero tiene la dificultad de que es
necesario distribuir las nuevas versiones a todas las máquinas, y estas requieren algo más de
recursos.
En la arquitectura WEB, todos los procesos se realizan en los servidores centrales, y lo único
que funciona en las computadoras de los puestos de trabajo es un explorador de internet.
Aunque por lo general esta arquitectura requiere un mayor esfuerzo de programación, la
gestión de mantenimiento de todo el sistema se simplifica, y su utilización puede realizarse
desde cualquier equipo que tenga acceso a través de internet, o de una intranet, a los
servidores correspondientes.
71
Para los ERP o SAC la plataforma de explotación está compuesta por el sistema de explotación
y el sistema de gestión de bases de datos (SGBD).
Los sistemas más desarrollados, como el SAP, funcionan sobre múltiples sistemas de
explotación y SGBD.
Al analizar la adquisición de un ERP o SAC, la correcta selección del sistema de explotación y
del SGBD puede tener implicaciones importantes en los costos totales y la eficiencia del
sistema.
Las licencias de los sistemas de explotación y de los SGBD pueden llegar a ser una parte
importante de la inversión total, aunque para ambos casos existen alternativas que se
suministran como software libre.
La formación de los especialistas en la alternativa que finalmente se seleccione debe incluirse
en las acciones necesarias para la implantación del sistema. En este sentido, la experiencia
acumulada en el uso de determinado sistema de explotación y SGBD, puede inclinar la balanza
a la hora de seleccionarlos.
72
7 Principales características de los ERP
La principal diferencia entre los ERP y los SAC tradicionales es que el ERP representa una
plataforma única35 para la automatización de todas las actividades de una empresa, que permita el
uso óptimo de los recursos (fuerza de trabajo, materiales, recursos financieros y activos fijos),
diseñada con el objetivo de integrar la información que se produce en sus distintas áreas, y
garantizar una fuente única para cada dato.
En este contexto el SAC deja de ser un sistema en sí, para convertirse en una funcionalidad más
del ERP.
Antes de que surgieran los ERP, los sistemas automatizados de una empresa estaban constituidos
por subsistemas independientes, que manejaban sus bases de datos con criterios y codificaciones
propias y que buscaban optimizar los procesos y recursos del área en que se aplicaban.
En esas condiciones, el resultado total de la actividad de la empresa era normalmente la suma de

los resultados de sus partes, sin aprovechar la sinergia existente cuando esos subsistemas
interactúan de forma efectiva36.
La principal área de aplicación de los ERP son las empresas de producción de bienes o servicios,
aunque buena parte de sus módulos, y los principios que sustentan su arquitectura, pueden
emplearse también en entidades de otro tipo, tales como órganos de la administración pública,
universidades, hospitales, etc.
7.1 Principales módulos

Los ERP, para que sean catalogados como tales, deben tener módulos que apoyen como mínimo
las siguientes funciones de una empresa:
• Planificación de la producción
• Control de órdenes de producción o servicios
• Comercial
• Compra de materiales y partes
• Control de inventarios
• Mantenimiento
• Contabilidad y finanzas
• Gestión de las relaciones con los clientes
• Recursos humanos
35
Los ERP proponen una única base de datos, una sola aplicación y un interfaz con los usuarios uniforme
para todos los módulos.
36
De la física se conoce que el resultado de un sistema, solo es la suma de los resultados de sus partes, si
estas no interactúan entre sí. Cuando existe esa interacción entre sus elementos, el resultado final de todo
el sistema puede ser mayor o menor que la suma de los resultados de sus partes. La sinergia se obtiene
cuando la interacción de los elementos del sistema tiene por fin apoyar mutuamente su funcionamiento y
no entorpecerlo.
73
• Gestión de proyectos
Los módulos de planificación de la producción, control de órdenes de producción o servicios y
comercial son por lo general, específicos para las distintas ramas de la producción.
Los diferentes sectores de la economía (industria, agricultura, construcción, transporte,
comunicaciones, comercio) tienen características propias en su ciclo de producción. Incluso dentro
de un mismo sector, las características del proceso productivo y su comercialización pueden ser
muy disímiles en sus diferentes ramas.
Tómese por ejemplo el sector industrial, que abarca desde la producción de bienes como la
electricidad, que se distribuye de forma ininterrumpida a centenas de miles, o millones, de
clientes, para los que es necesario realizar una medición periódica (normalmente cada mes) del
consumo, facturarlo y cobrarlo; hasta la construcción de buques o aviones, que requiere un
proceso productivo que puede demorar meses, o años, para obtener una unidad del producto
para un solo cliente.
La planificación de la producción, su control y comercialización, deben ser obviamente específicas
para cada uno de esos tipos de industrias.
Los restantes módulos de un ERP tienen prácticamente las mismas funcionalidades en cualquier
empresa, y sus estructuras de datos, aunque obviamente particularizadas para el tipo de
producción de que se trate, son mu y similares.
7.2 Integración
La integración de la información de la empresa era, antes del surgimiento de los ERP, una tarea
muy compleja, sino imposible en no pocos casos.
Un mismo dato se captaba por los diferentes subsistemas, en ocasiones a partir de identificaciones
incompatibles y no siempre con igual valor, por lo que frecuentemente era extraordinariamente
complejo dilucidar qué información era realmente veraz.
Todos los objetos que trate el ERP deben tener una codificación única, independiente del módulo
que los utilice en un momento determinado. La identificación única de los objetos que trata el
sistema es un requisito imprescindible para la integración de los datos.
La fuente de cada dato debe ser también única. Una vez que se capta un dato primario, el mismo
debe utilizarse en tantos módulos como se requiera, sin tener que ser captado nuevamente.
Así, por ejemplo, la información sobre la salida de un material, de un almacén interno hacia un
área de producción de la empresa debe utilizarse en:
 La actualización del inventario correspondiente,
 La entrada en el módulo de control de órdenes de producción,
 El registro en la contabilidad analítica de la empresa,
 La estadística requerida por el módulo de compras de materiales y partes.
74
Ambos problemas: la integración de toda la información y la existencia de “una sola fuente de la
verdad”, deben quedar resueltos con la introducción de un ERP.
La utilización más efectiva de un ERP se logra cuando buena parte de los procesos, que se realizan
en la empresa de forma manual, pueden ser automatizados.
No debe perderse de vista, sin embargo, que la automatización de los procesos implica
normalmente una pérdida de flexibilidad en la operación de la empresa, y requiere de una gran
disciplina por parte de todos los involucrados.
La pérdida de flexibilidad se debe a que si el sistema tiene que tomar ciertas decisiones, todas las
alternativas posibles tienen que definirse previamente y ser incorporadas a los programas, por lo
que cuando se presenta una situación especial no prevista, que por métodos manuales puede ser
objeto de una tratamiento particular, o se ajusta a las variantes predefinidas o se modifica el
sistema, algo que en normalmente requiere tiempo y recursos, ambos escasos.
El aumento de la disciplina requerida se relaciona principalmente con la necesidad de reflejar en el
sistema, de forma inmediata y veraz, cualquier acción que se realice que afecte los datos
existentes. Así por ejemplo, si el consumo interno o venta de un material, no se refleja
inmediatamente en el sistema, se pueden aceptar solicitudes de producción para un plazo que,
teniendo en cuenta la situación real de los inventarios, no debieran aceptarse; o puede dejarse de
hacer un pedido de materiales, imprescindible para culminar las ordenes de producciones en
proceso.
Las interfaces con los usuarios deben tener en los ERP un diseño uniforme, que facilite el
aprendizaje sobre el uso del sistema y su mantenimiento.
Debido a la complejidad que entraña el diseño y desarrollo de un ERP, la regla es que las empresas
no tengan la experiencia ni los recursos requeridos para elaborar uno propio, por lo que en
general deberán escoger alguna de las versiones que estén disponibles en el mercado e
implantarla.
Aunque en teoría es posible utilizar módulos de diferentes ERP para resolver distintas
funcionalidades, este camino no es recomendable, al menos con el actual estado del arte37.
La integración de módulos de diferentes ERP puede ser tan compleja como la integración de los
sistemas independientes que existían antes de los ERP.
7.3 Otras características

Además de lo hasta aquí descrito, un ERP debe poseer las siguientes características:
 Apoyar los procesos de decisión y planificación estratégicos y operativos
37
En algunas actividades, como la bancaria por ejemplo, se desarrollan esfuerzos tendientes a estandarizar
de forma conceptual las estructuras y funciones de sus entidades, de tal forma que en los niveles operativos
existan servicios estandarizados, que puedan ser objeto de automatización por diferentes suministradores
de software sin perder la capacidad de integrarse con los restantes servicios. Ver 39, Banking Industry
Architecture Network (BIAN).
75
 Apoyar la ejecución de las tareas y su control
 Flexible
 Modular
 Abierto
 Abarcador
 Incluir las mejores prácticas de la rama
 Multiplataforma, multimoneda, multientidad
 En el plano tecnológico: transaccional, en tiempo real, en línea y desde equipos móviles
Los procesos de decisión y planificación estratégica de una empresa tienen que ver,
fundamentalmente, con los pronósticos sobre el mercado de su cartera de productos o servicios,
y con el análisis de las capacidades y su renovación y ampliación, a través de procesos
inversionistas.
Una parte de este trabajo debe ser realizado por especialistas que se nutren de experiencias e
información que no está en el sistema, tales como: los planes, fortalezas y vulnerabilidades de los
posibles competidores; las nuevas tecnologías para el proceso productivo; y el desarrollo de
nuevos productos o servicios que pueden sustituir los de la cartera de la empresa.
Los ERP deben ser capaces de complementar esa información con datos objetivos sobre: cuellos
de botella en el proceso productivo, clientes confirmados para los productos y servicios de la
empresa y demandas previsibles, potenciales clientes, pronósticos de precios para los insumos y
los resultados de la producción, costos marginales para incrementos y decrementos de la
producción de ciertos productos, etc.
Por su característica integradora, un ERP cuenta con todos los elementos para facilitar la
ejecución de las órdenes de producción de manera eficiente y deja en sus bases de datos todos
los elementos requeridos para monitorear y controlar el buen funcionamiento de los procesos.
Una empresa es un ente con vida propia, que requiere ajustar constantemente su forma de actuar,
tanto debido a cambios en su medio ambiente, como a innovaciones propias de los procesos
productivos. Esta característica de las empresas obliga a que los ERP sean lo suficientemente
flexibles como para adaptarse a esas nuevas condiciones.
El concepto de modularidad de los ERP está asociado a la posibilidad de utilizar un mismo sistema
en ambientes disímiles. Anteriormente se explicaban las enormes diferencias existentes en las
características de diferentes ramas de producción. Si los ERP se diseñaran e implantaran como
trajes hechos totalmente a la medida, habría que rehacer todo el trabajo para cada aplicación. La
división del sistema en módulos que son capaces de interactuar entre ellos, junto con la
posibilidad de configurarlos en cada caso, permite seleccionar la composición adecuada de estos
para cada aplicación, sin tener que rehacer todo el trabajo.
Cada vez con mayor frecuencia los ERP de las empresas tienen que interactuar con sistemas de
otras entidades con las que esta se relaciona. La característica de abierto es la que le permite al
ERP adaptarse a las diferentes interfaces de esos sistemas. Como ya se explicó, el desarrollo en
76
este ámbito pasa por la elaboración y aceptación de estándares para las diferentes interfaces y el
surgimiento de entidades que sirvan de pasarelas para los mensajes correspondientes.
Para que las ventajas de los ERP puedan materializarse, los mismos deben abarcar la totalidad de
las actividades de una empresa, ya que como norma existen interrelaciones entre estas que, de no
formar parte del sistema pueden distorsionar sus resultados.
Los ERP representan una oportunidad única para incluir las mejores prácticas de la rama, lo cual
no quiere decir que en todos los casos lo hagan. El tema de utilizar las mejores prácticas se enlaza
con la voluntad de modificar no sólo el sistema de procesamiento de datos, sino también, y quizás
en primer plano, los procedimientos existentes en una empresa. Este tema y sus consecuencias se
comentarán más adelante cuando se revisen los retos que debe enfrentar la implantación de un
ERP.
Debido a que por las razones explicadas, los ERP no se construyen para una aplicación
determinada, sino para múltiples ambientes, el prefijo “multi” está presente en varias de sus
características.
Con el fin de no obligar a la dependencia de un solo suministrador de equipos y sistemas de
explotación o de gestión de bases de datos, el sistema debe ser multiplataforma. Esta
característica permite utilizar de la forma más racional posible no sólo los recursos financieros
requeridos para la adquisición de esos elementos, sino también la cultura informática existente en
la entidad.
En el mundo actual las operaciones internacionales son muy frecuentes, y en ciertos ambientes
como el de Cuba sin tener operaciones de comercio exterior, las empresas tienen que trabajar su
contabilidad con más de una moneda. El tratamiento multimoneda que le dé el ERP a toda la
información financiera es en este contexto de vital importancia.
La existencia de organizaciones económicas que abarquen varias empresas, cada una con
personalidad jurídica propia, es común en el mundo y también en nuestro país. La característica de
multientidad es la que le permite a los ERP trabajar en cada una de esas empresas y brindar
información consolidada sobre el total de las mismas.
En el plano tecnológico la mejor definición de las características de un ERP es que contenga las
tecnologías más avanzadas del momento para resolver sus tareas. Este como se comprenderá, es
un blanco móvil, que cambia constantemente.
Con el desarrollo tecnológico actual puede afirmarse que los ERP tienen que ser como mínimo
transaccionales y funcionar en tiempo real y en línea. El apoyo al acceso al sistema desde equipos
móviles es otra característica tecnológica, que ya en las condiciones actuales de las redes de
telefonía inalámbricas, debe ser tomada en cuenta a la hora de seleccionar un ERP.
7.4 La selección e implantación de un ERP, los riesgos

La implantación de un ERP no es un proceso fácil. Puede afirmarse que sin excepciones el proyecto
correspondiente tropezará con obstáculos de gran magnitud durante su ejecución.
77
Para facilitar ese proceso es importante cumplir los siguientes pasos:
 Definir las necesidades reales de la entidad, partiendo de una proyección a mediano plazo de
su actividad y un análisis crítico sobre los procesos de la empresa y las posibilidades de su
entorno.
 Seleccionar un fabricante de ERP con suficiente aval de casos exitosos, módulos que se ajusten
lo más posible a las necesidades de la entidad, y capacidad para asesorar en el proceso de
implantación, explotación y mantenimiento.
 Definir las modificaciones a realizar en los procesos existentes (reingeniería de procesos), con
el fin de obtener los mejores resultados con la implantación del nuevo sistema.
 Elaborar un plan detallado de actividades para la implantación del sistema, que incluya:
o La adquisición e instalación del equipamiento y los medios de comunicación
requeridos por el sistema.
o La adquisición de los sistemas de explotación, sistemas de gestión de bases de datos,
cortafuegos y demás software general a utilizar en el nuevo sistema.
o La formación del personal para atender los nuevos equipos y software.
o La prueba del sistema en condiciones lo más cercanas posible a la futura realidad.
o La introducción de los posibles cambios organizativos y de procesos en
correspondencia con la utilización de los diferentes módulos del sistema.
o La formación del personal que utilizará el sistema, incluyendo los niveles gerenciales.
o La revisión y posible modificación de resoluciones y otros instrumentos legales
vigentes para la entidad.
o La elaboración de los nuevos procedimientos.
o La preparación de toda la información requerida para la carga inicial.
 Definir responsables a nivel ejecutivo para cada una de estas actividades.
 Controlar al mayor nivel de dirección de la entidad el cumplimiento de los planes elaborados,
tomando las medidas que se requieran en cada momento.
Garantizar que la implantación del sistema en el menor tiempo posible, sea un objetivo del mayor
nivel de dirección de la entidad, que se involucre en la gestión de los riesgos previsibles y ocultos,
es algo cuya importancia nunca podrá exagerarse.
Por muy bien concebido que esté el plan de trabajo, por muy racionales que sean los objetivos que
se persiguen, y por muy eficiente que sea el sistema a implantar, los procesos de este tipo chocan
siempre con un enemigo invisible: el miedo al cambio.
Este miedo al cambio tiene raíces objetivas, ya que las personas que trabajan en la entidad que ha
decidido implantar un ERP, estarán expuestas a riesgos reales.
En muchos casos, puestos de trabajo tradicionales dejarán de ser necesarios, en otros, el
contenido de ciertas ocupaciones cambiará radicalmente, y será necesario desarrollar habilidades
que hasta el momento no se requerían.
78
Por último, y no por esto con menor importancia, en la medida que el sistema elimine las barreras
tradicionalmente existentes entre elementos estructurales de una organización, y que la toma de
decisiones sea más transparente, y muchas de ellas totalmente automatizadas, el protagonismo
de la figura del gerente intermedio disminuirá.
Los cambios estructurales y de contenido de trabajo, provocados por la reingeniería de los
procesos y la aplicación de las mejores prácticas, no son los únicos riesgos que deben manejarse
con la implementación de un ERP.
Otros riesgos, más visibles y previsibles, pero no menos importantes de gestionar son:
 Concentración de puntos de fallo. Un viejo proverbio dice que no se deben poner todos los
huevos en una sola canasta. Por definición un ERP es un único sistema, con una única base de
datos y que abarca toda la actividad de la empresa. Para gestionar este riesgo evidente, deben
preverse las siguientes medidas:
o El sistema se deberá probar de forma exhaustiva y en condiciones extremas antes de
su implantación, con el fin de garantizar que durante la explotación del mismo no se
produzcan interrupciones imprevistas, ni que colapse por sobrecargas en los
diferentes elementos.
o Debe preverse la necesaria redundancia en los medios técnicos y de comunicación,
con el fin de garantizar la continuidad del funcionamiento del sistema y/o minimizar
los tiempos de interrupción por roturas en los mismos. En casos extremos deberá
duplicarse en localidades distintas los servidores que mantienen la vitalidad del
sistema.
o La información que procesa el sistema debe contar con un sistema de salvas, que
permita su recuperación en los plazos que racionalmente exija el sistema.
Como ya se comentó, todas estas medidas de seguridad deben decidirse desde una
perspectiva de costo beneficio, por lo que el elemento gestión cobra un significado especial.
La labor de los especialistas en informática es en este sentido de la mayor importancia, su
apreciación objetiva de la dimensión del riesgo, y su explicación en términos comprensibles
por parte de los directivos, es decisiva a la hora de tomar las decisiones finales.
 Múltiples vías de acceso a la información del sistema. Por su carácter de trabajo en línea, los
datos y las funcionalidades del sistema pueden ser utilizados desde diferentes puestos de
trabajo, incluso en algunos casos desde cualquier computadora conectada a Internet. Esta
realidad exige que las medidas de protección sean realmente eficiente y sean implantadas con
el mayor rigor.
 Por último repetir algo ya comentado, la necesidad de que todos los trabajadores que
interactúan con el ERP tengan una gran disciplina. Este es otro de los elementos que sólo con
una participación comprometida y consciente del mayor nivel de dirección de la entidad
puede garantizarse.
79
80
8 Principales ERP o SAC en uso
8.1 SABIC
8.1.1 Aspectos históricos y principales características del SABIC

Los antecedentes del sistema SABIC se remontan al año 1985. A partir de ese momento se crea en
el entonces Banco Nacional de Cuba (BNC) un equipo de especialistas que, con conocimientos
sobre la programación de las computadoras y de la actividad bancaria, comienzan a realizar tareas
para sustituir con PCs los equipos de saldo directo que todavía funcionaban las sucursales, y las
grandes computadoras del SUMCE38, demasiado costosas y obsoletas, que existían en las oficinas
centrales.
Los principales trabajos que se realizaron en esta etapa fueron:
• Desarrollo de un sistema sobre una PC para sustituir equipos de saldo directo que aun
funcionaban, y eliminar el registro manual del diario y el mayor. Implantado en la mayoría de
las sucursales del BNC.
• Concepción, diseño y programación de un sistema parametrizado para el registro local de las
transacciones de la Sucursal Especial de Operaciones Internacionales (SEOI) del BNC, utilizando
PCs. Este sistema permitía contar con los datos requeridos para la gestión operativa de los
departamentos de la SEOI, y alimentaba en soportes magnéticos el sistema central de
contabilidad. Se implantó en todos los departamentos.
• Desarrollo e implantación de un sistema, que utilizaba PCs e impresoras rápidas, para la
contabilidad central de la SEOI, la que hasta ese momento se procesaba en una EC-1040 del
SUMCE.
• Elaboración de un software, utilizando PCs con MS-DOS39, para conectar al BNC a la red
bancaria internacional SWIFT. El BNC pertenecía a la red de SWIFT desde 1989, pero no podía
transmitir ni recibir mensajes porque el equipamiento y el software necesario tenían
componentes fabricados en EEUU que, por el bloqueo, no podían ser vendidos a Cuba. Este
software fue certificado por SWIFT en 1991 y comenzó a funcionar en el BNC en ese mismo
año.
En 1993 se decide crear el Banco Internacional de Comercio (BICSA), como banco comercial para
exportaciones, importaciones y operaciones domésticas en divisas; que debía funcionar con
procedimientos similares a bancos de su tipo en el mundo.
38
SUMCE Sistema Uniforme de Máquinas Computadoras Electrónicas. Línea de equipos desarrollados por el
campo socialista compatibles con las IBM 360 /370.
39
Swift suministraba toda la documentación requrida, pero era necesario desarrollar y poner a punto los
programas. El software debía abarcar los niveles del modelo OSI: Aplicación, Presentación, Sesión,
Transporte, y Enlace. El protocolo del nivel de enlace era una versión de BSC modificada por SWIFT, los
restantes niveles tenían protocolos propios. El principal problema a resolver al elaborar los programas, fue
garantizar que todo funcionara en los tiempos requeridos, sobre un sistema que no soportaba la ejecución
en paralelo de programas (MS-DOS). El nivel de enlace se programó en C, los restantes niveles en Foxpro.
81
Junto con la creación del BCSA se decidió también elaborar un sistema automatizado para bancos
comerciales, que representó la primera versión del SABIC.
Para definir la arquitectura del SABIC se revisaron varios sistemas automatizados de bancos y se
contrastaron con las experiencias acumuladas hasta ese momento.
Finalmente se decidió tomar como modelo un sistema inglés, que funcionaba con éxito para
bancos comerciales en varios países. Se estudiaron en detalle sus características y principales
elementos arquitectónicos.
La primera versión del SABIC se puso en funcionamiento en enero de 1994, junto con la apertura
del BICSA. Esta primera versión no tenía todas las características previstas en el diseño del sistema,
sino que dado el poco tiempo disponible se le incluyeron solo los elementos esenciales para
garantizar el registro contables de ese banco, que comenzaba a operar y que tenía aun pocas
transacciones. Esta primera versión respetó los principios arquitectónicos definidos previamente,
con el fin de poder garantizar su evolución ordenada.
Ya en enero de 1995 el SABIC que estaba en explotación en el BICSA contaba con las principales
funcionalidades diseñadas en un inicio:
• Transaccional
• Tiempo real
• Multiusuario
• Multimoneda
Al ser transaccional el SABIC garantizaba que no se produjeran errores formales y
fundamentalmente de cuadre al actualizar las tablas con datos contables. Para el SABIC una
transacción es un conjunto de asientos contables que:
• Cuadran por moneda, fecha valor y fecha contable,
• No contienen errores formales,
• Provoca una actualización de todo o nada,
• Contiene una identificación unívoca,
Para garantizar las características de tiempo real y multiusuario se utilizó inicialmente la tecnología
de redes de computadoras de Novell. La programación desarrollada garantizaba que las
transacciones se ejecutaran de forma inmediata, lo que permitía que se realizara un control de la
disponibilidad de fondos antes de aceptar una transacción. Por otra parte, todos los usuarios del
sistema interaccionaban con él al mismo tiempo, y los reportes (posición por monedas, balance,
estado de resultado, etc.) se podían confeccionar con la información actualizada hasta el
momento de su emisión.
Todas las cuentas estaban abiertas por moneda, y se introdujo una cuenta nominal especial que
podía utilizarse como contrapartida, y permitía el cuadre por monedas si existía más de una en
una transacción. El saldo de esta cuenta nominal de conversión de monedas, representa en todo
momento la posición del banco en la moneda en cuestión.
82
En el primer trimestre de 1995 se decide la extensión del SABIC a otros bancos e instituciones
financieras. Desde mayo del 1995 hasta diciembre del 1996 el SABIC se instala en el Banco
Metropolitano y en 250 sucursales del entonces BNC.
En el período 1997 a 2000, años en los que se ejecuta una amplia reorganización del sistema
bancario cubano, el SABIC se implanta además en:
• La oficina central del BANDEC

• La oficina central del BCC
• La oficina central del BNC
• El Banco de Inversiones
• El Banco Exterior de Cuba
• Varias instituciones financieras no bancarias
Durante este período se le agregan al SABIC las siguientes funcionalidades:
 Tránsito entre sucursales por medios electrónicos (ver cuadro XXX.1). Hasta ese momento el
tránsito de operaciones contables entre sucursales se realizaba con papeles a través del correo
nacional.
TRANSFERENCIA DE FONDOS ENTRE CLIENTES DE DISTINTAS SUCURSALES

(DE CLIENTE X1 DE LA SUCURSAL X AL CLIENTE Y1 DE LA SUCURSAL Y)
SUCURSAL X SUCURSAL Y
CLIENTE X1
1000
TRANSITO RECIBIDO
1
1000
TRANSITO ENVIADO
1000 1000 RTD

2 CLIENTE Y1
3
1000
TRAN. ENV. RATIF.
1000
Cuadro XXX.1
El movimiento de papeles a través del correo para actualizar la cuenta de tránsito traía, como
es fácil de imaginar, grandes dificultades que provocaban descuadres en la contabilidad y no
pocas oportunidades de fraude.
Para mejorar esta situación se desarrollaron módulos que, utilizando la red de transmisión de
datos que existía en esos momentos (X-25), intercambiaban mensajes entre los SABIC que
funcionaban en distintas sucursales, y que sustituían el envío y recepción de los documentos.
83
• Centro de autorización de operaciones con tarjetas magnéticas (ver cuadro XXX.2). En 1997 se
instalaron los primeros cajeros automáticos en el país y se comenzaron a emitir tarjetas
magnéticas de débito con la marca RED.
El SABIC se utilizó desde un inicio para la autorización de las transacciones que se ejecutaban
con las tarjetas emitidas por los bancos que tenían este sistema.
Debido a los grandes volúmenes de transacciones que tuvo que enfrentar el SABIC para
resolver esta tarea, fue necesario rediseñar el módulo central de tal forma que soportara la
ejecución paralela de varios hilos, para poder mantener los tiempos de respuestas requeridos
por el funcionamiento de los cajeros automáticos40.
CENTRO DE EMISIÓN DE TRARJETAS MAGNÉTICAS

Y DE AUTORIZACIÓN DE SUS TRANSACCIONES
VISA
MASTERCARD
RED ETC
TPV TPV TPV
CENTRO CENTRO
AUTORIZADOR DE
CONTROL CONTROL
VISA
TRANSACCIONES MASTERCARD
CAJEROS TPV
SABIC AUTOMÁTICOS
RED VISA
Cuadro XXX.2
• Para asimilar el trabajo con la red de cajeros automáticos, fue necesario desarrollar
adicionalmente otros módulos que permitieran la conciliación de las operaciones y el cuadre
físico de cada cajero (ver cuadro XXX.3).
40
La respuesta a una transacción de un cajero automático no puede demorar más de 45 segundos,
independientemente de la distancia que tenga que recorrer el mensaje. Cuando en un mismo momento se
reciben varios cientos de solicitudes de autorización, o información, en el centro de emisión de las tarjetas,
la duración de la respuesta a cada uno de ellos no puede demorar más que fracciones de segundos, ya que
para garantizar que no se le autorice a una tarjeta un importe mayor al saldo que tiene, las transacciones
tienen que procesarse secuencialmente.
84
CONTROL DE CAJEROS AUTOMÁTICOS
BCC
SLBTR
2 1 2
1 CENTRO 2
CONTROL
SABIC CAJEROS SABIC
AUTOMÁTICOS
3
3
cuadro XXX.3
• El SABIC se utilizó también en estos años como soporte del Sistema de Liquidación Bruta en
Tiempo Real (SLBTR) que se implantó en el Banco Central de Cuba, a través del cual los bancos
comerciales intercambian por medios electrónicos sus transacciones (ver cuadro XXX.4).
PAGOS INTERBANCARIOS ORDENADOS POR CLIENTES

CUENTAS EN DISTINTOS BANCOS
SLBTR BCC
(SABIC)
BANCO1 BANCO2
4 36.00 36.00 4
2346550 Cr 36.00 2346560 Cr 36.00
3 5
1 1 2
Orden de pago 36.00 1843245

Db 1843245
Cr 1651234
2346560
2 36.00
6 36.00
BCC
BCC
2 36.00
6 36.00
cuadro XXX.4
85
• El sistema bancario cubano decidió en el año 1998 aplicar el principio de truncamiento41 para
facilitar la automatización del procesamiento de los cheques.
Se estandarizó la identificación de los cheques emitidos por los diferentes bancos, que incluye
el código del banco, la moneda, el número de la cuenta y el número del cheque.
De las tecnologías disponibles para leer por medios electrónicos la información de cada
cheque (caracteres magnéticos, caracteres reconocibles y código de barras) se escogió e
implantó la del código de barras, debido a que, al ser utilizada de forma masiva en el comercio
minorista, el costo de los equipos requeridos para dotar cada mostrador e imprimir los
cheques era el más bajo.
Con estas medidas, de cada cheque que se presenta en una sucursal bancaria, para su cobro o
depósito, sólo es necesario captar manualmente la fecha de emisión y el importe. Una vez que
se han leídos los datos contenidos en el código de barra, y captados los que se introducen
manualmente, las transacciones del SABIC pueden procesar el cheque, debitando localmente
la cuenta de su emisor si esto es posible, o enviándolo por medios electrónicos a la entidad
bancaria que corresponda.
Adicionalmente, La imagen del cheque se escanea para archivarla en soporte digital.
A finales del año 2000, con el fin de proyectar su futura evolución, se analizaron las principales
deficiencias de este sistema, considerándose las siguientes como las más significativas.
• El nivel de seguridad y protección del sistema era bajo. La tecnología que soportaba el sistema
(MS-DOS + Foxpro + Novell) era muy frágil, y el hecho de que en cada sucursal se actualizaban
y guardaban todos los datos, significaba que existían tantos puntos de vulnerabilidad como
sucursales tenía el banco.
• El esquema descentralizado en que se basaba el SABIC obligaba, además, al tránsito contable
entre sucursales, única solución con una tecnología basada en papeles como la que había
existido hasta el año 1995, pero superada en los grandes bancos a nivel internacional desde la
década del 70, cuando surgieron las posibilidades de teleprocesamiento.
Aun cuando el tránsito se había automatizado y funcionaba de una forma bastante eficiente,
no dejaba de representar un riesgo en la explotación del sistema, ya que para estar seguros de
que no había problemas, era necesario conciliar las cuentas de tránsito entre todas las
sucursales en los dos extremos.
• El sistema era, y lo sigue siendo en la actualidad, muy rígido en cuanto a la estructura de los
datos y los programas que deben desarrollarse para particularizar las transacciones, lo cual
obliga a realizar adaptaciones frecuentes para resolver problemas no previstos inicialmente.
• Por último, aunque no por esto menos importante, debido a la tecnología utilizada en su
programación, el mantenimiento del sistema requiere un gran esfuerzo, a pesar de que como
41
El principio de truncamiento consiste en aceptar, entre las instituciones bancarias, que la información
sobre un cheque que emite un banco es tan válida como el cheque en sí, con lo que no es necesario enviar
físicamente este efecto, sino sólo la información sobre él captada en la sucursal.
86
se verá más adelante su módulo central, que representa el cerebro del sistema, no ha
requerido modificaciones mayores desde su concepción inicial.
Durante el período 2001 – 2006 el SABIC evolucionó en los siguientes sentidos:
• Se migró de MS-DOS, como sistema de explotación de las terminales, y Novell, como sistema
de explotación de la red, a Windows para ambas funciones.
• Como principal lenguaje de programación se pasó de Foxpro a Visual Foxpro y SQL, y la gestión
de la base de datos se migró de Foxpro a SQL-Server.
• Se modificó el diseño de las tablas de la base de datos en lo que fue necesario para permitir la
contabilidad centralizada.
• Se aumentaron y consolidaron las medidas de seguridad y protección del sistema y de los
datos.
• A este conjunto de cambios se les dio el nombre de Nuevo Esquema Funcional (NEF) y se
Implantó en el Banco Metropolitano, que adquirió en la Ciudad de la Habana más de 100
sucursales que pertenecían anteriormente al BANDEC y al BPA.
Durante los últimos 6 años (2006-2012) el esfuerzo del grupo de especialistas que atienden el
SABIC se ha concentrado en estabilizar la versión implantada en el Banco Metropolitano y en
implantarla, aunque con un esquema descentralizado debido fundamentalmente a deficiencias en
los medios de comunicación, en el BANDEC que tiene unas 200 sucursales y en el BPA que cuenta
con 400 sucursales y cajas de ahorro en todo el país.
8.1.2 Principales servicios que brinda el SABIC

Los principales servicios que brinda el módulo central del SABIC en la actualidad son los siguientes:
• Seguridad y protección
La seguridad del SABIC se apoya fundamentalmente en la seguridad que brinda el software de
bases de datos SQL-SERVER, y consiste en la realización diaria de una copia total de la base de
datos (Backup), y en la actualización automática de una bitácora de todas las actualizaciones
de las tablas del sistema.
La copia diaria de la base de datos, la base de datos actualizada en cada momento, y el fichero
que contiene la bitácora de todo lo realizado, pueden guardarse físicamente en soportes
distintos, con lo que de producirse una rotura en el soporte de la base de datos más
actualizada, la misma puede recuperarse siempre desde los otros dos. De igual forma, si la
rotura es en el soporte que contiene la última salva o en el de la bitácora intermedia,
realizando una nueva salva de la base de datos más actualizada, se pueden reproducir las
condiciones de seguridad del sistema.
87
La protección del acceso sistema se garantiza, entre otras, con medidas en la red para limitar
interactuar con la base de datos, con la obligatoriedad de definir claves duras42 para cada
persona que tiene acceso al sistema, y con la confección de una bitácora lógica que registra
todas las acciones que sobre los datos se ejecutan y quien las ordenó.
Adicionalmente al final de cada día se comprueba la integridad contable de las principales
tablas del sistema.
• Cálculo y aplicación de intereses
En el SABIC los intereses se calculan todos los días como parte de las rutinas de inicio del día
contable. Para cada cuenta del mayor existe un campo llamado acumulado de intereses,
donde se van sumando diariamente los intereses calculados si corresponde. Para el cálculo de
los intereses de cada cuenta se define una tasa de interés, los días a considerar y los días base
(365 o 360 en ambos casos).
En el lenguaje del SABIC se le llama aplicación de intereses al registro contable del ingreso o
egreso de los intereses calculados hasta cierto momento, y del cobro o pago, o el registro en
cuentas por cobrar o pagar, de ese importe. Obviamente cuando se aplican los intereses el
campo de acumulado de intereses se lleva a cero.
La aplicación de los intereses puede hacerse a través de una transacción que se lance
manualmente, o de forma automática si se han definido los parámetros requeridos.
Una variante muy usada de la aplicación automática de los intereses es llevar, al final de cada
mes, los intereses acumulados hasta ese momento a una cuenta de “intereses por cobrar o
pagar devengados”.
• Registro anticipado de transacciones
Existen ciertas transacciones cuyo registro contable se conoce anticipadamente, como por
ejemplo la amortización de los activos fijos, que se debe realizar cada mes. En el SABIC estas
transacciones se pueden registrar en cualquier momento, señalando la fecha en que deben
contabilizarse realmente. Todos los días, cuando se inicia el sistema, programas del módulo
central revisan las transacciones que están pendientes y, si corresponde, las contabiliza.
• Saldo contable, saldo confirmado y saldo disponible
Para cada cuenta del mayor, el SABIC registra en todo momento un saldo contable y un saldo
confirmado. El saldo contable, conocido también como el saldo de los estados de cuenta,
incluye todos los movimientos registrados en el sistema con fecha contable menor o igual que
la fecha del día contable en curso. El saldo confirmado, conocido también como saldo para los
intereses, se calcula por la suma de todos los asientos que afectan una cuenta y que tienen
fecha valor igual o menor que la fecha del día contable en curso.
42
Se le da el nombre de clave dura a una clave de usuario que tenga no menos de 8 caracteres, que tienen
que contener mayúsculas, minúsculas, números y caracteres especiales y que debe ser modificada cada
cierto tiempo.
88
Adicionalmente el SABIC permite establecer relaciones de cuentas para calcular una
disponibilidad real de fondos. Así, por ejemplo, se puede definir una cuenta memorándum
para reservar fondos de la cuenta corriente de un cliente cuando a favor de este se emite un
aval o una garantía, o se recibe un cheque en depósito contra otro banco y no se tiene aún la
ratificación de su validez. De igual forma se pueden definir cuentas cuyo saldo se sume al saldo
confirmado de la cuenta, al momento de comprobar si existen fondos en la misma
(autorización de sobregiro).
• Cierre diario de posiciones en monedas extranjeras
Como parte del cierre contable diario, cada día se cierran las cuentas de conversión de
monedas, y cualquier otra cuenta nominal con monedas distintas a la moneda base del banco,
contra una cuenta de ingresos y egresos por tipo de cambio, utilizando el tipo de cambio del
día. Esta operación permite calcular las ganancias o pérdidas que se producen por tener
posiciones abiertas en distintas monedas a la moneda base43 cada día (ver 41).
• Emisión de estados de cuentas
Para todas las cuentas que se definan se puede emitir un estado de cuentas, con las reglas
propias de este tipo de reporte, con la periodicidad que se defina. Los estados de cuentas
normalmente están numerados de forma secuencial, incluyen el saldo contable inicial y final,
así como todos los asientos que lo afectaron. En el SABIC, adicionalmente, se incluye en el
estado de cuentas el saldo confirmado y el disponible al final del período que se informa.
Los estados de cuenta pueden imprimirse o enviarse por correo electrónico.
• Consulta de maestros, clasificadores y operativos
Todas las tablas del sistema pueden consultarse a través de un interfaz homogéneo que
permite construir expresiones lógicas con todos los campos de la tabla. Para cada campo se
pueden usar las funciones igual, menor, mayor, incluido en, desigual, etc. y unirlas con otras,
para otros campos, a través de los operadores “Y” y “O”. Las expresiones para consultar una
tabla pueden guardarse, dándoles un nombre, lo que permite utilizarlas de forma repetitiva. El
resultado de la consulta puede verse en pantalla, o ser impreso si se desea.
• Actualización de clasificadores y operativos
Para todos los clasificadores y operativos existe también un interfaz estándar que permite
actualizarlos, fila a fila.
• Reportes por pantalla, en papel, en formatos Excel o PDF
Todos los reportes que se emiten a través del SABIC pueden mostrarse por pantalla o llevarse
a un formato determinado, que puede ser papel, tabla Excel, o PDF.
43
En un banco una operación aislada en cierta moneda no produce en general ni pérdidas ni ganancias por
tipo de cambio. Esas pérdidas o ganancias se producen por tener posiciones abiertas (activos distintos a
pasivos) en una moneda, y variar el tipo de cambio.
89
• Recuperación de lotes
Todos los reportes que se emiten se guardan en una tabla del sistema que lleva el nombre de
maestro de lotes. Para gestionar esta tabla, cada reporte que se emite, además de su nombre,
recibe un número, llamado número de lote.
Los lotes de impresión se guardan por el período que se defina en los parámetros del sistema
y se pueden recuperar en cualquier momento, redefiniendo incluso su formato.
• Reverso de una transacción
Con el fin de simplificar la regla contable de que cuando una transacción contiene un error no
puede modificarse en ninguna de sus partes, sino reversarla completamente y volverla a
introducir con las correcciones, el SABIC contiene una transacción general que permite
reversar cualquier otra siempre y cuando no hayan sucedido hechos contables que no puedan
ser reversados44 automáticamente. Para reversar una transacción basta con dar los datos que
la identifican unívocamente.
• Interfaz para incorporar transacciones tipificadas
Una buena parte de los programas que hay que desarrollar para particularizar una aplicación
del SABIC tienen como objetivo captar los datos de una operación específica y, a partir de
estos, generar los asientos que se requieren para contabilizar la transacción correspondiente.
En el SABIC las tablas que contienen los datos contables sólo pueden actualizarse a través de
programas de su módulo central, por lo que las transacciones específicas tienen que preparar
los datos de los asientos en un formato predefinido (interfaz de contabilización del SABIC) y
entregárselos al módulo central. El módulo central revisa formalmente los asientos contables
que se le entregan y, si no detecta errores, actualiza las tablas con datos contables
garantizando que o se actualice totalmente la transacción o no se haga nada.
 Transacción general
La transacción general, permiten introducir los datos de cualquier transacción contable, y

garantiza que no se cometan errores formales, incluyendo el cuadre.
Como ya se explicó, la mayor parte de las transacciones del SABIC se ejecutan con programas
que particularizan las distintas operaciones o documentos primarios. Por muy exhaustiva que
haya sido la definición y programación de transacciones específicas, siempre se presentarán
casos que no se ajustan a lo tipificado, para los que se utiliza la transacción general.
• Interfaz para el tratamiento de mensajes financieros (ISO 8583)
Con el fin de permitir que el SABIC fungiera como sistema autorizador de las transacciones con
cajeros automáticos se desarrolló un interfaz basado en la norma ISO 8583, que permite
44
Un caso común es cuando una transacción implica la inserción de un artículo en cartera, por ejemplo una
cuenta por pagar, y al momento de quererse reversar el asiento insertado ya no existe. Como es fácil de
comprender, una operación con estas características no puede reversarse de forma automática.
90
recibir mensajes basados en ese estándar, accionar según los mismos indican y enviar las
respuestas que correspondan.
• Interfaz con el SLBTR y tránsito entre sucursales
El BCC definió un interfaz para interactuar con el SLBTR que, en esencia, utiliza los formatos
definidos por SWIFT para similares mensajes, y canales propios de comunicación con el
estándar SNMTP de correo electrónico.
Desde la creación el SLBTR del BCC funciona con el SABIC y, obviamente, cualquier
implantación de este sistema en un banco puede intercambiar mensajes contables con él.
• Configuración del sistema
El SABIC cuenta con un mecanismo de definición de variables locales y generales que permite
particularizar cada implantación. Las direcciones físicas donde se encuentran los componentes
del sistema, el tipo de entidad en el que está funcionando (centro contable, centro
informativo, sucursal, o una combinación de estos), la moneda base, el código de la entidad,
etc., son todos aspectos que pueden definirse para cada instalación.
8.1.3 Principales elementos arquitectónicos del SABIC

Los registros contables del SABIC se hacen en todos los casos a nivel de la “cuenta del mayor”
definida por el sistema.
Las cuentas del mayor tienen la siguiente estructura
• Código de moneda según un clasificador previamente definido, con dos dígitos.
• Código de cuenta/subcuenta con cuatro dígitos. La cuenta/subcuenta en el SABIC representa
el concepto contable que se quiere registrar (Efectivo, Fondos libres en banco, Cuenta
corriente de cliente, etc.). Existe un clasificador de cuentas que contiene el conjunto de las
cuentas/subcuentas que se utilizan en una aplicación particular (plan contable).
La codificación de las cuentas/subcuentas debe respetar las siguientes reglas:
• El valor del primer dígito tiene el siguiente significado
– Cuentas reales de activo para los valores 1 y 2
– Cuentas reales de pasivo y capital para los valores 3 y 4
– Cuentas nominales para el valor 5
– Cuentas contingentes de activo para los valores 6 y 7
– Cuentas contingentes de pasivo para los valores 8 y 9
• Por otra parte, las cuentas contingentes en el SABIC se registran siempre por partida doble
y, entre ellas, tienen que cumplir las mismas reglas formales y de cuadre definidas para las
cuentas reales.
• Tipo de Contraparte. Todas las cuentas del SABIC se asocian a una contraparte. Los principales
tipos de contraparte, codificados sobre un dígito son:
91
• Persona jurídica como cliente, con el valor 1,
• Bancos o instituciones financieras no bancarias, con el valor 2,
• Concepto de ingresos o egresos, con el valor 3,
• Persona natural como cliente, con el valor 5.
• Contraparte y su posible desglose para lo que se reservan 7 dígitos. El contenido de la
contraparte depende de su tipo, y tiene la siguiente codificación:
• Las personas jurídicas como clientes se codifican sobre 5 dígitos y se asocian a un
clasificador de clientes, en el que se pueden definir distintos segmentos (con cuentas
corrientes en el banco, suministradores nacionales, suministradores extranjeros, etc.).
Cuando la contrapartida es un cliente, quedan dos dígitos, a los que se les da el nombre de
desglose, y sirven para identificar distintas cuentas de un cliente en la misma moneda.
• Los bancos o instituciones financieras no bancarias se codifican sobre cuatro dígitos y se
asocian a un clasificador de bancos. Cuando la contrapartida es un banco quedan tres
dígitos disponibles para el desglose, los que pueden utilizarse, por ejemplo, en
particularizar cada operación de crédito (otorgado o recibido) con esa entidad financiera.
• Las cuentas nominales tienen como contrapartida los conceptos de ingresos y egresos
codificados sobre cuatro dígitos, y que se detallan también en un clasificador. El desglose
de los conceptos de ingresos y egresos contiene el código del centro de costo que les dio
origen sobre tres dígitos.
• Cuando la contrapartida de una cuenta del SABIC es una persona natural se utilizan los 7
dígitos para su identificación. Existe además un clasificador de personas, donde para cada
código de 7 dígitos se recogen los principales datos de la misma, tales como tipo de
documento de identificación (pasaporte, carnet de identidad, etc.) número de
identificación, nombre, dirección, etc.
El clasificador de personas del SABIC no contiene sólo las personas que tienen cuentas
personales en la institución donde está implantado el sistema, sino también todas aquellas
que de una u otra forma se relacionan con el mismo, como empleados, firmantes de
cuentas, etc.
Los datos contables del SABIC se archivan en tres tablas con los siguientes nombres y contenidos:
 El Mayor que contiene para cada cuenta a catorce dígitos:
• El saldo contable
• El saldo confirmado
• Un acumulado de intereses
• Fecha de la última contabilización
• Fecha del último cálculo de intereses
92
Nótese que no existe un campo para el signo de los saldos (débito o crédito). El SABIC utiliza
para todos los importes la convención de que los valores positivos son deudores y los
negativos acreedores.
 El diario que contiene una copia de todos los asientos contables que tendrán que actualizar el
mayor en un futuro de una forma u otra. Cada asiento contable contiene, entre otros, los
siguientes datos:
• Cuenta a 14 dígitos
• Importe
• Tipo de asiento del diario
• Fecha de posteo
• Fecha contable
• Fecha valor
• Fecha de vencimiento
• Referencias e identificación de transacciones
Los tipos de asientos del diario identifican el tratamiento a darle al artículo en cuestión. Así,
un tipo de asiento del diario con valor 01 significa que ese asiento se registró con una fecha
valor mayor a la contable, que ya se actualizó el saldo contable, y que cuando llegue la fecha
valor, en la rutina de inicio del día, se deberá actualizar el saldo confirmado y eliminar el
artículo del diario.
Los tipos de asiento con valor 02 identifican los asientos que constituyen las carteras, para los
que obligatoriamente se define una fecha de vencimiento.
 Por último el histórico contiene una copia de todos los asientos contables que modificaron en
algún momento el diario y/o el mayor. Los principales datos contenidos en el histórico son:
 Cuenta a 14 dígitos
 Importe
 Fechas (todas las contenidas en el diario y la de actualización del histórico)
 Centro de costo y operador
 Referencia original
 Referencia corriente
 Referencia externa
 Número de transacción
 Número de asiento
 Número de transacción original
 Número de asiento original
Nótese que para cada asiento se guardan tres referencias, la corriente, la original y la externa.
La referencia corriente identifica cada transacción, la referencia original puede contener la
referencia corriente de una transacción que de alguna forma le sirvió de antecedente, Por
ejemplo, cuando se reversa una operación la transacción que reversa toma un número de
93
referencia corriente propio de ella y, como referencia original, la referencia corriente de la
transacción que se reversa.
La referencia externa sirve para identificar cualquier documento que haya servido de base
para la transacción que se contabiliza.
El cuadro XXX.5 muestra los principales módulos del SABIC y la forma en que se relacionan. Como
se puede apreciar en el mismo todos los datos se almacenan en una base de datos relacional, en la
actualidad se utiliza SQL-Server en la versión del 2005.
El módulo central es el encargado de mantener la coherencia contable del sistema, garantizando

que las transacciones no tengan errores formales y que actualicen la base de datos a través de un
procedimiento de todo o nada. Adicionalmente el módulo central contiene los programas que se
corren en todos los casos en el cierre e inicio del día contable, y es el encargado de llamar a otros
programas, que se definan en una aplicación particular, para correr en esos momentos.
Por último el módulo central es el encargado de actualizar todos los datos relacionados con las
posibles configuraciones del sistema y controla el diálogo con los usuarios.
ARQUITECTURA DEL SABIC

SEGURIDAD Y PROTECCIÓN
T
R
A
N
S MAESTROS
A I S DE CONTABILIDAD
C G MAYOR
N C HISTORICO
C B
O DIARIO
T D
I N
O E T MÓDULO R
A
N R B CENTRAL E
E L
F L
S A
E
A C CLASIFICADORES
I OTROS MAESTROS
Z O
R C OPERATIVOS
E O N
P N A
Oy S L
R U PROCESADOR
T L MENSAJES
E T FINANCIEROS
S A
S
RTD OTROS
SISTEMAS
Cuadro XXX.5
Las funciones de la interfaz contable se comentaron más arriba, así como las transacciones, los
reportes y consultas y el procesador de mensajes financieros.
Como muestra el cuadro XXX.5 todo el acceso al sistema está controlado por las funciones de
seguridad y protección, que garantizan que sólo las personas autorizadas puedan interactuar con
el mismo y dejan trazas sobre lo ejecutado.
94
8.1.4 Base de clientes
El SABIC se encuentra implantado en los siguientes bancos:
Banco Central de Cuba
Banco de Crédito y Comercio
Banco Popular de Ahorro
Banco Metropolitano
Banco de Inversiones
Banco Exterior de Cuba
Banco Nacional de Cuba
Banco Industrial de Venezuela
Banco de Exportación y Comercio (Venezuela)
Y en las siguientes instituciones financieras no bancarias:
Fintur
Finatur
Fincopex
Fincomex
Rafin
Lo que en total representa unas 700 oficinas y más de 15000 puestos de trabajo.
Los volúmenes totales de transacciones mensuales que se hacen con el SABIC deben sumar algo
más de 10 millones, de las cuales el 60% tiene que ver con las operaciones de tarjetas magnéticas
y cajeros automáticos.
8.1.5 Tecnologías utilizadas

La versión actual del SABIC está soportada por:
WINDOWS
SQL-SERVER
Visual Foxpro
Lenguaje C++
Como se habrá podido apreciar de las explicaciones dadas anteriormente, la arquitectura del
sistema parte de tener un módulo central que realiza las funciones más generales de la
contabilización bancaria, incluyendo la actualización de todos los ficheros con datos contables.
A este módulo central se le agregan programas que permiten particularizar las transacciones de
una implantación específica, y emitir los reportes de salida específicos. La mayor parte de estos
programas están elaborados utilizando VisualFoxpro, aunque no es la única alternativa. Cualquier
lenguaje que pueda interactuar con el SQL-Server puede ser utilizado.
Esta arquitectura ha permitido emplear el SABIC, tanto en instituciones financieras con algunos
trabajadores, como en bancos con miles de puestos de trabajo y cientos de oficinas.
95
8.1.6 Requerimientos
Además de los paquetes de software antes señalados, para implantar el SABIC se requiere como
mínimo una computadora que funcione como servidor y tantas como puestos de trabajo existan.
En casos de entidades extremadamente pequeñas, el propio servidor puede servir como terminal
para un puesto de trabajo.
Cuando existen sucursales, cada una de ellas debe tener disponible un servidor local,
adicionalmente a los puestos de trabajo.
Si el sistema funciona en un solo edificio debe estar disponible una red de área local (LAN) con
velocidades de al menos 100 Mbps.
Si las sucursales u otras oficinas que funcionan con el sistema se encuentran en locales ubicados
en distintos puntos geográficos, se requiere adicionalmente un enlace a distancia (WAN) con
velocidades no inferiores a los 64 Kbps.
En dependencia de los volúmenes de impresión se requieren impresoras en cada puesto de
trabajo o conectadas a la red. Las impresoras pueden ser de matriz de punto o con tecnología
laser, en todos los casos basta con que sean en blanco y negro.
Para las funciones de salva se requiere, adicionalmente, contar con una capacidad de
almacenamiento en otro equipo, preferiblemente ubicado en un local distinto al de los servidores
centrales. La capacidad de almacenamiento de las salvas depende obviamente de los volúmenes
de datos que trate el sistema.
96
Bibliografía
1. The A.C.I.D. Model
http://databases.about.com/od/specificproducts/a/acid.htm
2. Biography of Lucas Pacioli
Artículo de J J O'Connor y E F Robertson
http://www-groups.dcs.st-and.ac.uk/history/Biographies/Pacioli.html
3. Traducción de Particularis de Computis et Scripturis
http://archive.org/stream/ancientdoubleent00geijuoft/ancientdoubleent00geijuoft_djvu.txt
4. Herman Hollerith: Data Processing Pioneer
William R. Aul
Think, November 1972
http://www-03.ibm.com/ibm/history/exhibits/builders/builders_hollerith.html
5. Historia y características del RPG
http://en/wikipedia.org/wiki/IBM_RPG
6. Response time in man-computer conversational transactions
Robert B. Miller, IBM Poughkeepsie, New York
Fall Joint Computer Conference, 1968
http://theixdlibrary.com/pdf/Miller1968.pdf
7. A Relational Model of Data for Large Shared Data Banks –SEAS
E.F. Codd, IBM Research Laboratory, San Jose, California
Communications of the ACM,
Volume 12, Número 6, Junio 1970
www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
8. UNIX Past
http://www.unix.org/what_is_unix/history_timeline.html
9. The History of the IBM Personal Computer
Marzo 2011, John Koenig
http://computemagazine.com/the-history-of-the-ibm-personal-computer/
10. Desarrollo del protocolo TCP/IP
http://www.cs.utexas.edu/users/chris/think/Early_Days_Of_TCP/index.shtml
11. Desarrollo de las fibras ópticas
http://www.fiber-optics.info/history/history/
12. Ley de Moore
http://www.mooreslaw.org/
13. Carta de los jefes ejecutivos (CEOs) de SAP, Informe anual 2011
http://www.sapannualreport.com/2011/en
14. Carta a los accionistas, clientes, colaboradores y empleados. Informe anual 2011 de Microsoft
http://www.microsoft.com/investor/reports/ar11/index.html
15. Carta del presidente y jefe ejecutivo (CEO) de IBM, informe anual de 2011 IBM
http://www.ibm.com/investor/pdf/2011_ibm_annual.pdf
16. Infraestructura inteligente, artículo de HP
http://www.hpl.hp.com/research/intelligent_infrastructure.html
17. ACM seminario 2012, índice

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=6167332
18. Intel reporte anual 2011, riesgos
97
www.intc.com/intelAR2011
19. Medios de Pago
Dr. Jorge Barrera Ortega, 2011
Propuesta su publicación por la editorial de la Universidad de la Habana
20. SWIFT in figures
www.swift.com
21. The Bolero Rulebook
www.bolero.net/en/Newsdownloads/articlesordownloads.aspx
22. Bolero Solutions Overview
www.bolero.net/en/solutions/Overview.aspx
23. Zimmermann, Hubert (Abril 1980)
OSI Reference Model – The ISO Model of Architecture for Open System Interconection
IEEE Transactions on Communications 28 (4)
Páginas 425 – 432
24. Data Mining: What is Data Mining ?
http://www.anderson.ucla.edu/faculty/jason.frand/teacher/technologies/palace/datamining.htm
25. UN/EDIFACT documentación
http://www.unece.org/trade/untdid/welcome.html
26. Especificaciones técnicas del iPhone 5
www.apple.com/iphone/specs
27. Especificaciones técnicas del iPad
www.apple.com/ipad/specs
28. OCW de mit
29. Readings in Database Systems
4th edition
Joseph M. Hellerstein and Michael Stonebraker
The MIT Press
Cambridge, Massachusetts
30. Peter P. Chen: The Entity-Relationship Model - Toward a Unified View of Data.
ACM Transactions on Database Systems 1(1),
1976 Pag. 9-36
31. [WONG79] Eugene Wong, R. H. Katz: Logical Design and Schema Conversion for
Relational and DBTG Databases.
Entity-Relationship Approach to System Analysis and Design
Proc. 1st International Conference on the Entity-Relationship Approach
North Holland, 1979 Pag. 311-322
32. Top 10 Enterprise Database Systems to Consider
Kenneth Hess, mayo 20 2010
http://www.serverwatch.com/trends/article.php/3883441/Top-10-Enterprise-Database-Systems-to-
Consider.htm
33. Aplicación del enfoque sistémico a la automatización de la elaboración del plan de la economía
nacional utilizando las técnicas de bancos de datos y el diálogo hombre – máquina.
Barrera J., Ortiz E. y Zamora V.
Ponencia al Seminario del Instituto de Matemática Aplicada y Computación de la Academia de
Ciencias de Cuba,.
La Habana, Marzo 1982
98
34. Una aplicación del modelo relacional en la base de datos del sistema unificado de
procesamiento del plan.
Barrera J., Ortiz E. y Hernández L.
Economía Planificada No. 2,
La Habana, Marzo 1980
35. SACP Sistema automatizado de cálculos del plan
Lebedinsky N.P. y otros
Editorial Económica,
Moscú 1980
36. An Overview of Different Authentication Methods and Protocols
Richard Duncan,
Octubre 23,2001
http://www.sans.org/reading_room/whitepapers/authentication/overview-authentication-
methods-protocols_118
37. Understanding and selecting authentication methods
Deb Shinder
Agosto 28, 2001
http://www.techrepublic.com/article/understanding-and-selecting-authentication-
METHODS/1060518
38. X12 EDI Transactions sets

www.x12.org/x12org/docs/EDITransactions.pdf
39. Banking Industry Architecture Network (BIAN)

www.bian.org
40. An overview of enterprise resource planning

The Institute of Chartered accountants of India
220.227.161.86/21489sm_finalnew_isca_vol2_cp7.pdf
41. Registro y análisis de los activos y pasivos que modifican su valor

Revista del Banco Central, La Habana
Año 9 No. 2 trimestre abril – junio 2006. ISSN 1560-795X
99

Libro Sistemas Automatizados de Contabilidad

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Sistemas Automatizados de Contabilidad

Cargado por

Copyright:

Formatos disponibles

SISTEMAS AUTOMATIZADOS

Dr. Jorge Barrera Ortega

2.1 Contenido del ciclo contable

 Recepción del documento primario

Definición de cuentas a afectar

Archivo de documento CARTERAS

Depuración de errores Registro en mayor MAYOR

Conciliación de estados de cuenta

2.2 La recepción del documento primario

Recepción de documento primario

2.3 La definición de las cuentas a afectar

Definición de cuentas a afectar

Escaque x -> Cuenta 1 / Signo

2.4 El registro en el libro diario

1/1/2012 Cuentas por cobrar Factura 1 10000

2.5 El archivo del documento primario

2.6 La gestión de activos y pasivos pendientes

1/1/2012 Efectivo TPV 12 5432.34

Mayor Ingresos por ventas

Mayor Cuentas por cobrar

2.8 La conciliación de los estados de cuenta

2.9 El balance de comprobación

Emitir Balance de Comprobación

Mayor Cuentas por cobrar

Total 0 XXXXX XXXXX 0

2.11 La emisión de los estados financieros

3.1 Producir un diario en soporte electrónico

Los principales efectos de este primer paso de la automatización de la contabilidad fueron: la

Definición de cuentas a afectar Gestión de carteras

Archivo de documento DOCUMENTOS

Depuración de errores Registro en mayor MAYOR

Conciliación de estados de cuenta

En este primer estadio de la automatización, el registro en el diario se continuaba haciendo

Registro en el diario Gestión de carteras

Archivo de documento DOCUMENTOS

Depuración de errores Registro en mayor MAYOR

Conciliación de estados de cuenta

3.3 Recepción de documentos primarios en soportes electrónicos

Registro en el diario Gestión de carteras

Archivo de documento DOCUMENTOS

Depuración de errores Registro en mayor MAYOR

Conciliación de estados de cuenta

3.4 Integración del SAC en un ERP

ERP SAP R/3

3.5 Interacción con otros sistemas automatizados

REGISTRO Recepción documento primario DOCUMENTOS

Depuración de errores Registro en mayor MAYOR

4.1 Surgimiento de la contabilidad actual

Su principal obra, llamada “Summa de Arithmetica, Geometrica, Proportione et Proportionalita”,

• La ecuación fundamental de la contabilidad

4.2 Los equipos de tarjetas perforadas

Los sistemas de tarjetas perforadas

Perforadora. Equipo que reproducía la información que se introdujera a través de un teclado, en

Clasificadora. La clasificadora procesaba un lote de tarjetas y colocaba en diferentes bolsillos las

4.3 Las computadoras

Todos estos equipos de la segunda generación, especializados en procesamiento de datos5, tenían

La actualización de los mayores y la emisión del balance de comprobación y los estados

4.4 Las redes de terminales

4.5 Las minicomputadoras, las bases de datos y UNIX

4.6 Las PC, las fibras ópticas, Internet y los celulares

MODELO OSI DE 7 CAPAS

APLICACIÓN N7 PROTOCOLO N7 APLICACIÓN N7

PRESENTACION N6 PROTOCOLO N6 PRESENTACION N6

SESION N5 PROTOCOLO N5 SESION N5