La historia es real, lo vi con mis propios ojos.
Durante varios años, un chico, al igual que muchos de ustedes, trabajó como programador. Por si acaso escribiré así: "programador". Porque él era un especialista en 1C, en una empresa de fabricación.
Antes de eso, probó diferentes especialidades: 4 años como programador en una franquicia, gerente de proyectos, logrando cerrar hasta 200 horas, al mismo tiempo recibiendo un porcentaje del proyecto, por la supervisión y dedicándose un poco a las ventas. Intentó desarrollar productos por su cuenta, fue jefe del departamento de TI en una gran empresa con 6,000 empleados, probó diferentes opciones para aplicar su profesión en comillas: programador de 1C.
Pero todas estas posiciones eran bastante estancadas, principalmente por los ingresos. Todos nosotros en ese entonces ganábamos aproximadamente el mismo dinero, trabajábamos en las mismas condiciones.
A este chico le intrigaba cómo podía ganar más dinero, sin dedicarse a las ventas y sin crear su propio negocio.
Se creyó un genio y decidió encontrar un nicho en la empresa donde trabajaba. Este nicho debía ser algo especial, no ocupado por nadie. Y quería que la empresa misma quisiera pagar dinero a alguien en este nicho, para no tener que engañar a nadie o maquillar nada. Que fuera objetivo: una persona en esta posición debería ser bien remunerada. Un loco, por así decirlo.
La búsqueda no fue larga. En la empresa donde este chico trabajaba, había un nicho completamente libre que se podría llamar 'organización de los procesos de negocio'. En cada empresa hay una cantidad de problemas. Siempre hay algo que no funciona, y no hay nadie que venga y corrija el proceso de negocio. Así que decidió probarse como especialista que podría ayudar al propietario a resolver sus problemas con los procesos de negocio.
En ese momento, llevaba seis meses trabajando en la empresa y recibía un salario promedio en el mercado. No tenía nada que perder, especialmente porque podría encontrar un trabajo similar en una semana. En resumen, este chico razonó que no pasaría nada grave si, de repente, no funcionara y lo despidieran.
Se armó de valor y se presentó ante el propietario. Le propuso mejorar el proceso más problemático de la empresa, que en ese momento era la gestión de inventarios. Ahora, a todos los que trabajan en esta compañía, incluso les da vergüenza recordar esos problemas, pero las auditorías que se realizaban cada trimestre mostraban discrepancias entre el sistema contable y los saldos reales de hasta decenas de por ciento. Tanto en valor como en cantidad y en número de artículos. Era un desastre. La empresa realmente tenía saldos correctos en el sistema contable solo cuatro veces al año: al día siguiente de la auditoría. Este proceso fue el que nuestro chico empezó a controlar.
El chico llegó a un acuerdo con el propietario para reducir las discrepancias en los resultados de las auditorías a la mitad. Además, al propietario no le quedaba mucho que perder, porque hasta nuestro héroe, varios empleados habían intentado corregir la situación, y en general se consideraba que la tarea era prácticamente irresoluble. Todo esto despertó un gran interés, porque si lograba tener éxito, automáticamente se convertiría en alguien que sabe poner orden y resolver problemas difíciles.
Así que se enfrentaba a la tarea de reducir las discrepancias en los resultados del inventario a la mitad en el transcurso de un año. Al inicio del proyecto, no tenía idea de cómo lograrlo, pero entendía que la gestión de inventarios es algo sencillo, así que de alguna manera lograría hacer algo útil. Además, reducir las discrepancias de decenas de por ciento a un solo dígito no parece tan difícil. Todos los que trabajan en consultoría o en actividades similares saben que la mayoría de los problemas del proceso se resuelven con acciones bastante simples.
Desde enero hasta mayo, se preparó, automatizó algunos procesos, reescribió el proceso de gestión de inventario, cambió los flujos de trabajo de los almacenistas, contadores y, en general, reestructuró todo el sistema, sin mostrar ni contar nada a nadie. En mayo, distribuyó nuevas instrucciones a todos y, tras el primer inventario del año, comenzó una nueva vida: el trabajo bajo sus reglas. Para observar el resultado, la empresa comenzó a realizar inventarios con más frecuencia: cada dos meses. Los primeros resultados fueron positivos, y al final del año, las variaciones en los resultados del inventario habían caído a fracciones de un por ciento.
El éxito fue colosal, pero no se confiaba en su sostenibilidad. El chico dudaba que el resultado se mantendría si se alejaba y dejaba de observar el proceso. Sin embargo, el resultado estaba ahí, y el chico obtuvo todo lo que había acordado con el propietario. Luego, pasados unos años, la sostenibilidad del resultado se confirmó: durante varios años, las variaciones se mantuvieron dentro del 1%.
Entonces decidió repetir el experimento y propuso al propietario mejorar otro proceso problemático: el suministro. Allí había déficits que impedían enviar los volúmenes que nuestros clientes deseaban. Acordaron que, en un año, los déficits se reducirían a la mitad, y el chico también realizaría de 10 a 15 proyectos relacionados con 1C, sobre la automatización de diferentes procesos de negocio y otras cuestiones.
En el segundo año, nuevamente todo se logró con éxito, los déficits se redujeron a más de la mitad, todos los proyectos de TI se completaron con éxito.
Dado que el salario ya satisfacía completamente todas las necesidades de ese chico para unos dos años hacia adelante, decidió estabilizarse un poco, tranquilizarse y sentarse en un lugar cálido y cómodo, que él mismo había creado.
¿Qué representaba eso? Formalmente, era director de TI. Pero es difícil entender quién era realmente. Después de todo, ¿qué hace un director de TI? Por lo general, administra la infraestructura de TI, supervisa a los sysadmins, implementa sistemas ERP, participa en reuniones del consejo de administración.
Uno de los deberes clave de este tipo era participar en los procesos de cambio, y principalmente — generar e iniciar estos procesos, buscar y proponer soluciones, aplicar nuevas metodologías de gestión, evaluar los cambios propuestos, analizar la efectividad de otras funciones y departamentos, y finalmente — participar directamente en el desarrollo estratégico de la empresa, hasta el punto de desarrollar de forma independiente el plan estratégico de toda la compañía.
Le dieron carta blanca. Podía asistir a cualquier reunión a la que anteriormente no tenía acceso. Se sentaba allí con un cuaderno, anotando algo o simplemente escuchando. Hablaba poco. Luego empezó a jugar en su teléfono, afirmando que así trabajaba mejor su memoria asociativa.
En las reuniones rara vez aportaba algo útil. Se iba, pensaba, y luego llegaba un correo: crítica, opinión, propuestas o una descripción de las soluciones que ya había aplicado.
Pero más frecuentemente organizaba las reuniones él mismo. Encontraba un problema, ideaba soluciones, identificaba a las partes interesadas y llevaba a todos a la sala de negociaciones. Y allí — hacía lo que podía. Convencía, motivaba, argumentaba, discutía, lograba.
Oficialmente, era considerado la tercera persona en la empresa, después del propietario y del director. Por supuesto, molestaba muchísimo a todos los 'grandes' de la empresa, empezando por el número 4. Especialmente por sus jeans rasgados y camisetas brillantes, además de — el tiempo del propietario.
El propietario le dedicaba 1 hora al día. Cada día. Hablaban, discutían problemas, soluciones, nuevos negocios, direcciones de desarrollo, indicadores y eficiencia, desarrollo personal, libros y simplemente — la vida.
Pero este chico era extraño. Se suponía que debía sentarse y disfrutar, que la vida había salido bien. Pero no. Decidió reflexionar.
Se preguntó: ¿por qué a él le había funcionado y a otros no? El propietario también lo instó, diciendo que quería que los demás también lograran organizarse, porque hay muchos gerentes, que por lo general se ocupan de la gestión operativa y la planificación estratégica, pero prácticamente nadie se ocupa de los cambios sistemáticos en sus procesos. Puede que en su descripción del puesto esté anotado que deben acelerar su proceso, aumentar su eficiencia, pero en la práctica, nadie se ocupa de ello. ¿Por qué sucede esto? A este chico también le intrigaba la razón, así que decidió hablar con todos esos gerentes.
Se acercó al subdirector de calidad y propuso implementar gráficos de control de Shewhart para que el producto fuera mejor que el japonés. Pero resultó que su colega no sabía qué eran los gráficos de control de Shewhart, qué era la gestión estadística de procesos, y solo había oído de refilón sobre la aplicación del ciclo de Deming en la gestión de calidad. Bueno...
Fue a otro subdirector y propuso implementar el controlling. Pero aquí tampoco encontró apoyo. Un poco más tarde, se enteró sobre la gestión de límites (boundary management) y propuso a todos los subdirectores implementar la parte sistémica de esta metodología para mejorar los procesos. Pero por más que habló, nadie parecía querer entender de qué se trataba. Quizás les parecía aburrido o demasiado complicado. Pero, de hecho, nadie se interesó.
En resumen, les contó todo lo que sabía y había aplicado en la empresa. Pero nadie lo entendió. Aún no comprenden por qué, por ejemplo, se logró corregir por completo el registro de inventario, qué tiene que ver el controlling y la gestión de límites.
Por último, llegó hasta sus programadores, que eran tres personas en total. Les habló sobre la gestión de límites, el controlling, la gestión de calidad, Agile y Scrum... Y para su sorpresa, todos lo entendieron e incluso pudieron discutir con él algunos detalles técnicos y metodológicos. Comprendieron por qué los proyectos de almacenamiento y aprovisionamiento tuvieron éxito. Y aquí se le iluminó la mente: de hecho, los programadores salvarán al mundo.
Se dio cuenta de que los programadores son los únicos que podrán entender correctamente, con el nivel de detalle necesario, los procesos de negocio.
¿Por qué ellos? En realidad, nunca encontró una respuesta clara. Solo formuló algunas insinuaciones en forma de tesis.
En primer lugar, los programadores conocen las áreas temáticas del negocio, y de hecho, las conocen mejor que cualquier otra persona en la empresa.
Además, los programadores realmente entienden qué es un algoritmo de proceso. Esto es importante porque los procesos de negocio son algoritmos, y los elementos en ellos pueden no estar alineados. Por ejemplo, en el proceso de aprovisionamiento en el que el chico trabajaba, el primer paso es la elaboración del plan de compras anual, y el segundo, la compra diaria. Estos pasos están conectados por una relación directa, es decir, se supone que según este algoritmo, las personas deben trabajar: elaborar el plan de compras anual y ejecutar la solicitud al mismo tiempo. El plan de compras anual se elabora una vez al año, mientras que la solicitud se presenta 50 veces al día. Allí termina el algoritmo, y sobre eso hay que trabajar. En realidad, pensó él, para los programadores, conocer los algoritmos es una ventaja competitiva, porque cualquier otra persona que no esté familiarizada con ellos simplemente no entiende cómo debería funcionar el proceso de negocio y cómo se puede representarlo.
Otra ventaja de los programadores, según el chico, es que tienen suficiente tiempo libre. Todos entendemos cómo un programador puede tardar tres veces más en una tarea de lo que realmente requiere, y pocos lo notarán. Esta es, de nuevo, una ventaja competitiva, porque para poner en orden algún proceso de negocio, se necesita tener mucho tiempo libre: pensar, observar, estudiar y probar.
La mayoría de los gerentes, según el chico, no tienen ese tiempo libre y se enorgullecen de ello. Sin embargo, en realidad, esto significa que una persona no puede ser efectiva porque no tiene tiempo para aumentar su eficacia: es un círculo vicioso. En nuestra cultura, estar ocupado está de moda, por lo que todo sigue donde estaba. Para nosotros, los programadores, esto es una ventaja. Podemos encontrar tiempo libre y reflexionar sobre todo.
Los programadores, decía él, pueden cambiar rápidamente el sistema de información. Esto no se aplica en todas las empresas, pero en todos los lugares donde trabajó, se podían realizar modificaciones como se deseara. Especialmente si no afecta el trabajo de nadie. Por ejemplo, podría implementar un sistema que mida en secreto las acciones de los usuarios y luego usar esa información para analizar la eficiencia del trabajo del departamento de contabilidad y rastrear el costo de la gestión contable.
Y lo último que recuerdo de sus palabras es que los programadores tienen acceso a una gran cantidad de información, ya que están dotados de acceso administrativo al sistema. Por lo tanto, pueden utilizar esta información en su análisis. Nadie más en una fábrica normal dispone de ese recurso.
Y luego se fue. Durante el período de aviso de dos semanas, lo obligamos a compartir su experiencia, porque queríamos continuar con el trabajo que él estaba realizando. Además, su puesto se iba a quedar vacante.
Durante unos días, lo sentamos en una silla, encendimos la cámara y grabamos sus monólogos. Le pedimos que hablara sobre todos los proyectos realizados, métodos, enfoques, éxitos y fracasos, causas y efectos, retratos de los directores, etc. No hubo muchas restricciones, ya que no sabíamos qué había en su cabeza.
En sus monólogos, por supuesto, había sobre todo tonterías y cosas graciosas; él estaba de muy buen humor, ya que se estaba mudando de un pueblo pequeño a San Petersburgo. ¿Y a dónde ir a trabajar en San Petersburgo? A Gazprom, por supuesto.
Pero conseguimos extraer algunas cosas útiles de sus monólogos. Les diré lo que recuerdo.
Así que, recomendaciones de ese chico. Para aquellos que quieran intentar poner orden en los procesos de negocio.
Para hacer este tipo de trabajo, en primer lugar, es necesario tener cierto nivel de "despreocupación". No hay que tener miedo de perder el trabajo, no tener miedo de arriesgarse, no tener miedo a los conflictos con los colegas. A él le resultaba fácil, porque comenzó su camino después de trabajar en la empresa solo medio año, y no tuvo tiempo de establecer contacto con nadie, ni siquiera planeaba hacerlo. Entendía que las personas vienen y van, y para él lo importante eran sus propios resultados y su evaluación por parte del propietario del negocio. Si sus colegas lo trataban bien o mal, eso le preocupaba poco en ese momento.
El segundo punto es que, desafortunadamente, para dedicarse eficazmente a este trabajo, es necesario aprender. Pero no hay que hacerlo a través de un MBA, cursos o instituciones, sino de manera autodidacta. Por ejemplo, en su primer proyecto, relacionado con el almacenamiento, actuó de manera intuitiva, sin saber nada más que lo que es la "gestión de calidad".
Cuando comenzó a leer literatura sobre los métodos para aumentar la eficiencia, descubrió las tecnologías que ya estaba aplicando. Él las utilizaba de manera intuitiva, pero resulta que no era una invención suya, todo ya estaba escrito hace tiempo. Pero perdió tiempo, mucho más del que habría invertido si hubiera leído el libro adecuado desde el principio. Aquí es importante entender que al estudiar un método específico, ninguno de ellos, ni siquiera el más avanzado, resolverá completamente los problemas de un proceso empresarial.
El segundo truco es que cuanto más métodos conozcas, mejor. Por ejemplo, en la antigua Japón vivía Miyamoto Musashi, uno de los esgrimistas más conocidos, autor del estilo de dos espadas. Estudió en alguna escuela con un maestro, luego viajó por Japón, enfrentándose a diferentes oponentes. Si el oponente era más fuerte, su viaje se detenía por un tiempo y Musashi se convertía en aprendiz. Como resultado, en unos pocos años adquirió habilidades de varias prácticas de diferentes maestros y formó su propia escuela, añadiendo algo personal. Al final, logró una maestría única. Aquí es lo mismo.
Claro, se puede actuar como consultores de negocios. De hecho, son gente excelente. Pero, por lo general, llegan para implementar algún método, pero no el que necesita el negocio. También nosotros hemos tenido situaciones tristes así: nadie sabe cómo resolver un problema y nadie quiere pensar en cómo solucionarlo. Comenzamos a buscar en internet o llamamos a un consultor, y le preguntamos qué puede ayudarnos. El consultor piensa y dice que hay que implementar la teoría de restricciones. Le pagamos por la recomendación, gastamos en la implementación, pero el resultado es nulo.
¿Por qué ocurre esto? Porque el consultor dijo que implementemos tal sistema, y todos estuvieron de acuerdo con él. Genial, pero un solo método no resuelve todos los problemas de un proceso empresarial, especialmente si no coinciden las premisas iniciales —las nuestras y las que se requieren para implementar el método.
En la práctica que el chico recomienda, hay que tomar lo mejor e implementarlo. No se trata de adoptar los métodos en su totalidad, sino de extraer sus características clave, sus aspectos destacados y prácticas. Y lo más importante es entender la esencia.
Tomemos, dijo él, por ejemplo, scrum o agile. En sus monólogos, el chico repitió muchas veces que no todos comprenden completamente la esencia de scrum. También leyó el libro de Jeff Sutherland, que algunos consideran "lectura ligera". Para él, fue una lectura profunda, porque uno de los fundamentos de scrum es la gestión de la calidad, y eso se menciona directamente en el libro.
Allí se habla sobre Toyota Production, sobre cómo Jeff Sutherland presentó scrum en Japón, cuán bien se adaptó allí y lo cerca que estuvo de su filosofía. Y Sutherland habló sobre la importancia del rol del scrum master, sobre el ciclo de Deming. El rol del scrum master es acelerar constantemente el proceso. Todo lo demás que hay en scrum —la entrega por etapas, la satisfacción del cliente, un listado claro de tareas para el período del sprint— también es importante, pero todo eso debe moverse cada vez más rápido. La velocidad de trabajo debe aumentar constantemente en las unidades en las que se mide.
Quizás aquí esté el problema en la traducción, porque nuestro libro se tradujo como "Scrum: un método revolucionario para la gestión de proyectos", pero si se tradujera literalmente el título en inglés, resultaría: "Scrum: el doble en la mitad de tiempo", lo que significa que incluso en el título hay una referencia a la velocidad como función clave de scrum.
Cuando este chico implementó scrum, en el primer mes la velocidad se duplicó sin cambios significativos. Encontró puntos para realizar cambios, modificó scrum a su medida para que funcionara mucho más rápido. La única pregunta que, como dicen en internet, surgió fue: "Hemos duplicado la velocidad, ahora queda por ver qué haremos con esa velocidad". Sin embargo, ese ya es un campo completamente diferente...
Además, personalmente recomendó varias metodologías. Las llamó fundamentales y esenciales.
La primera es boundary management.
Se enseña en «Skolkovo», según él, no hay otros libros o materiales. Tuvo la suerte de asistir a una conferencia de un profesor de Harvard que predica sobre la gestión de límites, así como de leer varios artículos en Harvard Business Review sobre las obras de Eric Trist.
La gestión de límites habla de la importancia de saber ver y trabajar con las fronteras. Las fronteras están por todas partes: entre departamentos, entre diferentes tipos de trabajo, entre funciones, entre el trabajo operativo y el analítico. Conocer la gestión de límites no revela verdades supremas, pero permite ver la realidad desde una perspectiva diferente: a través del prisma de los límites. Y, en consecuencia, gestionarlos: establecer límites donde sea necesario y eliminarlos donde estorben.
Pero más y con más frecuencia, él hablaba sobre el control. Era un tema en el que parecía obsesionado.
El control, en resumen, es gestión basada en números. Aquí, decía él, cada parte de la definición es importante: tanto «gestión» como «basada en» y «números».
En nuestra organización, decía él, tenemos problemas con los tres componentes del control. Especialmente considerando que están estrechamente interconectados entre sí y con otras partes del sistema empresarial.
Lo primero que está mal son los números. Son escasos y de baja calidad.
Una parte significativa de los números que tomábamos provino del sistema de información 1C. Así que, según él, la calidad de los números en 1C es inaceptable. Al menos, por la posibilidad de modificar datos retroactivamente.
Es evidente que la culpa no recae en los desarrolladores de 1C; ellos solo consideran las demandas del mercado y la mentalidad del contabilidad nacional. Pero para los fines del control, sería mejor cambiar los principios de trabajo de 1C con los datos en una empresa específica.
A continuación, los números de 1C, según él, pasan un procesamiento semi-manual, utilizando Excel, por ejemplo. Este tipo de procesamiento tampoco contribuye a la calidad de los datos ni a la rapidez.
Al final, alguien más revisa el informe final para no presentar accidentalmente números erróneos al director. En consecuencia, los números llegan al destinatario bonitos, verificados, pero muy tarde. Normalmente, después del final del período (mes, semana, etc.).
Y aquí, decía él, todo es muy simple. Si los números de enero te llegan en febrero, ya no puedes gestionar las actividades de enero. Porque enero ya ha terminado.
Y si las cifras se basan en la contabilidad y la empresa es simplemente una compañía común, con la presentación trimestral del IVA, el gerente recibe cifras relativamente adecuadas una vez al trimestre.
A partir de aquí es claro. Reciben cifras una vez al mes: tienen la oportunidad de gestionar según las cifras (es decir, realizar el control) 12 veces al año. Practicando la contabilidad trimestral, gestionan 4 veces al año. Además, un bono: la contabilidad anual. Una vez más al mando.
El resto del tiempo, la gestión, por regla general, se realiza a ciegas.
Cuando (y si) las cifras finalmente aparecen, entra en juego el segundo problema: ¿cómo gestionar en base a cifras? Sobre este punto de sus razonamientos, no pude estar de acuerdo.
El chico afirmaba que si el gerente nunca había tenido cifras, su aparición generará un efecto wow. Estará mirando y manipulando las cifras de una manera y de otra, convocará a las personas a la oficina, exigirá explicaciones e investigaciones. Después de jugar con las cifras, realizar análisis, amenazar a todos los empleados diciendo que 'ahora sí, no los dejaré en paz', el gerente muy rápidamente se calmará y dejará de lado este tema. No volverá a utilizar la herramienta. Y los problemas permanecerán.
Esto ocurre, decía él, debido a las competencias insuficientes del gerente. En control, principalmente. El gerente simplemente no sabe qué hacer con estas cifras. Qué hacer — lo sabe, cómo hacerlo — no. conHacer — es lo que se menciona arriba (reñir, jugar). Hacer — es un proceso de negocio diario.
Él afirmaba que todo es muy simple: la cifra debe convertirse en parte del proceso empresarial. En el proceso empresarial debe quedar muy claro: quién, qué y cuándo debe hacer algo cuando la cifra se desvía de la norma (cualquier variante — por encima del límite, por debajo del límite, fuera del corredor, presencia de una tendencia, incumplimiento de cuartiles, etc.)
Y aquí marcó el dilema clave: la cifra está presente, debe convertirse en parte del sistema empresarial para aumentar la efectividad de la gestión, pero... esto no ocurre. ¿Por qué?
Porque el gerente ruso no cederá un pedazo de su poder a un competidor.
Los competidores del gerente ruso — un proceso empresarial de calidad y funcionamiento, una motivación mutuamente beneficiosa bien pensada y una automatización adecuada —, lamentablemente, dejarán al gerente sin trabajo.
¿Es una tontería, no creen? Especialmente lo que dice sobre los líderes. Bueno, yo he contado, ustedes mismos decidan.
Un poco menos, pero aún así demasiado, en mi opinión, habló sobre Scrum.
Definitivamente, dijo que lean y traten de aplicar Scrum en la práctica. Si, dice, han leído pero no lo han intentado, consideren que no saben. Es mejor leer un libro, por ejemplo, de Sutherland, que artículos y todo tipo de guías (¿qué es esa tontería?) en Internet.
Scrum, dijo él, solo se comprende a través de la práctica y con mediciones obligatorias del volumen de trabajo realizado. Prueben personalmente los dos roles más importantes: el propietario del producto y el Scrum Master.
Es especialmente importante, según el chico, experimentar en la práctica el rol del Scrum Master, cuando pueden aumentar el volumen de tareas completadas en un sprint sin aumentar los recursos ni el costo del sprint.
Y también en su top estaba la TOC (Teoría de las Restricciones de Sistemas).
Estos son, según el chico, principios básicos y fundamentales para mejorar la eficiencia que se pueden aplicar prácticamente en cualquier área, en cualquier proceso de negocio y en el sistema empresarial en general.
Cuando se dio cuenta de que no estábamos familiarizados con la TOC, dejó de hablar. Solo añadió que no nos privaría del placer de leer los libros de Eliyahu Goldratt. Dijo algo similar a Scrum: lean y prueben. Tipo, en cualquier puesto en el que estén, no importa qué trabajo hagan, allí encontrarán oportunidades para aumentar la eficiencia con los métodos de la TOC.
Luego, parece que su repertorio de metodologías se agotó, y dijo: mezclen principios para crear soluciones aplicadas en situaciones concretas.
Eso, dice, es la principal recomendación, la clave del éxito. Entiendan los principios, la esencia, y creen soluciones aplicadas únicas: procesos de negocio y sistemas empresariales.
Luego intentó recordar alguna cita y al final tuvo que buscar en Internet. Resultó ser una cita del artículo 'Sobre los hombros de gigantes' de Eliyahu Goldratt:
«Hay una diferencia entre las soluciones aplicadas (aplicaciones) y las nociones fundamentales en las que se basan estas soluciones. Las nociones son generales, mientras que las soluciones aplicadas son una adaptación de las nociones a un entorno específico. Como hemos visto, dicha adaptación no es sencilla y requiere desarrollar ciertos elementos de la solución. Debemos recordar que la solución aplicada se basa en premisas (a veces ocultas) sobre el entorno específico. No hay que esperar que esta solución aplicada funcione en un entorno para el cual las premisas iniciales no son válidas».
Dijo que el trabajo de un programador y el de un «mejorador de procesos de negocio» son muy similares. Y se fue.
Fuente: habr.com
