Iceberg

Todos saben lo que es un iceberg: un gran trozo de hielo que flota en el océano. Todos recuerdan lo que está mal con el iceberg: solo una pequeña parte es visible, que está por encima de la superficie del agua, el resto está oculto. Y cuánto hay allí, este descanso, nadie lo sabe.

Una situación similar es con los datos en sistemas automatizados.

Usualmente vemos los datos en sí. Documentos, como facturas de entrega o recibo, transferencias, pagos, etc. Directorios: nomenclatura, contrapartes, unidades. Vemos las tareas, tanto ordinarias como de proceso. Vemos los restos: cuántos bienes hay en stock, quién nos debe dinero, cuántos déficits tenemos, etc.

Cualquier dato, individualmente o en combinación, forma un cierto estado. Por ejemplo, nuestro almacén, en todo momento, se encuentra en algún estado. Decimos que sí, el estado del almacén. O el estado de las cuentas por cobrar o por pagar, o el estado de las tareas, o el estado de los procesos.

Somos bastante capaces de evaluar instantáneamente la condición, tanto en un sistema automatizado como en la vida. Estimado, huir y olvidar.

Luego, después de un tiempo, nuevamente nos encontramos con los mismos datos o situación. Nuevamente hacemos una evaluación instantánea del estado: decimos "todo está bien" o "todo está mal". Esto se repite una segunda, tercera, ciento veinticinco veces.

Si evaluamos la situación como crítica, entonces, probablemente, la corregiremos de alguna manera. Y si no? Sí, la situación no es muy buena, pero parece que puedes vivir. Esto sucede a menudo en las reuniones operativas: alguien plantea una pregunta, cuenta la situación y realiza una evaluación. Todos gimen o hacen ruido y ... ¿qué? Como regla, se olvidan. Hasta la próxima, hasta que alguien más preste atención.

Cada vez que una situación negativa recibe indulgencia, porque la vemos como si fuera la primera vez. Alguien, por supuesto, recuerda: oh, ya sucedió, no recuerdo, como hace un mes, o tal vez seis meses. Golpean al portador de un recuerdo demasiado bueno para guardar silencio; dejemos que la situación se considere mejor como un bebé.

¿Por qué está pasando esto? ¿Qué falta en la información de la situación negativa? Hay una evaluación instantánea, bastante de alta calidad y detallada. ¿Cómo continuar la frase "todo está mal aquí", para que juegue con nuevos colores y se vuelva más informativa?

Es muy simple continuar la frase: "todo está mal aquí y durante mucho tiempo". El tiempo o la duración del estado es la información que se necesita para una decisión adecuada.

En la vida, todos entienden esto. Déjame darte un par de ejemplos.

"No tengo suficiente dinero": una evaluación instantánea requiere intervención quirúrgica. "No he tenido suficiente dinero durante un año" - wow, tenemos un problema sistémico aquí, en el que debemos pensar mucho y cambiar algo en la vida.

"Algo me duele la pierna", bueno, nunca se sabe, puede que haya cumplido su condena o que el clima afecte la artritis. "Mi pierna ha estado adolorida durante seis meses", corrió inmediatamente a la clínica.

“Un niño trajo un deuce”: bien hecho, ya es hora, se necesitan deuces para mantener el equilibrio. "Un niño solo trae dos para todo el trimestre" - oh, idiota es menor de edad, ¿qué haces allí? Mañana voy a la escuela, ¿dónde está el número de teléfono de tu maestro de clase?

Del mismo modo en los sistemas empresariales.

"El cliente nos debe un millón" - bueno, paga lo que molestas. "El cliente nos debe un millón por seis meses" - tu madre, ¿dónde miraste?

“Hay cinco posiciones urgentes en la declaración de déficit”: los compradores ordenarán, por lo que no se debe retirar a las personas. "Cinco posiciones urgentes han estado colgadas en una posición deficitaria durante dos meses", ¡por eso están cayendo las ventas! Arrastre con urgencia a todos a la alfombra, ¡compre de inmediato!

"Los programadores han retrasado mi tarea": ​​sí, todas son tareas, así que no se preocupen. Lo haré "Los programadores ya han retrasado mi tarea durante dos meses" - maldita sea, hace mucho que quería dispersar a estos imbéciles, ¿qué están haciendo allí?

