Scientia et Technica A–o X, No x, Mes 200x. UTP.

ISSN 0122-1701 1

ASEGURAMIENTO DEL PROCESO DE DISE„O Y DESARROLLO EN UN TALLER

0(7$/0(&È1,&O

RESUM EN GIOVANNI TORRES CHARRY

En este documento se presentan pautas y recomendaciones para establecer y
certificar, con base en la norma ISO 9001, un proceso de dise–o y desarrollo en
Ingeniero Mec‡nico, MSc.
Profesor Auxiliar
Universidad Tecnol—gica de Pereira
un taller metalmec‡nico; cada uno de los numerales de la norma asociados al
dise–o y desarrollo son tratados en forma tal que pueden ser f‡cilmente seguidos
gtorres@ utp.edu.co
y utilizados por cualquier taller metalmec‡nico.

PALABRAS CLAVES: Dise–o y desarrollo, taller metalmec‡nico,

certificaci—n, Norma ISO 9001.

ABSTRACT
Rules and recommendations are presented in this document to establish and
certify, under the ISO 9001 standards, a design and development process for a
metal workshop; each one of the items of the norm involved with the design and
development are treated in such way that they can be easily followed and used
by any metal workshop.

KEYW ORDS: Design and development, metal workshop, certification, ISO

9001 Standards.

1. ,1752'8&&,Ï1 2. DISE„O Y DESARROLLO EN UN TALLER

Los talleres metalmec‡nicos en Colombia, en su mayor’a
catalogadas como Pymes, han prestado durante mucho
tiempo el servicio de fabricaci—n de repuestos para la
industria nacional y las multinacionales presentes en su
‡rea de influencia; por diferentes factores entre los que se
destacan tiempo y dinero, los clientes empezaron a
solicitarle a estos talleres soluciones de dise–o. Si bien
los sistemas, m‡quinas o dispositivos dise–ados y
fabricados por estos talleres cumpl’an en un menor o
mayor grado con las necesidades primarias requeridas
por los clientes, su dise–o y desarrollo se hac’a en una
total informalidad y basados en la experiencia y astucia
casi artesanal de los operarios y jefes de planta de cada
taller. Con el paso del tiempo las empresas empezaron a
ser m‡s exigentes y a solicitar un aval de calidad de los
productos y servicios contratados; ante este panorama la
mayor’a de los talleres metalmec‡nicos decidieron
continuar s—lo con sus servicios de repuestos y dejar la
parte de dise–o como algo adicional y s—lo prestado a
aquellos clientes que no exijan o requieran un certificado
de calidad.
En este art’culo se expone de manera general - basado en
la experiencia vivida en el proceso de establecimiento,
aseguramiento y certificaci—n de la empresa Payan y Cia
Ltda. Bajo los est‡ndares de la norma ISO 9000 Versi—n
2000 - las pautas y recomendaciones a tener en cuenta
para asegurar un proceso de dise–o y desarrollo en un
taller metalmec‡nico.
Fecha de Recepci—n: (Letra Times New Roman de 8 puntos)
Fecha de Aceptaci—n: Dejar en blanco
M ETALM ECANICO
2.1. Generalidades
Basado en las definiciones dadas en [1], [2] y [3], el
concepto de dise–o puede ser ampliado de la siguiente
manera: el dise–o y desarrollo es un proceso que traduce
necesidades en soluciones, apoy‡ndose en conocimientos
tŽcnicos s—lidos y herramientas computacionales de
modelado y an‡lisis e involucra todo un conjunto
integrado de conocimientos cient’ficos, tecnol—gicos,
mercadotŽcnicos, componentes de conocimiento
cient’fico o emp’rico, nuevos o copiados, de acceso libre
o restringido, comerciales o tŽcnicos y de otra ’ndole
requeridos para la producci—n y comercializaci—n de
bienes y servicios espec’ficos.
Es conveniente resaltar aqu’ la gran diferencia que existe
en el manejo del dise–o que se realiza los talleres
metalmec‡nicos y el que realizan empresas que dise–an
l’neas de productos o productos de consumo masivo; en
los talleres metalmec‡nicos por lo general el dise–o se
efectœa para un producto œnico, ha pedido y bajo
condiciones particulares de cada cliente, es decir dise–os
personalizados, estas condiciones son entre otras: el
tiempo reducido, el que los dise–os deben adecuarse a
condiciones de operaci—n y de disposici—n propias de la
planta de cada cliente lo que no permite la
estandarizaci—n, continuos cambios por parte del cliente
durante el desarrollo del proyecto, poca disponibilidad de
informaci—n tŽcnica de los equipos perifŽricos y que
interactuar‡n con el dise–o proyectado, imposibilidad de
validaci—n antes de liberar el producto, el dise–o debe ser
2 Scientia et Technica A–o X, No x, Mes 200x. UTP

construido y validado en operaci—n en la planta del 3.1. Caracterizaci—n del proceso

cliente, por lo que los errores de dise–o deben ser Antes de volver operativo el proceso se debe establecer
m’nimos. cual ser‡ el esquema de dise–o a seguir, pues es sabido
que existen muchas descripciones del proceso de dise–o,
2.2. Establecimiento del proceso de dise–o y del mismo modo que hay muchas definiciones de dise–o.
desarrollo en un taller metalmec‡nico
El establecimiento o formalizaci—n de dise–o y desarrollo
Definici—n del problem a
Planteam iento
no es solo una actividad administrativa, parte de un Del cliente
convencimiento y un compromiso real de la direcci—n y verificaci—n
de toda la empresa para su establecimiento, desarrollo y Dise–o conceptual
consolidaci—n.

Cada empresa es œnica en su forma de operar, sin Dise–o prelim inar

embargo aqu’ se propone que la empresa en su proceso
de mejoramiento adopte para funcionar, un enfoque
Dise–o detallado
1
basado en procesos ; dentro de este esquema de
funcionamiento la empresa debe identificar la necesidad
de establecer un proceso de dise–o y desarrollo para
Com unicaci—n del dise–o
formalizar y normalizar el servicio de dise–o ya ofrecido Especificaciones

o por ofrecer, para asegurarse una ventaja competitiva

frente a sus competidores.

La organizaci—n deber‡, en funci—n de sus posibilidades y

Producto validaci—n

la proyecci—n deseada, establecer e incorporar los

recursos necesarios para su funcionamiento. Estos
recursos ser‡n del tipo humanos, de infraestructura y
Figura 1. Modelo de cinco fases del proceso de dise–o

tŽcnicos tales como hardware, software, herramientas de

medici—n y apoyo. El recurso humano debe estar en
En la figura 1 se muestra el modelo prescriptivo de 5
fases del proceso de dise–o seleccionado en este caso, en
cabeza de un profesional calificado en dise–o,
generalmente un ingeniero, quien se desempe–e como
l’neas punteadas se muestra los ciclos de
retroalimentaci—n interna y externa. Una vez adquiridos
el recurso tŽcnico, humano y establecido el esquema de
jefe del proceso y que en este documento se le
denominar‡: Coordinador de dise–o y desarrollo.
dise–o a seguir, se debe realizar la caracterizaci—n del
proceso, esto implica entre otras cosas establecer los
3. '2&80 (17$&,Ï1DEL PROCESO
objetivos del proceso, el alcance, el campo de aplicaci—n,
Ya establecido el proceso de dise–o y desarrollo dentro
los elementos de entrada y salida, las actividades que se
ejecutan, la interrelaci—n con otros procesos, la forma en
de la compa–’a se deben constituir los mecanismos para
que se medir‡ su desempe–o (indicadores), los recursos,
asegurar y mantener la calidad de este. La norma ISO
9001:2000 establece que la organizaci—n debe crear la
2 la responsabilidad y la autoridad dentro del proceso.
documentaci—n necesaria para mantener el sistema de
3.2. Enfoque al cliente
gesti—n de calidad as’ como para que el personal tenga la
Con base en la percepci—n de que todo cuanto tiene que
informaci—n que requiere para realizar su trabajo; en este
sentido la primera funci—n a ejecutar por el coordinador
ver con la calidad comienza y termina con el cliente, se
hace necesario establecer los medios para recoger las
de dise–o ser‡ la de establecer la documentaci—n para el
3 recomendaciones y especificaciones del cliente -lo que el
proceso .
cliente necesita-, por eso es importante obtener la
informaci—n acerca de la satisfacci—n del cliente para
poder ejecutar la triada: medici—n, an‡lisis y mejora; esto
debe verse reflejado en la documentaci—n que se
establezca.

4
1
3.3. Numeral 7.3 ± Dise–o y desarrollo
Una actividad que utiliza recursos y que se gestiona con el fin de
permitir que los elementos de entrada se transformen en resultados se
puede considerar un proceso. La aplicaci—n de un sistema de procesos En la norma [4], el numeral que involucra directamente al
dentro de una organizaci—n, junto con la identificaci—n e interacciones dise–o y desarrollo es el 7.3; en el se establecen las
de otros procesos, as’ como su gesti—n, puede denominarse como pautas para la planificaci—n del dise–o, sus resultados, la
³HQIRTXHEDVDGRHQSURFHVRV´.
2
De aqu’ en adelante se har‡ referencia en este documento a ella
simplemente como la norma.
3
La documentaci—n generada para el proceso debe ir ligada al resto de
documentos de los dem‡s procesos a travŽs del manual de la calidad de 4
RefiŽrase al texto de la norma ISO 9001:2000
la compa–’a.
Scientia et Technica A–o X, No x, Mes 200x. U.T.P
revisi—n, la verificaci—n, la validaci—n y el control de los
cambios.
En concordancia con los requisitos de documentaci—n
establecidos por la norma en el numeral 4.2 (requisitos de
la documentaci—n), en este art’culo se van a establecer
procedimientos para describir como los integrantes del
proceso de dise–o y desarrollo deben ejecutar sus
actividades, a estos se les llamar‡ procedimientos
operativos y van a indicar quien hace que, donde, cuando,
por que y como lo hace.
La codificaci—n que se utilizar‡ aqu’ para nombrar los
procedimientos y documentos asociados se hace a
manera de ejemplo, cada compa–’a en funci—n de lo que
se describa en su manual de calidad tendr‡ su propia
manera de codificar sus documentos. Espec’ficamente la
documentaci—n que se utilizar‡ aqu’ sigue la siguiente
forma:
DD-XX-YY
Donde,
DD: siempre se utilizar‡ en los documentos e indica que
este pertenece al proceso de dise–o y desarrollo.
XX : Puede tomar las siguientes:
PR: indica que es un procedimiento
IT: indica que es un instructivo
FT: indica que es un formato
YY: toma valores secuenciales desde 01 en adelante
Al interior de cada procedimiento pueden establecerse
otro tipo de documentos (instructivos, formatos), en tal
caso se sigue la misma regla utilizada para XX y YY.
3.3.1. Recepci—n de las necesidades de los clientes
Las necesidades de los clientes son tratados por la norma
en el numeral 7.3.2 (elementos de entrada para el dise–o
5 ser‡n elementos de apoyo en la determinaci—n
y desarrollo) . Para cumplir con este numeral se crea el
procedimiento DD-PR-01 (Recepci—n de proyectos de
dise–o y desarrollo); el objetivo de este procedimiento es
el de estructurar el mŽtodo de recepci—n de las
necesidades de dise–o de los clientes y establecerlos
como entradas al proceso de dise–o y desarrollo.
Antes de que sea aceptado un proyecto este debe ser
valorado preliminarmente, segœn los criterios que
establezca la empresa, para determinar la viabilidad de su
ejecuci—n; aqu’ se plantea la conformaci—n de un comitŽ
de dise–o y desarrollo, este comitŽ estar‡ integrado por el
coordinador de dise–o, el asesor comercial-vendedor o
cliente interno, el coordinador de producci—n y en lo
5
 ³'HEHQ GHWHUPLQDUVH ORV HOHPHQWRV GH HQWUDGD UHODFLRQDGRV FRQ ORV
UHTXLVLWRVGHOSURGXFWR\PDQWHQHUVHUHJLVWURV´³HVWRVHOHPHQWRVGHEHQ
revisarse para verificar su adecuaci—n. Los requisitos deben estar
FRPSOHWRVVLQDPELJHGDGHV\QRGHEHQVHUFRQWUDGLFWRULRV´
____________________________
1. Las notas de pie de p‡gina deber‡n estar en la p‡gina donde se citan. Letra Times New Roman de 8 puntos
3
posible por un representante de la gerencia. Las
funciones principales de este comitŽ son:
· Determinar y evaluar la relevancia y
conveniencia de los proyectos de dise–o y
desarrollo a ser manejados por la compa–’a.
· Proponer proyectos de desarrollo con base a
oportunidades, vigencia, potencial econ—mico-
tecnol—gico y a la apropiaci—n de los resultados y
desarrollos paralelos.
· Seguir y evaluar el desarrollo de los
proyectos ejecutados y en ejecuci—n en la
compa–’a.
Las decisiones y los t—picos tratados en cada reuni—n del
comitŽ son registrados en un acta, validada con la firma
de los asistentes.
El principal problema encontrado con este tipo de comitŽ,
por lo menos en la experiencia vivida en Payan, es la
dificultad para establecer las reuniones de tal manera que
se ajusten a los horarios de todos los integrantes.
Una vez aceptado el proyecto como viable, se deben
determinar con claridad las necesidades de dise–o; en
este sentido en el procedimiento se establece lo siguiente:
· La recepci—n de los requerimientos de dise–o se
efectœa por parte de los asesores comerciales.
Para esto se crean los instructivos: DD-PR-01-
IT-01 (Elementos De apoyo para las entradas de
dise–o) y DD-PR-01-IT-02 (Instructivo para la
recepci—n de los requerimientos de dise–o).
· En el instructivo DD-PR-01-IT-02 (Instructivo
para la recepci—n de los requerimientos de
dise–o), se establecen algunas pautas para el
correcto y completo registro de las necesidades
de dise–o .
6
· Las fotos, filmaciones y descripciones verbales
de los requerimientos de dise–o por parte de los
asesores comerciales y pueden servir adem‡s
como apoyo de referencia durante el desarrollo
del proyecto pero no constituyen por si solos
entradas suficientes para el proceso (Instructivo
DD-PR-01-IT-01).
· Se establece el formato DD-PR-01-FT-01
(Recepci—n de requerimientos de dise–o) para
registrar los requerimientos de los clientes.
·
Una vez recibidos los requerimientos en el
formato DD-PR-01-FT-01, el coordinador de
dise–o y desarrollo le asigna un c—digo a cada
proyecto al momento de su aceptaci—n en el
proceso.
6
Estas incluyen las necesidades explicitas de los clientes, requisitos
legales, pr‡cticas industriales y normas, experiencias pasadas y las
necesidades no definidas por el cliente, etc.
4 Scientia et Technica A–o X, No x, Mes 200x. UTP
· A cada proyecto se le crea una carpeta de dise–o
f’sica y una virtual.
· Se crea el formato DD-PR-01-FT-02 (Relaci—n
de proyectos de dise–o y desarrollo); el objetivo
es mantener un registro de los proyectos
ejecutados y en ejecuci—n en el proceso. Este
formato incluye entre otra informaci—n: la
descripci—n general del proyecto, el c—digo
asignado, las fechas de inicio y finalizaci—n y
los clientes interno y externo.
· Los registros generados en esta etapa ser‡n
archivados en la carpeta de dise–o del proyecto.
3.3.2. Planificaci—n del dise–o y desarrollo
La forma en la ejecuci—n del proyecto es tratado en la
norma en el numeral 7.3.1 (Planificaci—n del dise–o y
7
desarrollo) . Para cumplir con este numeral de la norma
se crea el procedimiento DD-PR-02 (Planificaci—n del
dise–o y desarrollo); el objetivo del procedimiento es el
de establecer una metodolog’a para la planeaci—n de las
actividades de dise–o, control y verificaci—n en los
proyectos de dise–o y desarrollo. En tŽrminos generales
se desea planificar que se va a hacer, quien, con que y
cuando lo va a hacer:
· La planeaci—n la hace el coordinador de dise–o y
ser‡ aprobada por el comitŽ de dise–o.
·
Se deben formular los objetivos generales y
espec’ficos del proyecto en tŽrminos de valores
medibles o de ejecuci—n; estos constituyen la
base para el desarrollo del proyecto, su
verificaci—n y validaci—n, en el alcance del
proyecto se establecer‡ el tipo y la forma de los
resultados del proyecto, para su registro se crea
el formato DD-PR-02-FT-01 (Objetivos, alcance
y recursos del proyecto).
· Como parte de esta planeaci—n se establecen
actividades para el desarrollo del proyecto, el
responsable y los recursos necesarios para su
ejecuci—n; con esta informaci—n se constituye un
cronograma para el proyecto que ser‡ registrado
en el formato DD-PR-02-FT-02 (Cronograma de
proyecto de dise–o y desarrollo), como gu’a para
la generaci—n de este se puede utilizar el
instructivo DD-PR-02-IT-02 (Instructivo para la
realizaci—n de cronogramas de proyectos), si se
utiliza un software para la planeaci—n, deber‡
establecerse un formato base o plantilla para
todos los proyectos.
· Debido al enfoque al cliente que se ha acogido
aqu’, la planeaci—n deber‡ incluir las revisiones
internas, la verificaci—n, la validaci—n y las
7
³/DRUJDQL]DFLyQGHEHSODQLILFDU\FRQWURlar el dise–o y desarrollo del
SURGXFWR´ ³OD RUJDQL]DFLyQ GHEH JHVWLRQDU ODV LQWHUIDFHV HQWUH ORV
diferentes grupos involucrados en el dise–o y desarrollo para asegurarse
de una comunicaci—n eficaz y una clara asignaci—n de
UHVSRQVDELOLGDGHV´
revisiones con el cliente. El nœmero total de
revisiones internas y revisiones con el cliente
depender‡n de la magnitud del proyecto, se
especificar‡n en la planeaci—n y quedar‡n
plenamente establecidas en el cronograma del
proyecto.
· La planeaci—n - el plan y el cronograma - es
revisada, ajustada y finalmente aprobada por el
comitŽ de dise–o, los resultados de esta revisi—n
se registrar‡n en el formato DD-PR-03-FT-01
(Revisi—n interna de proyectos de dise–o).
· Los registros generados en la planeaci—n como
son el plan, el cronograma y su revisi—n ser‡n
archivados en la carpeta de dise–o del proyecto.
3.3.3. Resultados de dise–o y desarrollo
El producto o resultado del dise–o es tratado en la horma
en el numeral 7.3.3 (Resultados del dise–o y desarrollo) .
8
Para cumplir con este numeral de la norma se crea el
procedimiento DD-PR-03 (Resultados del dise–o y
desarrollo). El objetivo del procedimiento es establecer
los par‡metros que definen los resultados del proceso de
dise–o y desarrollo as’ como su revisi—n, verificaci—n y
aceptaci—n. En este procedimiento tambiŽn se han
incluido los requisitos de los numerales 7.3.4 (revisi—n
del dise–o y desarrollo) , 7.3.5 (verificaci—n del dise–o y
9
y 7.3.6 (validaci—n del dise–o y
10
desarrollo)
11
desarrollo) ; esto se hace por conveniencia ya que el
proceso de dise–o y desarrollo, como se vio en la figura
1, es un proceso iterativo y los resultados finales
dependen de la retroalimentaci—n interna y externa que se
logran con las revisiones, la verificaci—n y la validaci—n.
Los resultados de dise–o pueden tener mœltiples formas y
se debe asegurar de que estos cumplan con los requisitos
propuestos. En la planeaci—n se describe cual debe ser la
forma de los resultados y como se verificar‡ que se hayan
cumplido los requisitos; al decidir la forma que tomar‡n
los resultados se debe tener en cuenta quien y en que
circunstancias los va a utilizar:
· Es conveniente establecer adem‡s de las
revisiones internas, revisiones con el cliente de
 ³ORV UHVXltados del dise–o y desarrollo deben proporcionarse de tal
