Inicio arrow Artículos - apuntes arrow Procesos: incompatibilidades y efectos secundarios Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Procesos: incompatibilidades y efectos secundarios
Valoración del artículo: / 45
MaloBueno 
19.04.2006
procesoLa teoría de los textos de administración de empresas sobre "procesos" y "organización centrada en procesos" debería incorporar una advertencia, que a modo de prospecto dijera algo así:
Incompatibilidades: La administración en empresas del conocimiento debe realizarse bajo la supervisión de un experto.
Efectos secundarios: En estas empresas, la administración en dosis o forma errónea puede producir mediocridad.

Las empresas de programación son el mejor ejemplo que conozco de empresas del conocimiento, y aplicar en ellas teoría de procesos porque "es lo que se lleva", o lo que me dijeron en el master es una barbaridad.

Producción industrial

Los modelos industriales emplean a personas, procesos y tecnología para inyectar valor en la materia prima y transformarla en producto. Los objetivos para este cometido son: conseguir la mayor cantidad de producto, con el mayor nivel de calidad posible de la forma más eficiente (con el menor coste).

Desde que en los 80 Michael Hammer levantara la liebre de los procesos, las tres últimas décadas han enseñado a las fábricas que el factor más eficiente para dar calidad de forma homogenea, predecible y escalable son los procesos; y que la mejor forma de aumentar la eficiencia es basando la producción en procesos, y mejorando la capacidad de éstos. Si el proceso y la maquinaria pueden llegar a comprender todo el know-how necesario, la persona queda como un operador de baja capacitación, barato y fácil de remplazar.

Políticamente no es correcto decir que el principal factor de la empresa son sus procesos, luego las máquinas, ordenadores o robots, y por último las personas. En las presentaciones corporativas se mencionará justo lo contrario; pero se puede hacer una prueba curiosa: teclear en Google la cadena entrecomillada "organización centrada en procesos" = 625 páginas. "organización basada en personas" = 4 páginas.

La Ingeniería de procesos y la producción basada en procesos han tomado el protagonismo. Su diseño, medición y mejora en ciclos tipo "PDCA" se han revelado como la clave para mejorar de forma continua eficiencia y calidad; dibujando una ecuación en la que, las personas ayudadas por la tecnología actúan como recursos para ejecutar los procesos.

Aunque seguramente contra corriente de muchas opiniones, insisto que aplicar la teoría de este modelo en empresas del conocimiento es una barbaridad, porque trabajan con materias primas muy diferentes.

¿Cuál es la materia prima del software?.


Materia prima


Esta cuestión es la razón de la diferencia y de la barbaridad.

La mediocridad en el desarrollo de software es el resultado que se obtiene al gestionar a las personas como los recursos que ejecutan los procesos, ayudados por la tecnología, y al considerar axiomático que:
  • Los procesos son el elemento de mayor palanca para garantizar la eficiencia y la calidad.
  • En lo relativo a las personas, la fórmula de la eficiencia es coneguir el mayor tiempo de trabajo por el menor coste posible.
talento

La materia prima del software es el talento, y por esta razón la teoría industrial aplicada a nuestro sector da empresas de productos mediocres, porque:
  • Suministra una materia prima de baja calidad.
  • Su sistema "personas - procesos - tecnología" incorpora al producto una mínima parte del valor que se le podría transferir.

Administrando a las personas que desarrollan software como un recurso de producción industrial se puede estar en el mercado, conseguir el volumen de trabajo que el marketing y el capital relacional propio sean capaces de lograr, pero el producto será mediocre. Este modelo de empresa no es capaz de desarrollar software innovador ni valioso.

Algunas consideraciones
  • En el desarrollo de software el protagonista para dar valor al producto es el talento muy por encima de los procesos o la tecnología.
  • Las diferencias de valor, calidad o eficiencia que pueden aportar unas personas u otras no es como en los trabajos mecánicos de 1,5 ó 2. Pueden ser x10 o x100.
  • En la ecuación Personas - Procesos - Tecnología, falta un cuarto elemento: el Entorno. La cultura y el comportamiento organizacional. Los procesos y la tecnología, principales protagonistas de los entornos industriales son insensibles al entorno. Las máquinas y los procesos no producen más o menos según sea la cultura de la empresa. Por eso el cuarto elemento no se suele considerar. Sin embargo el talento es muy sensible. Huye de las empresas tóxicas; y las personas, aunque lo tengan, no lo pueden expresar si no están motivadas.

La clave no es la "gestión de los recursos humanos" sino la "gestión del talento".


Empresas de producción industrial
Empresas del conocimiento
industrialconocimiento


Como respuesta a la crisis del software surgieron hace un par de décadas, en medio del auge y protagonismo de los procesos, marcos de modelos como solución para nuestra industria: ISO 12207, CMM, CMMI, ISO 15504, PSP, TSP...