Como puede ver, la duración de una condición, especialmente una negativa, le da a la información una nueva dimensión. Era como si hubiera información plana y aburrida con la que no estaba claro qué hacer, pero se obtuvo una imagen tridimensional. El análisis de la situación y la toma de decisiones se vuelve mucho más fácil.

Aquí todo es tan obvio que ni siquiera puedo creerlo: ¿valen la pena las banalidades en un capítulo separado del libro de texto? Para responder a esta pregunta, eche un vistazo a su sistema de información.

¿Encuentra muchas condiciones con duración medida? Tradicionalmente, hay dos informes basados ​​en el principio de Iceberg: activos ilíquidos y atrasos. ¿Por cierto, usted ve activos ilíquidos? No en todos, incluso en los sistemas comunes, se pueden ver activos ilíquidos.

Desafortunadamente, en los sistemas de información ni siquiera existe un concepto de "estado". Hay datos y medios para verlos, desde diferentes ángulos. Una extensión elegante para un analista al que le gusta hurgar en grandes conjuntos de números, pero no tiene suficiente información sensible para tomar decisiones. Además, no importa quién tome la decisión: la persona o el sistema en sí.

Hay varias formas de implementar el principio Iceberg. Tradicional: contabilidad por lotes, cuando se agrega un separador a la matriz de información, un documento por lotes. Por ejemplo, los productos llegaron al almacén; recordamos no solo la nomenclatura y la cantidad, sino también el documento de recibo: la factura. La factura tiene una fecha, y a partir de ella siempre podemos calcular la fecha de vencimiento. Hacen lo mismo, por ejemplo, con las cuentas por cobrar: almacenan no solo la contraparte y el monto, sino también el documento que creó esta deuda, por ejemplo, una factura de entrega o un anticipo al proveedor.

En términos técnicos, el documento del partido crea muchas dificultades.

En primer lugar, aumenta el número de registros en las tablas. Una entrada "Funda, 10 piezas" puede convertirse en diez entradas: "Funda 1 pc del 01/09/2017", "Funda 1 pc del 12/09/2017", etc.

En segundo lugar, se necesitan algoritmos de cancelación de lotes. Por ejemplo, al enviar (es decir, cancelar productos), debe saber desde qué lote menos el resto. O al pagar al comprador, debe indicar para qué documento de envío vino el dinero. Se utilizan dos enfoques: el cálculo automático de lotes o su indicación manual. La selección automática de lotes son las estrategias de cancelación conocidas de FIFO (primero, el primer lote) y LIFO (primero, el último lote). La identificación manual de lotes se usa comúnmente en la contabilización de pagos.

El tercer problema, más bien metodológico, es que la vida real no obedece al algoritmo de cancelación de lotes. El almacenista tomará la parte del estante, pero no la que seleccionó el programa. No sabe qué es FIFO.

Resulta un sistema técnicamente complejo, cuyos resultados rara vez se usan. No estoy hablando de contabilidad o contabilidad de gestión, que utiliza lotes para calcular el costo de las cancelaciones. Estoy hablando de medir la duración de un estado negativo: activos no líquidos. ¿Cuántos tuvo que ver procesos de trabajo reales, regulares y efectivos en activos no líquidos?

La segunda forma no es almacenar la duración de todos los estados, sino calcularla si es necesario. Esta es una estimación instantánea de la duración. Por ejemplo, uno puede encontrar activos ilíquidos en un almacén sin almacenar lotes. Hay muchas formas, por ejemplo, comprender los saldos actuales, mirar retrospectivamente el movimiento de mercancías. Si no hubo movimientos, delante de nosotros hay un activo ilíquido.

Este método no tiene las desventajas de la contabilidad por lotes: no requiere el almacenamiento de grandes cantidades de datos y no complica el trabajo actual. Pero la principal ventaja de la contabilidad por lotes (almacenamiento de duración) no está en ella. Usted ve una estimación de la duración solo instantáneamente, en un punto particular en el tiempo. Entramos, miramos, apreciamos, salimos: la evaluación de la duración desapareció.

Por un lado, está bien, está bien. Puede tomar un algoritmo para calcular la duración e incrustarlo en los procesos; deje que el sistema reaccione cuando el estado negativo se haya arrastrado. Pero, por desgracia, la estimación instantánea de la duración no es tan instantánea: los recursos del sistema se gastan en el cálculo, de modo que solo el ruido cuesta, cada minuto que no se ejecuta.

