Saltar al contenido principal
Página

Tema 2.2 - Conceptos

Just-in-time (JIT) o Justo a Tiempo

La fabricación Justo a Tiempo (JIT), también conocida como producción justo a tiempo o el sistema de producción Toyota (TPS), es una metodología dirigida principalmente a reducir los tiempos de flujo  dentro de la producción, así como los tiempos de respuesta de los proveedores y los clientes.

Siguiendo su origen se desarrollo en Japón, en gran parte en los años 60 y 70 y particularmente en Toyota. JIT permite reducir costos, especialmente de bodega de materias, partes para el embalaje y de  los productos finales.

La esencia de JIT es que los insumos llegan a la fábrica, o los productos al cliente, "justo a tiempo", eso siendo poco antes de que se usan y solo en las cantidades necesarias. Esto reduce o hasta elimina la  necesidad de almacenar y luego mover los insumos de la bodega a la línea de producción (en el caso de una fábrica).


Sistema de Producción Toyota (SPT) 

El Sistema de Producción Toyota (SPT) (Toyota Production System o TPS en inglés), es un sistema integral de producción "Integral Production System" y gestión surgido en la empresa  japonesa automotriz  del mismo nombre.

En origen, el sistema se diseñó para fábricas de automóviles y sus relaciones con proveedores y consumidores, sin embargo, este se ha extendido hacia otros ámbitos. Este sistema es un gran precursor  para el genérico Lean Manufacturing.

El desarrollo del sistema se atribuye fundamentalmente a tres personas: el fundador de Toyota, Sakichi

Toyoda, su hijo Kiichiro y el ingeniero Taiichi Ohno, quienes crearon este sistema entre 1946 y 1975.

Originalmente llamado "Producción Justo-a-tiempo”. Los principios principales de SPT son mencionados en el libro "La Manera de Toyota".


Kaizen

Kaizen, japonés para "mejora".

Cuando se utiliza en el sentido comercial y se aplica al lugar de trabajo, Kaizen se refiere a actividades que mejoran continuamente todas las funciones e implican a todos los empleados desde el CEO a los  trabajadores de la línea de montaje.

También se aplica a procesos, tales como compras y logística, que cruzan los límites de la organización en la cadena de suministro. Se ha aplicado en la asistencia sanitaria, psicoterapia, entrenamiento de  vida, gobierno, banca y otras industrias.


BIMODAL - Gartner


Bimodal está ocurriendo.

Si intentas aplicar los convenios de seguridad del modo 1 en las iniciativas del modo 2, serás sobrepasado y la empresa quedará expuesta a riesgos insostenibles.

Para 2019, el 30 % de CISCOs adaptará las prácticas de gestión de riesgos, apoyará la TI bimodal y mejorará las tasas de éxito del modo 2, al tiempo que reducirá los costos. 

Fuente: http://www.gartner.com/it-glossary/?s=Bimodal



IT Bimodal: Dos enfoques distintos pero coherentes, bastante diferentes, ambos esenciales.



DevSecOps

DevOps tiene una relación nada fácil con seguridad.


Si DevOps no presta atención a la seguridad puede facilitar la rápida introducción de las vulnerabilidades.


Nuevo Modelo Operacional


Scrum


Scrum es un marco para desarrollar y mantener productos complejos. Consiste en roles Scrum, eventos, artefactos y las reglas que los unen.

Ken Schwaber y Jeff Sutherland desarrollaron Scrum. 


Work-in-Progress (WIP) (Trabajo en Proceso)

Un límite WIP (work in progress) es una estrategia para prevenir cuellos de botella en el desarrollo de software.

Se acuerda por el equipo de desarrollo trabajar en progresos limitados antes de que un proyecto comience y sean ejecutados por el facilitador del equipo.

Por ejemplo, un equipo puede dividir las tareas que deben realizarse para una característica en el diseño, código, prueba y despliegue. Cuando se alcanza un límite WIP para una determinada tarea, el  equipo se detiene y trabaja en conjunto para eliminar el cuello de botella. El objetivo de trabajar de esta manera es asegurar que todo el equipo se apropie del proyecto y produzca códigos de alta calidad. 


Acuerdo de Nivel de Servicio (SLA) y OLAS

Un Acuerdo de Nivel de Servicio (Service-level agreement o SLA) se define como un compromiso oficial que prevalece entre un proveedor de servicios y el cliente.

Aspectos particulares del servicio (calidad, disponibilidad, responsabilidades) son acordados entre el proveedor de servicios y el usuario del servicio.

Acuerdos de Nivel Operacional (Operational-level agreements u OLAs) pueden ser utilizados por grupos internos para apoyar SLAs.


Ciclo Plan-Hacer-Verificar-Actuar (Plan-Do-Check-Act Cycle/PDCA Cycle)

PDCA (Planear-Hacer-Verificar-Actuar o Planear-Hacer-Verificar-Ajustar) es un método de gestión de cuatro pasos iterativo utilizado en los negocios para el control y la mejora continua de procesos y  productos.

También se conoce como círculo/ciclo/rueda de Deming, ciclo de Shewhart, círculo/ciclo de control, o planear-hacer-estudiar-actuar (PDSA).


Otra versión de este ciclo PDCA es OPDCA. El "O" agregado para la observación o como algunas versiones dicen “Comprender la condición actual”. Este énfasis en la observación y la condición actual  tiene relación con la fabricación Lean o la literatura del sistema de producción de Toyota.


Definición de Listo (en Agile/Scrum)

Definición de “Listo” Cuando un artículo o Producto Backlog o un Incremento se describe cómo “Listo”, todo el mundo debe entender lo que significa “Listo”.

Aunque esto varía considerablemente según el Equipo Scrum, los miembros deben tener un entendimiento compartido de lo que significa que el trabajo sea completo, para asegurar la transparencia.

Esta es la definición de “Listo” para el Equipo Scrum y se utiliza para evaluar cuándo se completa el incremento del trabajo. La misma definición guía al equipo de desarrollo para saber  cuántos elementos  de la cartera de productos se pueden seleccionar durante una planificación de Sprint.

El propósito de cada Sprint es entregar Incrementos de funcionalidad potencialmente liberable que se adhieran a la definición actual del Equipo de Scrum de “Listo”.


Kanban para Equipos DevOps

El método Kanban puede ayudar a los equipos de DevOps a poner un poco de orden en su trabajo diario y la teoría Lean definitivamente puede ser apalancada para mejorar el flujo a través de los  equipos de DevOps.


Última modificación: viernes, 13 de agosto de 2021, 07:30