8
manera que permitan la verificaci—n respecto a los elementos de entrada
SDUDHOGLVHxR\GHVDUUROOR\GHEHQDSUREDUVHDQWHVGHVXOLEHUDFLyQ´
9
³(QODVHWDSDVDGHFXDGDVGHEHQUHDOL]DUVHUHYLVLRnes sistem‡ticas del
dise–o y desarrolloGHDFXHUGRFRQORSODQLILFDGR´
10
³Se debe realizar la verificaci—n, de acuerdo con lo planificado, para
asegurarse de que los resultados del dise–o y desarrollo cumplen los
requisitos de los elementos de entrada del dise–o y desarrollo. Deben
mantenerse registros de los resultados de la verificaci—n y de cualquier
acci—n que sea necesaria.
11
  ³ 6H GHEH UHDOL]DU OD YDOLGDFLyQGHO GLVHxR \ GHVDUUROOR GH DFXHUGR
con lo planificado para asegurarse de que el producto resultante es
capaz de satisfacer los requisitos para su aplicaci—n espec’fica o uso
previsto, cuando sea conocido. Siempre que sea factible, la validaci—n
debe completarse antes de la entrega o implementaci—n del producto.
Deben mantenerse registros de los resultados de la validaci—n y de
cualquier acci—n que sea necesaria.
Scientia et Technica A–o X, No x, Mes 200x. U.T.P
tal manera que se pueda tener la
retroalimentaci—n de este durante el desarrollo
del proyecto y poder corregir o mejorar el
desarrollo del mismo.
· En las revisiones internas se verifica el estado de
la ejecuci—n del proyecto y se analizan aspectos
tŽcnicos; se establecen tareas, fechas de
ejecuci—n y responsables de las mismas. Los
resultados de las revisiones internas se registran
en el formato DD-PR-03-FT-01 (Revisi—n
interna de proyectos de dise–o).
· En las revisiones con el cliente se utilizan
prototipos virtuales y las memorias de c‡lculo
para socializar los conceptos de dise–o y el
avance en la ejecuci—n del mismo; se establecen
tareas, fechas de ejecuci—n y responsables de las
mismas. Los resultados de las revisiones con el
cliente se registran en el formato DD-PR-03-FT-
02 (Revisi—n de proyectos de dise–o con el
cliente).
· Cuando los resultados del proyecto son planos
de piezas y/o ensambles, se estable que estos se
entregan en el formato DD-PR-03-FT-05
(Planos de dise–o y desarrollo). Cada plano
llevar‡ un c—digo consecutivo y estar‡ firmado
por el coordinador de dise–o quien avala la
informaci—n en el contenida.
· La aceptaci—n o rechazo de los resultados se
decide como resultado de la verificaci—n final
del proyecto, en esta actividad se comparan las
caracter’sticas finales del dise–o representado
mediante planos, memorias de c‡lculo,
especificaciones operativas, etc, contra los
requerimientos de dise–o establecidos
previamente. Esta verificaci—n puede conducir a
la liberaci—n de los resultados o a la
implementaci—n de cambios en el dise–o (ver
figura 1). esta verificaci—n la hace el equipo de
dise–o que trabaj— en el proyecto en cabeza del
coordinador; los resultados de esta verificaci—n
ser‡n registrados en el formato DD-PR-03-FT-
03 (Verificaci—n de proyectos de dise–o).
· El tipo de validaci—n a efectuar en el proyecto
debe establecerse con el cliente desde el
momento en que se hace la recepci—n de los
requerimientos de dise–o. Debido a la
diversidad de proyectos que se pueden ejecutar,
es casi una norma que es dif’cil para un taller
metalmec‡nico ejecutar la validaci—n de todos
ellos, durante la planeaci—n del proyecto se
deber‡ estipular quien y cuando realiza la
validaci—n, decisi—n que debe concertarse con el
cliente. Si la validaci—n puede ser realizada por
el taller, sus resultados se registrar‡n en el
formato DD-PR-03-FT-04 (Validaci—n de
proyectos de dise–o); cuando la validaci—n la
hace el cliente, el determinar‡ sus condiciones y
registros, formalmente el coordinador de dise–o
____________________________
1. Las notas de pie de p‡gina deber‡n estar en la p‡gina donde se citan. Letra Times New Roman de 8 puntos
5
solicitar‡ la retroalimentaci—n de esta
informaci—n. Si los resultados de la validaci—n
no son satisfactorios el equipo debe retornarse al
taller para que se le implementen los cambios a
que haya a lugar; se espera que si el proyecto es
bien planeado y se realizan buenas y suficientes
revisiones internas y con el cliente, el producto
final se acerque en un muy alto porcentaje al
ideal del cliente y que adem‡s la validaci—n sea
positiva.
3.3.4. Control de cambios del dise–o y desarrollo
Los cambios que se pueden presentar en el dise–o son
tratados en la norma en el numeral 7.3.7 (Control de
cambios de dise–o y desarrollo) .
12
Para cumplir con este numeral de la norma se crea el
procedimiento DD-PR-04 (Control de cambios del dise–o
y desarrollo). Este procedimiento tiene como objetivo
establecer las acciones a seguir cuando se generen
cambios en el dise–o, a su vez establece la creaci—n de un
registro de las causas de dichos cambios que permita
establecer la evoluci—n del proyecto y en determinados
casos detectar errores y prevenir su ocurrencia en el
futuro.
Como producto de las revisiones del dise–o tanto internas
como con el cliente, de la verificaci—n o de la validaci—n,
pueden generarse cambios dentro del dise–o planeado.
Cualquiera que estos sean y provengan de donde
provengan deben identificarse y ser registrados
adecuadamente.
· Es responsabilidad del coordinador de dise–o y
desarrollo revisar, verificar, validar y aprobar,
segœn sea el caso, cualquier cambio antes de su
implementaci—n, para esto puede convocar, si lo
considera conveniente a reuni—n a las personas
involucradas en el proyecto (Cliente, Asesor
Comercial, etc.).
· Una vez determinado, mediante las revisiones,
verificaci—n o la validaci—n del dise–o, que
deben efectuarse modificaciones al dise–o, las
accionas sugeridas en los respectivos registros,
son analizadas para determinar su conveniencia
y el efecto real sobre el dise–o.
· Los resultados de los an‡lisis as’ como las
decisiones que de ellos se desprendan deben ser
consignados en el formato DD-PR-04-FT-01
(control de cambios en proyectos), en este
formato deben quedar claramente establecidos
 ³/RV FDPELRV GH GLVHxR \ GHVDUUROOR GHEHQ LGHQWLILFDUVH \ GHEHQ