Se puede usar una estimación instantánea de la duración para procesos no muy importantes que no necesitan ser monitoreados todos los días. Por ejemplo, los mismos activos ilíquidos cuando construye el proceso de deshacerse de ellos: una vez al mes realiza cálculos, determina la lista de los artículos más acumulados y forma la tarea de deshacerse de ellos (por ejemplo, vender con descuento o desguace).

La tercera forma es calcular, separar, almacenar y rastrear el estado recortado.

Por ejemplo, tiene una declaración de déficit: una lista de bienes que necesita comprar. Para producción, ventas, reparaciones, etc. No tiene sentido monitorear todo el estado de déficit, posiciones bastante vencidas. Vale la pena resaltar estas posiciones pasadas, porque no habrá muchas.

Simplemente guarde en un lugar separado del sistema una lista de artículos vencidos, con cantidades y, lo más importante, la fecha de ocurrencia. Después de todo, ¿no siempre hay posiciones expiradas allí? Tan pronto como aparezcan, recuerde, y la fecha de aparición será el punto de partida de la duración.

Entonces el sistema hace todo por sí mismo. Revisa periódicamente el déficit: comprueba si hay posiciones expiradas. Si no, excelente, entonces el estado negativo se ha detenido. La lista guardada de posiciones vencidas puede olvidarse y eliminarse del sistema (aquí, a su discreción, puede dejarla en la memoria, es decir, para un análisis retrospectivo o un sistema de motivación). Si las posiciones expiradas aún son escasas, también es bueno (para el sistema), porque no necesita hacer nada, el tiempo corre y la duración está creciendo.

Una persona que supervisa un déficit vencido simplemente será feliz. En primer lugar, ya no puede vigilarlo, simplemente configure una notificación sobre el retraso. En segundo lugar, ya no necesita averiguar si el retraso ha aparecido durante mucho tiempo; la duración se mostrará automáticamente. En tercer lugar, no es necesario rastrear el momento de la desaparición retrasada: el sistema le avisará cuando las cosas salgan bien.

Será mucho más fácil para usted, como programador comercial, crear procesos de respuesta en un sistema comercial. Si bien no se comprende la duración, se ve obligado a tirar de la persona de inmediato, tan pronto como haya surgido un estado negativo. Y su "contracción" colgará constantemente delante de su nariz, como un trapo rojo.

Cuando hay una duración, la configuración se vuelve más fina: usted mismo elige el momento en el que debe mostrarle un problema a una persona. También puede elegir una pantalla a color en función de la duración del estado negativo. Por ejemplo, amarillo - un día, rojo - dos o más días, etc.

Al mismo tiempo, puede crear un sistema de respuesta ascendente. Por ejemplo, primero muestre el retraso en el déficit al proveedor. Un día después, si no se elimina, al jefe de suministro. Tres días después, al director comercial. En una semana - al director.

Además, usted comprende: su esencia depende del nivel al que se haya elevado la tarea. Usted le pide al proveedor que elimine la demora; debe ordenar el puesto. Pide al gerente de suministros que preste atención y, posiblemente, transfiera los puestos a otro proveedor. Usted le dice al director que todo el servicio de suministro funciona de alguna manera extraña, se necesitan cambios en el sistema.

Características clave de este método: almacenamiento separado de datos de estado y su actualización automática. Técnicamente implementado utilizando el principio de "Auto Task", que se discutirá más adelante.

En el proceso, seguramente encontrará otras formas de determinar la duración del estado, es decir, La magnitud del iceberg submarino. Es posible que esté programando en sistemas donde los métodos que he enumerado no funcionan, entonces debe buscar el suyo.

Lo principal: no se olvide del principio de "Iceberg" cuando programe un sistema comercial.

Especialmente si desea utilizar la contabilidad de particiones: debe relajarse durante el diseño, retrospectivamente, se implementa con gran dificultad.

Se puede incluir una evaluación instantánea de la duración, como las "Tareas automáticas", en cualquier momento. Bueno, apágalo también. En esta ligereza es su ventaja.

Daré algunos ejemplos del uso del Iceberg de mi práctica.

El primer ejemplo son los sistemas de gestión de tareas. Hay una tarea, una tarea o una nota. Hay un iniciador, hay un intérprete. Cuando la tarea es aceptada en el trabajo, todo está claro: hay una fecha límite, y puede determinar rápidamente si todo lo relacionado con la tarea es bueno o no.

