¿Cómo funciona la teoría de las restricciones en TI?

Answer 1

Además de lo que Bill Hagner ya respondió correctamente, hay muchos otros libros relacionados:

* El libro Reaching the Goal de John Arthur Ricketts se centra en TOC para servicios, con muchas referencias de IBM (el autor todavía trabaja allí)
amazon.com
Alcanzar el objetivo: cómo los gerentes mejoran un negocio de servicios usando la teoría de restricciones de Goldratt (edición en rústica) (IBM Press): John Arthur Ricketts: 9780132565417: Amazon.com: Libros
* David J. Anderson escribió mi favorito en gestión de proyectos de software.
Gestión ágil para ingeniería de software: aplicando la teoría de restricciones para los resultados de negocios: David J. Anderson: 0076092024415: Amazon.com: Libros ”
* Clark Ching escribió una gran novela de negocios en el estilo puro de Goldratt.
Amazon.com: Rolling Rocks Downhill: Cómo enviar TUS proyectos de software a tiempo, siempre (9781505446517): Clarke Ching: Libros

Mi resumen personal: funciona muy bien, pero fue muy difícil para mí averiguar cómo aplicar TOC en mi negocio de servicios. Una vez que empecé a descubrir cómo, en retrospectiva, era obvio. Luego, después de leer los libros anteriores, parece casi trivial (nunca realmente trivial)

Answer 2

La Teoría de las Restricciones (TOC), desarrollada por Eliyahu Goldratt en varios libros sobre el tema que hacen reflexionar al respecto, proporciona un marco para impulsar la eficiencia de los procesos al concentrar los esfuerzos de gestión únicamente en reducir el tiempo necesario (es decir, llevar más producción). restricción “(o factor limitante) en el proceso. En cualquier punto, un proceso tendrá muy pocas restricciones, y posiblemente solo una. Una vez que una restricción se ha “roto” (la eficiencia ha aumentado en la medida en que la restricción anterior ya no es el factor limitante que ralentiza el resto del proceso), otro punto en el proceso se convierte en la nueva restricción (y la nueva área de enfoque).

En su excelente libro The Phoenix Project, Gene Kim, Kevin Behr y George Spafford extienden TOC explícitamente a IT y DevOps. Ellos “mapean” las operaciones de TI para trabajar en el piso de la planta (¿quizás exagerando la analogía para algunos?), Discuten el objetivo de mejorar el rendimiento mediante la reducción del trabajo en progreso (WIP) y desarrollan con cierta profundidad el concepto de Persona específica (un “Brent”) que actúa como la restricción en / de numerosos procesos.

No soy un experto en TOC de ninguna manera, pero disfruto leyendo y pensando en ello. Y encontré que la asignación de TOC a TI en The Phoenix Project bien vale la pena leer en la asignación de la Teoría a una dimensión no obvia.

Alerta de spoiler:
“¿En realidad no está sugiriendo que esto se aplique también a TI? Eso al detener todo el trabajo, excepto a Phoenix, reduciremos la cantidad de WIP en TI, y que esto mejorará de alguna manera el rendimiento de la fecha de vencimiento. estás sugiriendo? ”