12
mantenerse registros. Los cambios deben revisarse, verificarse y
validarse, segœn sea apropiado, y aprobarse antes de su implementaci—n.
La revisi—n de los cambios del dise–o y desarrollo deben incluir la
evaluaci—n del efecto de los cambios en las partes constitutivas y en el
SURGXFWR \D HQWUHJDGR´ ³GHEHQ PDQWHQHUVH UHJLVWURV GH ORV UHVXOWDGRV
de la revisi—n de los cambios \GHFXDOTXLHUDFFLyQTXHVHDQHFHVDULD´
6 Scientia et Technica A–o X, No x, Mes 200x. UTP

cuales fueron los cambios realizados, sus Necesidades de los clientes

razones y los efectos en el dise–o tanto en su

Evaluaci—n preliminar
planeaci—n como en su ejecuci—n y en el
desempe–o final esperado. No se ejecuta Concepto tŽcnico- econ—mico
Aprob.?

3.3.5. Acciones preventivas y correctivas

Cliente interno / Cliente externo
En el proceso de dise–o y desarrollo se deben identificar
Concepto cliente
claramente las causas que motivaron el no cumplimiento NO
del plan de dise–o, los cambios en el dise–o o la no
Ejecutar?

aceptaci—n de los resultados y con base a esto tomar las