Pero el problema también tiene algunos estados intermedios. Por ejemplo, el iniciador lo escribió, lo envió y el ejecutor debe aceptarlo para trabajar. La aceptación en el trabajo es un cierto signo en una tarea. Hasta que el contratista lo deje, el estado de la tarea es la parte submarina del iceberg. No está nada claro cuando finalmente se digna a hacerlo.

Actué simplemente: agregué la fecha de aceptación para trabajar como un campo separado en la tarea. Aceptado: la fecha fue recordada. Y la fecha de envío de la tarea al ejecutor ya está allí. En consecuencia, obtenemos dos duraciones de un estado negativo. Hasta que se acepte la tarea, la duración es la diferencia entre la fecha actual y la fecha de envío. Sin embargo, cuando el contratista lo aceptó, aparece el intervalo exacto entre la aceptación y el envío, que se recuerda para siempre en el sistema y se utiliza para su posterior análisis.

Una situación similar, con una duración incomprensible, ocurre cuando el contratista hizo el trabajo y lo envió al iniciador para su verificación. Cuando verifica allí, no se sabe. Cualquier programador decente que trabaje directamente con el usuario final confirmará que las tareas a menudo se congelan en la prueba. Además, físicamente ya se puede verificar, al usuario le gusta todo, pero no se molesta en iniciar sesión en el sistema y hacer una nota.

La solución es similar. Agregamos dos fechas a la tarea: cuando el contratista envió para la verificación, y cuando el iniciador reaccionó, aceptó el resultado o regresó para su revisión. En consecuencia, la duración del estado de verificación siempre está a la mano, y podemos normalizar el tiempo de verificación de la tarea. Bueno, entonces no fue así.

Mi ejemplo favorito es la adquisición. Todo es simple con las tareas: siempre hay un objeto en el que se graba esta misma tarea, y puede agregar campos a este objeto que almacenan datos sobre la duración del estado.

Y la adquisición es una corriente. Nadie allí, en su sano juicio, planteará tareas separadas. Bueno, imagínate a ti mismo: una niña está sentada, ordenando bujes. Todos los dias Los mismos bujes. Y también ejes, pernos, tuercas, metal, forjas, estampados, etc.

Solo hay información sobre lo que debe pedirse. Sí, ocurre en diferentes niveles de detalle, a veces solo una lista de artículos y cantidades, a veces, por destinatarios, contratistas, pedidos, unidades, etc. Pero esta información siempre es instantánea, como un destello. Entré, ya ves, necesitas pedir 1020 piezas. Un minuto después entró, wow, ya son las 1200, porque la situación ha cambiado.

Los compradores entienden esto y lo aprovechan. En las reuniones, reuniones informativas y operativos, los compradores a menudo intentan llegar al fondo, pero desde ellos, como el agua de un pato. Les dicen: ¿eh, chicos, y qué casquillos faltan? Así que ayer, ¡solo surgió una necesidad! - Responde esos. Como es ayer Bueno ayer. ¡Juro que entré en escasez la mañana pasada, no había arbustos!

Para probar que las mangas fueron ayer, solo puedes levantar la copia de seguridad. Por supuesto, las personas vivas no recogerán copias de seguridad todos los días, por lo que los vendedores y fabricantes cansados ​​crean su propia versión del Iceberg: impresiones. Por ejemplo, ingresan al sistema el lunes, observan el déficit y lo imprimen. Cuando surja un problema, o ralladores con proveedores, muéstreles esta hoja de papel.

Pero es fácil esquivar ese pedazo de papel. Los vendedores dicen: ¿qué me estás metiendo aquí? Sí, el lunes no había suficientes mangas, ¿y qué? ¡Ya el martes había tantos que todos hubieran tenido suficiente! Y lo que ves en el sistema hoy surgió ayer.

Luego, también se ven obligados a participar en asuntos de papel: no solo imprimen una escasez, sino que también dan a los proveedores para su firma. Y las fechas de entrega se solicitan para fijar. Usted comprende que el proceso en términos de eficiencia es muy regular.

Principio Iceberg trabajó en tareas, pero no trabajó en el suministro. Los vendedores entendieron que había que hacer algo, y comenzaron a establecer tareas para compras: crearon directamente el objeto, le pusieron una lista de posiciones y esperaron la ejecución. Al principio comenzó a funcionar, luego los proveedores comenzaron a rechazar estúpidamente tales tareas, con un comentario como "no necesitamos poner instrucciones separadas para nuestro trabajo de rutina". En general, el comentario correcto es que si establece una tarea para todos, entonces los limpiadores deberán estar conectados al sistema.

El problema se resolvió mediante las tareas automáticas y Iceberg, que está allí por defecto. La autotask simplemente huele a un déficit, separa las posiciones faltantes por los artistas y forma algunos objetos que contienen información sobre lo que se debe ordenar a los proveedores. La fecha de formación automática de tareas se fija automáticamente, así como la fecha de ejecución, es decir. colocación de puestos con proveedores.

Si fue necesario, por ejemplo, 100 bujes, y el proveedor ordenó 70, entonces la autotask no se cierra, sino que simplemente se ajusta, ahora debe colocar 30 posiciones. Lo importante es la fecha de inicio del estado negativo, es decir El déficit sigue siendo el mismo. Una persona ordenó 70 puestos para un intervalo de tiempo y 30 para otro.

Con la aplicación del Iceberg, el problema se resolvió muy rápidamente, porque era imposible ocultar algo. Primero, la contabilidad de la duración del déficit se lleva a cabo en el contexto de posiciones y cantidades, y segundo, con referencia al contratista.Inmediatamente, por supuesto, nació un determinado KPI para el proveedor: qué porcentaje de los puestos solicita a tiempo (parece que tuvo que cumplir el día, desde el momento en que surgió la necesidad).

Iceberg cae bien en contabilidad. Para aquellos, después de todo, siempre hay algo mal en alguna parte. Los saldos negativos están presentes, en una variedad de cuentas o en registros que odian. Los avances no se cuentan, a pesar de la aplicación de la restauración de la secuencia de asentamientos. Sin mencionar los saldos totales sin cantidad, y viceversa.

En el estado normal del sistema, sin un Iceberg, es difícil llegar al departamento de contabilidad. La única forma de demostrar que las desventajas han estado suspendidas durante un mes es una copia de seguridad. Pero ellos tampoco son tontos: dirán que sí, hubo inconvenientes hace un mes, luego los eliminamos y ahora salieron nuevamente, son ustedes los programadores los que han mezclado algo. Si los proveedores simplemente se disculpan sin trasladar los problemas a otros, entonces los contadores han pensado durante mucho tiempo, no sé, conscientemente o no, un método como la presión artificial del tiempo.

Hay un programador decente en la empresa que se encarga del estado de la contabilidad. Él ve los contras en la parte de atrás y les dice a los contadores: queridas tías, ¿qué están haciendo? ¡Eliminémoslo! Al principio dicen: sí, por supuesto, lo eliminaremos, es en nuestro interés. Los contras nos dificultarán mucho al cerrar el trimestre, asegúrese de eliminar. En este momento, digamos, esto es mayo, no hay presión de tiempo, es decir Nadie tiene un tiempo limitado para resolver el problema. Por lo tanto, la tarea de restaurar el orden, como se esperaba, se pospone a la casilla distante.

Es casi imposible evitar la creación de residuos negativos mediante métodos de monitoreo del trabajo diario actual. Incluso si prohíbe las cancelaciones en negativo, hay una corrección de la parroquia. Por lo tanto, nuestro programador decente suspira y espera.

Antes de finales de junio, el programador, por ejemplo, le recuerda al contador varias veces que sería bueno eliminar los inconvenientes. Cuanto más se acerca la fecha límite, más agresiva se vuelve la respuesta: vete a la mierda, no es asunto tuyo, no nos enseñes cómo trabajar y, al final, desprecio total.

Y luego llegó julio, es necesario cerrar el trimestre. Ahora el problema debe resolverse en el modo de presión de tiempo, de la manera más rápida y eficiente posible, porque todavía hay muchas cosas que hacer, excepto las desventajas. Si trabajó como programador en la fábrica, entonces sabe lo que está sucediendo en este momento: la tarea pasa rápida y bellamente de la contabilidad a los programadores.

Es demasiado tarde para indignarse, aunque los programadores lo intentan. Pero los contadores dan argumentos de hierro: todo, una vez, es necesario entregar los informes, y hay muuuchas multas que la compañía tendrá que cerrar. No queda nada para el líder que modera el abuso del programador y el contador sobre cómo ponerse del lado de este último: la amenaza parece demasiado real. El programador tiene algo de lloriqueo, como este es el trabajo de un contador, sabe qué hacer y, en general, un programador le cuesta a la compañía tres veces más que un contador, y todo esto está mal, pero es demasiado tarde, se ha creado un problema de tiempo artificial.