Son una gran ayuda que identifican las áreas de conocimiento de la producción y mantenimiento del software, y desarrollan pautas de ingeniería para trabajar con sistemas que tienen niveles de integridad elevados, pero también pueden hacer estragos cuando se administran con modos trasplantados de entornos industriales a entornos del conocimiento, cuando no se equilibran adecuadamente en función de las característcas de cada empresa y de cada sistema de software.

Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad.
Gestionar empresas del conocimiento con teoría de management industrial genera productos mediocres y técnicos desmotivados.

Safe Creative

Trackback(0)
Comentarios (13)Add Comment
...
escrito por Invitado, April 19, 2006
En resumen, en el "proceso" de desarrollo de software lo que se ha de hacer es gestionar a las personas, justamente lo que predica el XP y otros mtodos giles.

SoftInSpain
Fantastico articulo
escrito por Invitado, April 19, 2006
Totalmente de acuerdo, los procesos no sirven en el desarrollo de soft para garantizar la realización de buenos productos, sencillamente porque el proceso de construcción del software no es un proceso sistematico y predecible sino que es una actividad con un altisimo componente creativo. El buen software lo hacen los buenos desarrolladores y las buenas empresas son las que conscientes de esto son capaces de atraer y mantener buenos desarrolladores.

El problema de usar metaforas de otros procesos industriales en el software es que no sirven porque sencillamente son cosas diferentes, como decia Martin Fowler en su famoso articulo the new methodology, la metafora de diseño/construcción que desde hace tiempo se viene aplicando al desarrollo de software es un completo error.

De todos modos, tampoco creo que la idea de los procesos sea del todo desdeñable y se tenga que trabajar en un entorno caotico. Para que se pueda producir buen software el ingrediente indespensable esta claro que es el talento, pero esto es condición necesaria pero no suficiente, también hace falta tener un entorno de trabajo donde se apliquen una serie de buenas practicas y se sigan unos determinados procesos (sobretodo en cuanto a SCM y QA). La dificultad creo yo esta en definir estos procesos de modo que sirvan para canalizar el talento pero sin llegar ha ahogarlo.





Muy interesante
escrito por Invitado, April 19, 2006
De nuevo, muchas gracias Juan por este contenido. La gestión de procesos basados en el conocimiento es un tema que me interesa muchísimo.

Yo creo que el problema principal es un problema de continuidad. Los procesos industriales (homogéneos, repetitivos, etc...) se pueden describir de forma prescriptiva hasta un nivel de detalle que incluya instrucciones de trabajo muy concretas. El problema surge cuando se intentan describir procesos basados en el conocimiento de esa forma.

Me permito incluir un enlace a un artículo (en inglés) en el que hago unas reflexiones sobre este tipo de procesos.

Me gusta mucho la idea de añadir el elemento Entorno a la ecuación tradicional procesos-tecnología-personas.

Lucas Rodríguez Cervera
Gracias
escrito por Invitado, April 20, 2006
Gracias por vuestros comentarios.
Coincido contigo, Lucas, en el interés por los procesos basados en el conocimiento, y sin falta voy a leer tu artículo, que no conocía.
Como apuntas, hay diferencias con los procesos industriales. Al igual que considero que el 4º elemento (entorno) hay que incluirlo en la ecuación cuando se trata de proceosos del conocimiento, también creo que hay un concepto que no se tiene en cuenta y que no se explicar muy bien así de pronto... algo así como un "coeficiente de permeabilidad del proceso". Permeabilidad a la absorción de conocimiento. Creo que los procesos y la tecnología son "contenedores" de conocimiento, de "Know How". Esponjas capaces de absorber conocimiento.
Esto se entroncaría en la línea de conocimiento tácito y explícito de Nonaka... y buf! bla bla...

Es una línea detrás de la que llevo ya algún tiempo, y que creo va tomando forma. Si Cronos es benévolo :-) un día intento postear algo con más coherencia.

Un saludo.
Juan Palacio.
Muy buenas reflexiones
escrito por Invitado, April 20, 2006
Muy buenas reflexiones que hacen pensar.

Ahora bien, el problema de hoy día en la producción de software de calidad es que hay que separar todo el proceso tecnologico y de abstracción asociados de los clientes finales, escondiendo la complejidad para poder vender las ideas finales de forma simple. Es decir no digas ni una sola sigla o tu cliente se dormira sin comprender de que le estás hablando.

Esto hace que el cliente final no entienda la dificultad y complejidad asociada y por tanto los precios asociados a un producto , proyecto o desarrollo. Lo que lleva a tener que ir siempre con prisar y corriendo y sin poder realizar un software de calidad.

No se si esto será así en el resto de paises pero lo que si que está claro es que "Spain is different".

smilies/wink.gif

Metal
escrito por Invitado, April 20, 2006
A mi me parece una farza, una completa cagada
Re:metal
escrito por Invitado, April 20, 2006
Lamento que no compartamos la misma forma de ver el desarrollo de software; pero sobre todo lamento no conocer tu punto de vista para poder considerar y charlar de las diferencias.
Sin duda las crticas y discrepancias son tan de agradecer o ms que las felicitaciones. Cuestionan y enriquecen y son base para di�logo y discusin; pero por favor que sean constructivas, no simples exabruptos, motivados a saber por qu.