Gerencia
acciones, establecer si las causas son propias del manejo Aprobaci—n gerencia
din‡mico de los proyectos de dise–o o si se hace Cliente interno / Cliente externo
necesario la aplicaci—n de acciones correctivas o Requerimientos de Dise–o
13
preventivas . Dise–o & Desarrollo

NO
OK?
4. CONCLUSIONES Y RECO M ENDACIONES
Existe una gran diferencia en el manejo de los proyectos Dise–o & Desarrollo
de dise–o que deben realizar los talleres metalmec‡nicos Planeaci—n, cronograma
del que realizan empresas que dise–an l’neas de NO
OK? Revisi—n de dise–o interna
productos o productos de consumo masivo; en los talleres
metalmec‡nicos por lo general los dise–os son
Dise–o & Desarrollo
³SHUVRQDOL]DGRV´
Dise–o conceptual
Ajustes
El establecimiento y posterior aseguramiento del proceso R. I Revisi—n de dise–o interna

de dise–o y desarrollo no debe ser solo una actividad

administrativa; debe partir de un real convencimiento y Cliente
compromiso de toda la empresa. Establecido el proceso,
la organizaci—n debe establecer e incorporar los recursos Cambios
OK? Revisi—n de dise–o con el cliente
necesarios, realizar la caracterizaci—n del proceso y
constituir los mecanismos para asegurar y mantener la
Dise–o & Desarrollo
calidad de este.
Dise–o detallado, planos,
especificaciones tŽcnicas
NO
En la figura 2 se resume el flujo de informaci—n en los OK? Verificaci—n