Por lo general, termina así: el programador acepta arreglar las desventajas con sus propias manos, y el gerente y el voto contable prometen abordar este problema sistémico después de eliminar la presión del tiempo. Y así, cada vez.

La solución al problema es similar a la oferta. Hacemos tareas automáticas para cada variante de la jamba; por ejemplo, calculamos y mostramos las desventajas en el cambio, establecemos el responsable y, lo más importante, la fecha en que surgió la tarea para obtener el Iceberg. Ahora, tan pronto como aparece un signo negativo, aparece una tarea automática y puede usarse como argumento en disputas.

Está claro que la contabilidad ignorará estas tareas. Pero entonces aparecerá algo de lo que el programador carece en las reuniones con la gerencia: hechos. Aquí está la jamba, aquí está la fecha de su ocurrencia, aquí está la duración del estado negativo, un mes, por ejemplo. Lo principal es enviar correctamente la información: mire, querido líder, nuestra contabilidad ha estado en un estado incontrolable durante un mes, no tenemos idea de cuánto cuesta nuestro almacén, cuánto incurrimos en costos, porque tenemos desventajas. Usted entiende, querido líder, el punto no está en las desventajas, sino en relación con la contabilidad. Menos es una situación extrema, un error obvio y obvio. Y todavía hay algunos implícitos que no son visibles a la vista, pero que le privan de la oportunidad de usar los datos. Bueno y así sucesivamente.

Incluso Iceberg pregunta directamente por cualquier proceso donde haya acuerdo. Solicitudes para gastar dinero, contratos, especificaciones, presupuestos, planes, la emisión de ropa especial, etc., hasta el infinito.

Los burócratas aman la coordinación, pero no como un proceso que debe hacerse, sino como un proceso que puede retrasarse sin cesar. El ingenuo programador, a quien se le asignó la tarea de agregar la aprobación del contador principal o director financiero al contrato, actúa de manera simple y sin pretensiones: agrega un cierto campo, como "De acuerdo", a este contrato. No sabe sobre Iceberg, por lo que condena el proceso de negociación de acuerdos para una muerte lenta y dolorosa.

La coordinación será dinámicamente interminable si el contrato no es muy significativo y no está en el campo de visión del director. Y los iniciadores de los tratados no tendrán más remedio que acudir periódicamente al contador principal para averiguar cuándo sucederá el gran sacramento.

Iceberg resuelve el problema de forma inmediata y rápida. En este caso, es suficiente saber dos fechas: cuándo se envió para su aprobación y cuándo tuvo lugar. La duración del estado de inconsistencia en este caso se calcula de manera elemental, y esta vez puede normalizar trivialmente.

Lo hice con la coordinación de contratos, donde la cadena estaba compuesta por varias personas: el jefe de la unidad, el financiero, el contador y el abogado. A cada uno se le dio un día para su aprobación, y Iceberg elevó el porcentaje de visitas en este período al 90%.

Luego, sin embargo, el problema comenzó por otro lado: cuando el acuerdo se acordó y se firmó en papel, ambas copias se envían a la contraparte para que firme y selle su sello. En consecuencia, el trozo de papel debería volver a entrar en el archivo del departamento legal.

Pero las personas que previamente se habían quejado por la larga aprobación no tenían prisa en entregar los originales de los contratos a los abogados. En general, se olvidaron de ello: les basta con firmar el contrato y usted puede trabajar con la contraparte. Aquí los abogados aullaron: es imposible sin los originales, cualquier cheque se adaptará a la compañía tal Auschwitz que no parecerá suficiente.

En consecuencia, otro Iceberg pareció entregar los originales de los contratos. Asignado un mes para acuerdos ordinarios y 100 días para acuerdos de comercio exterior. Y todo funcionó. Especialmente cuando los abogados comenzaron a rechazar nuevos contratos hasta que los viejos fueron entregados. Una imagen del número y el momento de los contratos fallidos estaba constantemente disponible en el sistema y, en vista de la importancia de este problema, estaba bajo control constante de la administración. Nadie quiere entrar en la esfera de interés del director con demasiada frecuencia, por lo que entregaron los originales casi siempre a tiempo.