Un saludo.

Juan Palacio.
Sobre el concepto de permeabilidad
escrito por Invitado, April 21, 2006
Interesante lo del "coeficiente de permeabilidad" del proceso. Lo que pasa es que en los procesos basados en el conocimiento, gran parte del conocimiento que se aplica en su ejecucin es de tipo prctico no articulabe (cogiendo prestado este concepto del mundo de la econom㡭a, Jess Huerta de Soto lo explica muy bien).

Sera como intentar describir el proceso de montar en bicicleta. Se podr꭭an definir los pasos del proceso (monta en la bicicleta, apoya un pie en el suelo y otro en un pedal, carga tu peso en el pie del pedal, etc...) pero al final del da no puedes esperar que lguien sin experiencia, sin ese conocimiento pr�ctico no articulable pueda montar en bicicleta.

As el concepto de permeabilidad del proceso estara en relaci�n con las posibilidades de articular dicho conocimiento en la medida de lo posible.
Re: permeabilidad
escrito por Invitado, April 21, 2006
Efectivamente "permeeabilidad" indicaría la cantidad de conocimiento que se puede articular, que es explicitable o que se puede depositar en el proceso (y la tecnología).

De forma esquemática, las bases sobre las que intento armar algo con sentido (no se si un castillo de naipes) son:

1.- Para realizar un trabajo el conocimiento necesario y suficiente debe estar, en la forma que sea, en las variables Personas - Proceso - Tecnología.
2.- El conocimiento residente en el proceso y la tecnología (conocimiento explítico) es valor, Know-How, asentado en bienes tangibles de la empresa.
3.- El conocimiento residente en las personas (conocimiento tácito) es valor, Know-how asentado en la plantilla de la empresa.

El "coeficiente de permeabilidad" para un trabajo dado, (con unos parámetros de calidad necesarios) sería un indicador de un sistema específico de Personas-Proceso-Tecnología; e indicaría qué porcentaje de conocimiento puede ponerse en el Proceso y la Tecnología.

Creo que dependería tanto:
1.- Del tipo de trabajo. Como apuntas, algunos como el necesario para montar en bicicleta, o para catar vinos lo ponen muy difícil si se les quiere explicitar (o imposible).
2.- Del proceso y la tecnología empleados. Ej: para el trabajo "hacer crema catalana" el coeficiente de permeabilidad al conocimiento del sistema será muy bajo, si Proceso-Tecnología es una espumadera. Será mayor si contamos con una batidora, y si estuviera formado por una Thermomix y su manual de recetas, hasta yo sería capaz de hacer la crema catalana con parámetros de calidad muy altos.

En fin, lo dicho, este tema me tira mucho.

Juan Palacio.
Más sobre permeabilidad y entorno
escrito por Invitado, April 21, 2006
Muy gráfico el ejemplo el de la crema catalana, la espumadera y la termomix.

El tema de la permeabilidad me lleva de nuevo al cuarto elemento que comentabas que hay que tener en cuenta además de proceso-tecnología-personas: el entorno. El entorno es un factor fundamental (en especial la cultura de la organización en particular en la forma de gestionar el conocimiento), ya que el mismo tiene un papel fundamental en el traspaso de ese conocimiento de las personas a los procesos y tecnología.

Lucas Rodríguez Cervera

PD: El comentario anterior era mio, se me había olvidado firmarlo
A más de uno le hace falta...
escrito por Invitado, May 04, 2006
Más de un manager y gerente de empresas de software necesitaría leer esto!
Mientras no se acepte que el desarrollo de software no es una ingeniería más, seguiremos metidos en la crisis de software de mala calidad, entregado tarde y con baja satisfacción de todo el mundo (tanto de los clientes como de los propios desarrolladores)

Enhorabuena por el artículo

Saludos

JM
Si todo fuera talento, entonces
escrito por Pedro Paramo, May 02, 2008
Si bien es muy importante el talento no deja de ser también la disciplina y el método, el marketing...., si hablamos de entornos industriales de desarrollo de software, dichas empresas dependen de compromisos adquiridos con proveedores y los que es aun mas critico, cada vez le dejamos a las máquinas (ordenadores) decisiones mas importantes. Es por esto que en lo referente al desarrollo de software cada vez se realiza énfasis en la definición de calidad de Software y Sus atributos. Haciendo el parangón con respecto a una casa musical,si esta bien el talento es importante para generar buena música, pero no garantiza el éxito de una producción musical. este engranaje se ha intentado con el desarrollo e implementación de metodologías de desarrollo software para reducir la brecha entre lo que se requiere, lo que se desarrolla, lo que se vende, lo que se compra, lo que se recibe.

"Con respecto al talento, en el arte el solo talento tampoco es suficiente". es importante pero no lo es todo.
FUD
escrito por kmilo, July 31, 2008
y quien dijo que en las metodologías guiadas por procesos hay que contratar desarrolladores menos capacitados??

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative