La gestión de backups o copias de seguridad es una actividad a planificarse a medida de la organización que la requiere a fin de obtener el objetivo esperado con el mínimo costo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
miércoles, 30 de diciembre de 2009
lunes, 19 de octubre de 2009
NO Cambio de hora en Argentina - Servidores Ubuntu
Gracias: http://www.vivalinux.com.ar/distros/parche-tzdata-argentina
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
miércoles, 16 de septiembre de 2009
Software Libre en las Empresas
¿Qué es el software libre?
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
lunes, 3 de agosto de 2009
Business Intelligence
Se denomina Business Intelligence (BI) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización u empresa. (http://es.wikipedia.org/wiki/Business_intelligence)
Es el ámbito informático y la actual potencia computacional el lugar en el cual ese objetivo de crear conocimiento comienza a ser factible:
Dato e Información
Desde el inicio de la era de la automatización de la información, se ha hablado de “dato” como la mínima unidad o átomo de los sistemas: la fecha de un evento, el nro de cliente relacionado a una transacción.
Simultáneamente, agrupando los datos se hablaba y se continúa hablando de “información”: una factura (incluye y relaciona a esa fecha con ese cliente), una cuenta corriente, una conciliación bancaria.
Conocimiento
Actualmente, a ese par de conceptos se le agrega un tercero inaugurando una nueva dimensión: el conocimiento.
Así que ahora los rangos o jerarquías de valores en un sistema de información se componen de tres escalas: dato, información y conocimiento.
¿Cuál es la tendencia de nuestros consumidores en los últimos seis años? ¿Cómo se comparan las ventas de esta temporada con las anteriores? ¿Y si sólo se consideran ciertos rubros? ¿Y si se consideran todos los rubros? ¿Qué hay de las compras de los nuevos clientes comparadas con las de los más antiguos?
Se necesitan esas respuestas y se necesitan YA.
Por supuesto que la inteligencia del negocio ya existe en el mismo desde hace mucho tiempo, quizá desde su inicio. Lo nuevo acá es que su origen y consistencia se respaldan por una evidencia objetiva, que está disponible para todos los actores que se considere necesario, que se obtiene de una manera económica y confiable y que no se necesita ser un experimentado actor del negocio para deducirla con cierta incertidumbre.
Además, el conocimiento que va aflorando a través de estrategias de BI, puede deparar sorpresas: puede ocurrir que cierta percepción que se tenía del negocio, de repente se ve cuestionada por informes que muestran lo contrario.
Conocimiento, el último de la lista de prioridades
Lo habitual es que se tiendan a resolver con prioridad las cuestiones operativas: poner en marcha “el sistema” y que se pueda facturar rápido, comprar rápido, controlar el stock, etc.
A lo sumo y junto con esas cuestiones operativas resueltas, hay disponibles ciertos “listados”. ¿Pero qué ocurre cuando además de un “listado de ventas del mes” se necesitan cosas tan básicas como un gráfico para comparar datos estacionales, o un consolidado que abarque muchos años?
Lo que siempre se deja para “después” es la posibilidad de generar un tremendo valor agregado a todos esos registros que van quedando grabados.
Herramientas
Son muchas las herramientas y estrategias para generar conocimiento con BI.
Conceptualmente hablando y por mencionar ciertos términos que se están popularizando, se habla de la necesidad de “preparar” la información para que comience a ser más accesible (datawarehousing), de “cruzar” la información (olap) y de analizar la misma para encontrar patrones o tendencias (data mining).
Actualmente es muy común que las pymes tengan una gran cantidad de historia en archivos digitales: hasta 20 años de facturaciones, remitos, pagos, libros de banco, precios, costos, etc.
Todo ese volumen tiene mucho conocimiento “oculto”. Los datos están, la información está (son un hecho, se pueden ver), pero el conocimiento también está; sólo que requiere de herramientas y procedimientos para salir a la luz y ayudar a todos a tomar mejores decisiones (no sólo a puestos directivos y gerenciales sino también a posiciones operativas).
Las soluciones disponibles no se limitan al mercado de las grandes corporaciones. Actualmente es posible armar planes para poner en marcha BI con presupuestos acordes a pymes.
Es el ámbito informático y la actual potencia computacional el lugar en el cual ese objetivo de crear conocimiento comienza a ser factible:
Dato e Información
Desde el inicio de la era de la automatización de la información, se ha hablado de “dato” como la mínima unidad o átomo de los sistemas: la fecha de un evento, el nro de cliente relacionado a una transacción.
Simultáneamente, agrupando los datos se hablaba y se continúa hablando de “información”: una factura (incluye y relaciona a esa fecha con ese cliente), una cuenta corriente, una conciliación bancaria.
Conocimiento
Actualmente, a ese par de conceptos se le agrega un tercero inaugurando una nueva dimensión: el conocimiento.
Así que ahora los rangos o jerarquías de valores en un sistema de información se componen de tres escalas: dato, información y conocimiento.
¿Cuál es la tendencia de nuestros consumidores en los últimos seis años? ¿Cómo se comparan las ventas de esta temporada con las anteriores? ¿Y si sólo se consideran ciertos rubros? ¿Y si se consideran todos los rubros? ¿Qué hay de las compras de los nuevos clientes comparadas con las de los más antiguos?
Se necesitan esas respuestas y se necesitan YA.
Por supuesto que la inteligencia del negocio ya existe en el mismo desde hace mucho tiempo, quizá desde su inicio. Lo nuevo acá es que su origen y consistencia se respaldan por una evidencia objetiva, que está disponible para todos los actores que se considere necesario, que se obtiene de una manera económica y confiable y que no se necesita ser un experimentado actor del negocio para deducirla con cierta incertidumbre.
Además, el conocimiento que va aflorando a través de estrategias de BI, puede deparar sorpresas: puede ocurrir que cierta percepción que se tenía del negocio, de repente se ve cuestionada por informes que muestran lo contrario.
Conocimiento, el último de la lista de prioridades
Lo habitual es que se tiendan a resolver con prioridad las cuestiones operativas: poner en marcha “el sistema” y que se pueda facturar rápido, comprar rápido, controlar el stock, etc.
A lo sumo y junto con esas cuestiones operativas resueltas, hay disponibles ciertos “listados”. ¿Pero qué ocurre cuando además de un “listado de ventas del mes” se necesitan cosas tan básicas como un gráfico para comparar datos estacionales, o un consolidado que abarque muchos años?
Lo que siempre se deja para “después” es la posibilidad de generar un tremendo valor agregado a todos esos registros que van quedando grabados.
Herramientas
Son muchas las herramientas y estrategias para generar conocimiento con BI.
Conceptualmente hablando y por mencionar ciertos términos que se están popularizando, se habla de la necesidad de “preparar” la información para que comience a ser más accesible (datawarehousing), de “cruzar” la información (olap) y de analizar la misma para encontrar patrones o tendencias (data mining).
- Se necesita “preparar” la información ya que normalmente la misma se va almacenando (a medida que surge de las actividades operativas) de una manera que no es la mejor para analizarlos (ni aún los actuales sistemas computacionales tan potentes pueden procesar información que no se encuentre adecuadamente almacenada para los fines de generar conocimiento). Esto no necesariamente implica una demora en la disponibilidad. Actualmente se habla de preparar en un modo NRT (near real time o “casi en tiempo real”) de tal manera que los eventos operativos se registran y ya están aportando al conocimiento del negocio.
- Se necesita “cruzar” la información para que comience a “aflorar” el conocimiento (como casos simplificados pero accesibles, ver las tablas dinámicas de Excel, las referencias cruzadas de Access o el Piloto de Datos de OpenOffice).
- Se necesitan estrategias para “analizar” los reportes o listados de tal manera que se expliciten ciertas tendencias como parte del conocimiento.
Actualmente es muy común que las pymes tengan una gran cantidad de historia en archivos digitales: hasta 20 años de facturaciones, remitos, pagos, libros de banco, precios, costos, etc.
Todo ese volumen tiene mucho conocimiento “oculto”. Los datos están, la información está (son un hecho, se pueden ver), pero el conocimiento también está; sólo que requiere de herramientas y procedimientos para salir a la luz y ayudar a todos a tomar mejores decisiones (no sólo a puestos directivos y gerenciales sino también a posiciones operativas).
Las soluciones disponibles no se limitan al mercado de las grandes corporaciones. Actualmente es posible armar planes para poner en marcha BI con presupuestos acordes a pymes.
martes, 26 de mayo de 2009
Gestión de existencias
Introducción
Una de los principales preocupaciones que plantean las empresas y que los motivan a buscar “un sistema”, es la problemática de la “contabilidad de la existencia”.
Frases como “no sé dónde estoy parado”, “¿cuánta plata hay en este depósito?”, “nunca pudimos manejar el stock bien”, “... sí, pero este negocio es especial y es imposible tener el stock” surgen habitualmente.
Sumado a esto, hoy las organizaciones cuya principal actividad es la comercialización de bienes de cambio, o también ciertas áreas (como por ejemplo un departamento de repuestos con clientes internos) se ven en la obligación, para ser competitivos, de minimizar todos sus costos, dentro de los cuales se incluyen el costo de almacenaje, el costo financiero por índices de rotación bajos, el costo de no contar con la mercadería en el momento oportuno, etc.
Sin embargo, la experiencia indica que en la gran mayoría de los casos, teniendo en cuenta ciertos simples procedimientos y con el software adecuado, no hay ningún impedimento por el cual una organización pueda tener en todo momento bien en claro cuál es su situación de existencias.
Conscientes de que este enfoque se encuentra simplificado, al no tener especialmente en cuenta a la organización como un todo, de todos modos es importante presentar una introducción.
Tipos de mercadería
Desde el punto de vista logístico, los productos se pueden clasificar en (por supuesto que no es la única clasificación posible):
Se trata de mercadería de la cual no se tiene identificación de cada individuo o grupo que conforma la existencia. De toda esa mercadería no tiene especial importancia si se debe vender una antes que la otra, si cierto individuo ingresó a la existencia antes o después que otro, etc.
Para estos productos la novedad a informar al sistema se limita a saber de cuánta cantidad del mismo se trata.
Si por alguna razón en particular se desea conocer alguna propiedad de los grupos que se fueron movilizando, por ejemplo si se desea conocer el costo que tuvo una cierta mercadería que egresa de un depósito, más allá del costo de reposición, luego existen técnicas como la de PEPS (primero entrado, primero salido). Estas propiedades pueden estimarse en base a los registros que quedaron en las novedades de ingreso y egreso (fechas, costo al momento de ingreso, etc) sin tener que estar obligados a que un cierto lote contenga esas propiedades.
Productos cuya existencia debe administrarse por lotes.
Existen razones por las cuales se debe mantener identificados grupos de individuos. Una muy típica es el vencimiento: por ejemplo, un lote de tarros de aceite lubricante tiene un vencimiento que se encuentra más próximo a ocurrir que otro. Al tener que usar aceite lubricante debe existir un proceso que automáticamente proponga utilizar el aceite del lote más próximo a vencer.
Otra razón es la existencia de mercadería con retazos (más allá de los fluidos): por ejemplo barras de acero de varios metros de longitud que pueden fraccionarse. O tela: si por ejemplo se dispone de 10 metros de una cierta tela, es necesario conocer si esos 10 metros están compuestos por un solo tramo o por dos tramos, uno de 4,4 y otro de 5,6 metros, ya que, si se necesitan 7 metros, en la existencia están disponibles pero hay que saber que no se encuentran en un solo tramo.
Para estos productos la novedad a informar al sistema no sólo debe ser la cantidad, sino de qué lote proviene esa cantidad y en cuántos lotes se presenta esa cantidad.
Productos cuya existencia debe administrarse por lotes unitarios o nro. de serie.
Ciertos productos deben conservarse durante su gestión logística con propiedades únicas. Tal es el caso de equipos con un nro de serie, como pueden desde teléfonos celulares y notebooks hasta automóviles.
Muchas son las razones que llevan a la necesidad de mantener cada individuo identificado, como pueden ser ciertos términos de garantía, elevado precio, propiedades únicas de cada individuo, trazabilidad, etc.
En un modelo logístico es posible dar a estos productos un tratamiento similar al modelo por lotes pero llevado a un extremo: lotes unitarios o lotes de cantidad uno.
La novedad a informar en estos casos es simplemente cuál es el nro. de serie o identificador único de lote unitario.
Productos que no requieren administrar existencia.
Esta es una omisión muy común en los sistemas logísticos: dar la oportunidad a tener mercadería sin existencia.
Hay ciertos productos que por ejemplo por su alta rotación, gran cantidad y bajo costo, son más costosos de administrar su existencia que ignorarlos. En ese caso puede armarse un modelo que ignore la existencia de esos productos y los considere siempre disponibles.
También estos productos son muy útiles a la hora de usarlos para representar servicios, por ejemplo en una novedad de existencia puede ocurrir esta salida:
El no considerar este tipo de productos puede provocar “ruido” en la base de datos, perdiendo valor la misma. Es muy típico pedir listados de existencia valorizados y que los totales se vean disminuidos por cantidades en negativo de productos que no requieren administrar existencia.
Eventos típicos que provocan un cambio logístico
de Entrada:
Es muy importante que la cuestión operativa sea lo más ágil posible teniendo en cuenta que todas las novedades queden registradas en el sistema informático de la manera más natural, para acompañar al procedimiento diseñado.
En modelos de existencia como el del ERP Regente, de Bircher y Asociados, todo queda simplificado a la confección de “remitos digitales” por los cuales el sistema, manual o automáticamente, deja evidencia de la novedad ocurrida.
La filosofía del modelo de los “remitos digitales”, está inspirado en el uso tradicional del remito de talonario, resultando muy sencillo de aprender para cualquier persona.
Estos remitos digitales, tienen tres partes fundamentales:
Independientemente del soporte tecnológico o manual, un evento típico consta de esos pasos:
Tal es el caso de un punto de venta unipersonal, en el cual la misma persona es la que está asesorando a un cliente, cerrando la venta, facturando, etc. En esos casos puede configurarse el modelo para que el remito de salida por venta sea disparado automáticamente (y silenciosamente) durante la transacción de impresión fiscal de la factura por ejemplo.
Explotación de la información
Una vez resuelta la cuestión operativa necesaria, surge el verdadero valor de una organización logística como es el hecho de poder contar de manera oportuna con información de existencias. Por ejemplo:
Ing. Pablo Giancarelli
http://www.bircherasociados.com.ar
Una de los principales preocupaciones que plantean las empresas y que los motivan a buscar “un sistema”, es la problemática de la “contabilidad de la existencia”.
Frases como “no sé dónde estoy parado”, “¿cuánta plata hay en este depósito?”, “nunca pudimos manejar el stock bien”, “... sí, pero este negocio es especial y es imposible tener el stock” surgen habitualmente.
Sumado a esto, hoy las organizaciones cuya principal actividad es la comercialización de bienes de cambio, o también ciertas áreas (como por ejemplo un departamento de repuestos con clientes internos) se ven en la obligación, para ser competitivos, de minimizar todos sus costos, dentro de los cuales se incluyen el costo de almacenaje, el costo financiero por índices de rotación bajos, el costo de no contar con la mercadería en el momento oportuno, etc.
Sin embargo, la experiencia indica que en la gran mayoría de los casos, teniendo en cuenta ciertos simples procedimientos y con el software adecuado, no hay ningún impedimento por el cual una organización pueda tener en todo momento bien en claro cuál es su situación de existencias.
Conscientes de que este enfoque se encuentra simplificado, al no tener especialmente en cuenta a la organización como un todo, de todos modos es importante presentar una introducción.
Tipos de mercadería
Desde el punto de vista logístico, los productos se pueden clasificar en (por supuesto que no es la única clasificación posible):
- Productos cuya existencia se puede administrar a granel.
- Productos cuya existencia debe administrarse por lotes.
- Productos cuya existencia debe administrarse por lotes unitarios.
- Productos que no requieren administrar existencia.
Se trata de mercadería de la cual no se tiene identificación de cada individuo o grupo que conforma la existencia. De toda esa mercadería no tiene especial importancia si se debe vender una antes que la otra, si cierto individuo ingresó a la existencia antes o después que otro, etc.
Para estos productos la novedad a informar al sistema se limita a saber de cuánta cantidad del mismo se trata.
Si por alguna razón en particular se desea conocer alguna propiedad de los grupos que se fueron movilizando, por ejemplo si se desea conocer el costo que tuvo una cierta mercadería que egresa de un depósito, más allá del costo de reposición, luego existen técnicas como la de PEPS (primero entrado, primero salido). Estas propiedades pueden estimarse en base a los registros que quedaron en las novedades de ingreso y egreso (fechas, costo al momento de ingreso, etc) sin tener que estar obligados a que un cierto lote contenga esas propiedades.
Productos cuya existencia debe administrarse por lotes.
Existen razones por las cuales se debe mantener identificados grupos de individuos. Una muy típica es el vencimiento: por ejemplo, un lote de tarros de aceite lubricante tiene un vencimiento que se encuentra más próximo a ocurrir que otro. Al tener que usar aceite lubricante debe existir un proceso que automáticamente proponga utilizar el aceite del lote más próximo a vencer.
Otra razón es la existencia de mercadería con retazos (más allá de los fluidos): por ejemplo barras de acero de varios metros de longitud que pueden fraccionarse. O tela: si por ejemplo se dispone de 10 metros de una cierta tela, es necesario conocer si esos 10 metros están compuestos por un solo tramo o por dos tramos, uno de 4,4 y otro de 5,6 metros, ya que, si se necesitan 7 metros, en la existencia están disponibles pero hay que saber que no se encuentran en un solo tramo.
Para estos productos la novedad a informar al sistema no sólo debe ser la cantidad, sino de qué lote proviene esa cantidad y en cuántos lotes se presenta esa cantidad.
Productos cuya existencia debe administrarse por lotes unitarios o nro. de serie.
Ciertos productos deben conservarse durante su gestión logística con propiedades únicas. Tal es el caso de equipos con un nro de serie, como pueden desde teléfonos celulares y notebooks hasta automóviles.
Muchas son las razones que llevan a la necesidad de mantener cada individuo identificado, como pueden ser ciertos términos de garantía, elevado precio, propiedades únicas de cada individuo, trazabilidad, etc.
En un modelo logístico es posible dar a estos productos un tratamiento similar al modelo por lotes pero llevado a un extremo: lotes unitarios o lotes de cantidad uno.
La novedad a informar en estos casos es simplemente cuál es el nro. de serie o identificador único de lote unitario.
Productos que no requieren administrar existencia.
Esta es una omisión muy común en los sistemas logísticos: dar la oportunidad a tener mercadería sin existencia.
Hay ciertos productos que por ejemplo por su alta rotación, gran cantidad y bajo costo, son más costosos de administrar su existencia que ignorarlos. En ese caso puede armarse un modelo que ignore la existencia de esos productos y los considere siempre disponibles.
También estos productos son muy útiles a la hora de usarlos para representar servicios, por ejemplo en una novedad de existencia puede ocurrir esta salida:
- 2 unidades Repuesto A, nros de serie X e Y
- 10 unidades del Repuesto B a granel
- 1 servicio de instalación y puesta en marcha
El no considerar este tipo de productos puede provocar “ruido” en la base de datos, perdiendo valor la misma. Es muy típico pedir listados de existencia valorizados y que los totales se vean disminuidos por cantidades en negativo de productos que no requieren administrar existencia.
Eventos típicos que provocan un cambio logístico
de Entrada:
- Arribo de mercadería desde otra área (interna o externa, por ejemplo por compra).
- Devoluciones (también un tema olvidado por los “sistemas informáticos”) y cambios.
- Entrega de mercadería vendida.
- Cambios
- Eventos especiales como rotura, vencimiento, robo
- Confección de un combo.
- Desarmado de un bulto / presentación / combo.
- Transferencias a otras áreas.
Es muy importante que la cuestión operativa sea lo más ágil posible teniendo en cuenta que todas las novedades queden registradas en el sistema informático de la manera más natural, para acompañar al procedimiento diseñado.
En modelos de existencia como el del ERP Regente, de Bircher y Asociados, todo queda simplificado a la confección de “remitos digitales” por los cuales el sistema, manual o automáticamente, deja evidencia de la novedad ocurrida.
La filosofía del modelo de los “remitos digitales”, está inspirado en el uso tradicional del remito de talonario, resultando muy sencillo de aprender para cualquier persona.
Estos remitos digitales, tienen tres partes fundamentales:
- Origen: (interno o externo) área desde la cual proviene la mercadería.
- Contenido: detalle de la mercadería con novedad, incluyendo todos los datos necesarios de lote.
- Destino: (interno o externo) área a la cual se agrega la mercadería.
Independientemente del soporte tecnológico o manual, un evento típico consta de esos pasos:
- Se decide trasladar mercadería de un punto de depósito a otro: para eso un responsable confecciona un remito.
- La mercadería es trasladada, quizá con una copia del remito: si por ejemplo el traslado implica distancias importantes, seguramente que esa mercadería está ubicada en algún medio de transporte.
- Cuando la mercadería llega, el responsable del área destino controla lo que está a punto de recibir y sólo va a firmar el remito si está de acuerdo en que la mercadería se encuentra según las condiciones del documento que está a punto de firmar. En cualquier otro caso quizá firme con alguna disconformidad, rechazando parte o toda la mercadería (para un soporte tecnológico como el de Regente, la firma es digital).
Tal es el caso de un punto de venta unipersonal, en el cual la misma persona es la que está asesorando a un cliente, cerrando la venta, facturando, etc. En esos casos puede configurarse el modelo para que el remito de salida por venta sea disparado automáticamente (y silenciosamente) durante la transacción de impresión fiscal de la factura por ejemplo.
Explotación de la información
Una vez resuelta la cuestión operativa necesaria, surge el verdadero valor de una organización logística como es el hecho de poder contar de manera oportuna con información de existencias. Por ejemplo:
- Que un vendedor tenga la certeza de lo que tiene disponible para ofrecer.
- Que un responsable de compra pueda utilizar un asistente para armar las órdenes de compra.
- Que la dirección cuente con información actualizada y procesada para tomar decisiones estratégicas, basándose en valorizaciones, índices de rotación, pronósticos, etc.
- Toda novedad de existencia debe quedar registrada (movimiento interno o externo) (origen, destino, mercadería y cantidad, fecha / hora, responsable, documentos relacionados si los hay).
- Para no generar carga burocrática, se debe disponer de mecanismos (por ejemplo un sistema informático) que permitan registrar la novedad de manera natural, automática, segura y sin errores.
- Recordar siempre que lo que se plasma en un sistema informático es un “modelo”, así que por ejemplo, a los fines de una solución, cierta mercadería con vencimiento, considerando los índices de rotación incluso más pesimistas, puede administrarse como “a granel”.
- Simplificar ese modelo lo más posible (por ejemplo: si dos áreas están físicamente contiguas y tienen un mismo responsable, considerarlas como una sola; etc).
- Que haya un responsable por cada lugar físico donde se va a almacenar mercadería (área). Considerar a la existencia como un “valor” o la caja de un cajero: así como un cajero es el único que puede ingresar o tomar valores de su caja, igualmente un responsable de existencia se siente más tranquilo si es el único responsable de los movimientos de su sector. Esto se logra definiendo áreas de existencia con responsables y únicos autorizados a modificar su existencia, junto con áreas de intercambio que son “libres” (es decir que todos pueden ingresar y quitar mercadería de ahí: típicamente estas áreas de stock son los transportes).
- Definir un método para identificar unívocamente los artículos (por ejemplo utilizando códigos de barra o rfid con lectores; aplicando una política de dar nombres a los productos unificada y coherente, conociendo los “códigos de repedido” de cada proveedor, etc). Incluso si el proveedor no tiene resuelta la cuestión de la identificación de los productos, disponer de un mecanismo, como la generación de códigos de barra ean13 internos de Regente, para suplir esa falta.
- Para mercaderías “enteras” (cuya cantidad se administra con números enteros por ejemplo) perseguir un objetivo de total precisión, es decir, que al hacer una auditoría en cualquier momento, la existencia coincida de manera exacta.
- Por otro lado, para mercaderías “no unitarias” o con “mermas” (por ejemplo, venta al peso con fraccionado, fiambres y carnes, fluidos, etc) perseguir un objetivo “con tolerancias”, es decir, tener por ejemplo el objetivo de conocer la existencia con un más menos 10% de margen de error.
- Impedir existencia negativa en ciertas áreas del modelo: por ejemplo para vendedores que ofrecen los productos desde su escritorio, sin visualizar la existencia de lo que venden, lo mejor es no permitir existencias negativas y trabajar con un servidor centralizado en modo transacción.
- Permitir existencia negativa en otras áreas del modelo: Si por el contrario se trata por ejemplo de un autoservicio, la existencia como dato pierde importancia crítica al momento de disponer del producto ya que la mercadería ha sido elegida por el cliente y la tiene en su poder. Es un absurdo que el sistema indique que “no hay existencia suficiente” con el cliente delante del punto de venta y la mercadería en su mano. Para estos casos y en instalaciones grandes, pueden usarse servidores descentralizados con posibilidad de trabajo desconectado y latencia. Otras razones por la cuales pueden permitirse existencia negativa en ciertas áreas: puede ocurrir que llegue una mercadería y el responsable de depósito envía “a góndola” los productos para no perder un minuto más en su venta. Recién luego de hacer el envío termina de controlar el ingreso y le da ingreso. En ese lapso, si se vende algo de esa mercadería, puede producirse existencia negativa. También puede ocurrir por error la existencia negativa y debería tolerarse: por ejemplo cuando accidentalmente se identifica incorrectamente un producto y se le da salida con otro nombre.
Ing. Pablo Giancarelli
http://www.bircherasociados.com.ar
Suscribirse a:
Entradas (Atom)