proyectos de dise–o de acuerdo al esquema establecido

aqu’. El nœmero de revisiones internas (RI) y revisiones CLIENTE INTERNO

con el cliente (RC) est‡ en funci—n de la complejidad del

CLIENTE EXTERNO
proyecto y se realizan segœn la planificaci—n que se
establezca. Validaci—n

Figura 2. Flujo de informaci—n en los proyectos de

Cada una de las etapas mostradas en la figura est‡n dise–o y desarrollo.
asociadas a una documentaci—n descrita en el cuerpo de
este art’culo: Procedimientos, formatos e instructivos.
5. %,%/,2*5$)Ë$
Debe llevarse registro de las actividades ejecutadas en el
[1] DYM, Clive L. El proceso de dise–o en ingenier’a,
desarrollo de cada proyecto, estos registros deben ser
archivados en la carpeta de dise–o asociada.
Primera edici—n, 327 p‡ginas, Limusa W iley,
Mexico D.F., 2002.
[2] ULRICH, Kart T, EPPINGER, Steven. Dise–o y
desarrollo de productos, Tercera edici—n, 366
p‡ginas, Mc Graw Hill, Mexico D.F., 2004.
[3] VOLAND, Gerard. Engineering by design, Primera
edici—n, 547 p‡ginas, Addison W esley, Estados
Unidos, 1999.
[4] INSTITUTO COLOM BIANO DE NORM AS
TECNICAS Y CERTIFICACION. Manual para las
13
el manejo de las acciones preventivas y correctivas se debe hacer de peque–as empresas Gu’a sobre la norma ISO
acuerdo a lo que se tenga establecido en los procedimientos que para tal 9001:2000. Bogot‡: ICONTEC, 2001. 172 p‡ginas.
efecto tenga la compa–’a en su sistema de gesti—n de calidad