Un ejercicio de creatividad. El torpedo de salvamiento. Sistema rápido de salvamiento marítimo.

Aquí os presento una idea que me surgió (creatividad) y desarrollé un poco para ejercitar y practicar. Espero ir publicando algunas otras que tengo en mi baúl de ideas. Y así compartirlas, y si hay suerte, estimular y motivar a que la gente imagine.

Mi idea consiste en un sistema de salvamiento marítimo rápido para la asistencia de victimas que se encuentran a gran distancia o distancias fuera del alcance de un experto socorrista. Este sistema sería capaz de asistir a la víctima más rápido que cualquier experto socorrista aún utilizando una embarcación motorizada.  El tamaño de éste permitiría ser transportado por socorristas en las típicas “quads” o estar al abasto del socorrista en la misma torre vigía.

El sistema está inspirado en un torpedo. Proyectil autopropulsado que se desplaza por debajo del agua, usado para detonar en proximidad o en contacto con objetivos marinos,  hubieron y hay diversos diseños de torpedos desde los más sencillos el torpedo de botalón, que data del 1877, hasta los actuales Mark-48.

Esquema del torpedo de salvamiento. Innocreatividad

El torpedo de salvamiento estaría compuesto esqueamáticamente por la siguientes partes.

  • Hélices: Son las que impulsan el torpedo.
  • Motor: El encargado de dar el movimiento a las hélices.
  •  Batería: Fuente de energía eléctrica para el sistema.
  •  Electrónica de potencia: La encargada de suministrar los diferentes voltages a las diferentes partes eléctricas y electrónicas del sistema. Motor, placa madre, etc.
  • Red inflable antipánico: Será la encargada de salvar a nuestro bañista en apuros.
  • Baliza: Dispositivo para una mejor visibilidad para el operario del torpedo.
  • Sensórica inercial: Placa compuesta por sensores como accelerómetros, giroscopios, y/o magnetrónomos para su navegación.
  • Placa madre: Placa que alberga la inteligencia y algoritmos para el control de navegación, lectura de sensores, protocolos de actuación, etc.
  • Cámara termográfica: Esta cámara capaz de visualizar temperaturas junto a algoritmos de visión artificial indispensable para una actuación sin riesgos.
  •  Radar: Sensor para para poder tener constancia de movimientos y distancias con precisión y rapidez.
  • Mando RF: Dispositivo no representado pero que sirve para una primera orientación y confirmación para el protocolo de salvamiento.

El funcionamiento del sistema sería el siguiente:

Una vez avistada la víctima, el socorrista lanza el torpedo al agua, el torpedo automáticamente se endereza utilizando sus sensores inerciales. Éste despliega la baliza para que el socorrista pueda ver en que lugar está el torpedo y comienza la marcha. Mediante un mando de radio frecuencia el socorrista marca la dirección de la víctima, como si fuera un juguete radio dirigido.

Torpedo en acción

Torpedo funcionamiento 1. Innocreatividad

Cuando el torpedo detecta que se encuentra a la distancia de procedimiento entre el torpedo y víctima, utilizando el rádar, la cámara termográfica y los algoritmos de visión artificial. El torpedo envía un mensaje al socorrista y este confirma. El mismo torpedo comienza el procedimiento de rescate.

vision_termografica

Visión de cámara termográfica. Innocreatividad

El sistema avanzado de visión junto con radar ayudaría a detectar posibles obstáculos que pudieran entorpecer la maniobrabilidad y la posibilidad de chocar con otros bañistas u objetos.

Una vez dada la confirmación por el socorrista el torpedo automáticamente procedería al salvamiento. El torpedo se sitúa justo debajo del bañista y procede a desmembrarse para dar salida a la red inflable antipánico. Ésta se infla por debajo de la víctima y asciende a la superficie rescatando a la víctima y poniéndola a salvo encima de este

Salvamiento_2

Procedimiento final y salvamiento Innocreatividad

Y este sería el funcionamiento básico de este dispositivo . Hay muchos campos donde investigar y/o definir. El procedimiento del socorrista, tipo de “colchoneta”, lugares de aplicación, etc.  Pero, no deja de ser un boceto de la idea.

Espero que les haya gustado la idea. 🙂

El Método de las carteras (parte 2). Gestión R+D

Este post está relacionado con el anterior post  El Método de las carteras (parte 1). Gestión R+D , donde en esta ocasión describo el método que se me ocurrió como posible adaptación para optimizar un laboratorio para la elaboración de  proyectos con base tecnológica.

Descripción del método:

El método se basa en la definición de 5 “carteras” de conocimiento con unas tareas y responsabilidades en concreto. Y hacer que cada ingeniero se encargue de esta durante un tiempo determinado, entre 2 y  3 meses, con el soporte del antiguo amo. Pasado este tiempo, rotar la “cartera” hacia otro ingeniero.

Cada “cartera” contiene la documentación utilizada para la elaboración de cada proyecto y sus ficheros, información recopilada para la cartera, librerías, el software utilizado, informes de metodología, etc.

Después del periodo de posesión, en el momento de la rotación se hará una reunión entre el antiguo poseedor y el nuevo con la presencia del jefe de laboratorio. Se explicará en que condiciones se deja la cartera, trabajos que quedan por realizar y sus prioridades, ideas para nuevas herramientas o metodologías que han pensado.

Los efectos directos que se podrían obtener serian:

  • Mejora de la transferencia del conocimiento.
  • Aumenta la seguridad en si mismo del profesional.
  • Elaboración de librerías comunes para el laboratorio y estandarizadas.
  • Mejora de las metodologías y conocimientos de herramientas.
  • Aumenta el tiempo de práctica en un área de proyecto para poder especializarse con más rigurosidad.
  • Versatilidad del laboratorio y facilidad para la incorporación de nuevos ingenieros o técnicos.

Las 5 “carteras” del conocimiento son:

  1. Diseño: Realización de esquemas y “layouts”, elaboración de la lista de componentes, elaboración de librerias, footprints, base de datos de datasheets y documentación de metodología utilizada.
  2. Test: Programación y definición de tests a realizar, búsqueda y soporte para la solución, elaboración de informes de test, elaboración de “tools” para la realización de test y documentación de metodología usada.
  3. Código: Firmware y software, programación de microcontroladores, programación de aplicaciones, implementación de librerías, soporte para la realización de “tools” y documentación de metodología utilizada.
  4. Prototipado: Ensamblador final del proyecto, control de material y proveedores, modelos 3D, soporte a PCB.
  5. Laboratorio y soporte técnico: Mantenimiento y control de la maquinaria, estoc de material genérico del laboratorio, soporte técnico a los “comerciales”, elaboración de informes, encargada del blog del laboratorio, realización de vídeos, fotos, novedades científicas y técnicas.

Todas las “carteras” van ligadas a otras carteras para poder desarrollar metodologías de comunicación en el laboratorio, por ejemplo, quien se encarga del prototipado ha de exigir, en caso necesario, las medidas de la PCB o pedirlas para poder hacer la “caja” contenedora, por decir. El encargado de test tiene que dar soporte al diseñador para poder encontrar el error y la solución al problema del circuito. Es interesante encontrar links de unión entre todas “las carteras” y que no trabajen completamente independientes entre si.

La estructura sería la siguiente:

Este método está focalizado en el laboratorio y no en la parte superior del organigrama, imagino que se podrían definir algunas tareas específicas para project managers, y definir con claridad donde cae la responsabilidad de esas tareas en concreto, pero analizar esas tareas no es el objeto de este método.

Se define como manager lab. en el organigrama del laboratorio, este será el encargado de gestionar el proyecto delante del project manager, la gestión de recursos, vigilar el “lead time” y soporte técnico al proyecto. Encuentro interesante que cada ingeniero fuese “manager lab.” de cada proyecto, pero en una situación con un número limitado de personal y el volumen de trabajo que existe, seria complicado. Idealmente tendría que ser el “manager lab.”.

Este se encargaría de gestionar las prioridades de trabajo de cada cartera, conociendo la situación de cada proyecto en cada momento, de esta manera, en caso necesario se podría tener en un proyecto, de manera temporal, más de un ingeniero trabajando, y así poder acelerar la finalización de un proyecto o de un proceso dentro de un proyecto. De hecho, la figurar de “manager lab.” actual responde para cada ingeniero en cada proyecto y da soporte técnico a todos en caso necesario.

La posesión de cada “cartera” implica atender a la demanda de cualquier proyecto dentro de las prioridades marcadas por el “manager lab.”, la redacción de informes esquemáticos y descriptivos de la metodología utilizada, problemas encontrado y soluciones, y la elaboración de librerías completas y descritas para que puedan ser utilizadas por el siguiente ingeniero que tome posesión de la “cartera”

La documentación de la “cartera” tiene que ser normalizable, fácilmente ampliable y modificable. Ya sea relacionada con los proyectos, librerías o metologías.

En el próximo post, la parte 3, explicaré un poco más como se definen “las carteras”, la implantación y una conclusión.

El Método de las carteras (parte 1). Gestión R+D

El origen de este método surge del análisis de un centro tecnológico donde se realizan proyectos R+D+i. Y hay más proyectos que ingenieros y el control de recursos no es muy exhaustivo, en consecuencia… Mi reflexión!

El documento intenta explicar de manera entendible una nueva estructura de laboratorio para mejorar su rendimiento y adaptarlo hacia un crecimiento estructurado. Una adaptación de lo que creo que es una gran estructura R+D+i a centros tecnológicos de pequeño formato o con un número limitado de ingenieros. El método no abarca toda la estructura necesaria para un cambio efectivo, es un método paliativo dentro de una estructura no flexible por convencimiento o por pereza a lo nuevo (típico en nuestro país, si funciona, $$$ ,para que cambiar).

Antecedentes y situación actual en  laboratorios a pequeña escala:

En estos momento en  EMPRESA  nos encontramos en la siguiente situación:

  • Falta de especialistas: Debido al funcionamiento actual, cada ingeniero se ocupa integramente de cada proyecto, desde el diseño del circuito, layout o pcb, programación, proveedores, test, etc. En definitiva “Aprendiz de muchas cosas, maestrillo de nada”, y no es por falta de capacidades por parte de los ingenieros sino por la poca dedicación que puede dedicar a cada aspecto del proyecto.
  • Dificultades para respetar el “lead time” y en consecuencia disminución de la calidad del producto: Por la falta de especialización de los ingenieros llegar a respetar la fecha de entrega se puede ver dificultada por varios motivos, como podría ser el estancamiento en cualquier aspecto dentro del desarrollo del proyecto, por falta de práctica, por falta de seguridad o por falta de soporte. Afectando de manera notoria la calidad del producto (prototipo) que se sirve al cliente.
  • No vigilar costes ni proveedores (del laboratorio): Por falta de tiempo, los ingenieros encargados del desarrollo de los proyectos no pueden llegar a analizar con detenimiento cuales podrían ser las opciones más óptimas, técnicamente para cada desarrollo, ni cuales opciones les pueden ofrecer sus proveedores o nuevos, teniendo en cuenta que podrían ofrecer a parte de un buen precio una buena asistencia técnica.
  • Utilización de la maquinaria del laboratorio: El dominio y el mantenimiento de la maquinaria es muy importante, tanto por la calidad del producto como por el tiempo, horas-hombre, que se podrían ahorrar si hubiera un especialista. Ahora mismo la utilización que se hace de la maquinaria es la justa, y el ratio horas-hombre/calidad es baja.
  • Comunicación directa entre comerciales y laboratorio: Este es un problema donde los comerciales también piden una solución, es muy importante y parece que no tenga la transcendencia que debería tener. El hecho de que un “comercial” venda “algo” que no se puede realizar, hace que pierda credibilidad delante del cliente. Al igual que, no tener referencias de la evolución de sus propios (comercial) proyectos aunque sea de una forma más ligera.
  • Nuevas tecnologías  y metodologías: Dentro de la dinámica en la elaboración de proyectos es muy difícil mejorar las propias metodologías, teniendo en cuenta que se hace un abanico muy amplio de diferentes tareas. Teniendo en cuenta que en el tiempo en el que se vuelve a realizar la misma tarea, no se ha asimilado la suficiente práctica como para poder mejorarla. La insuficiencia de tiempo hace que no se pueda hacer un seguimiento de nuevas tecnologías.
  • Soporte a proyectos de manera excepcional: Con un modelo de gestión de laboratorio en la que se sitúan actualmente, cada ingeniero tiene sus propios proyectos (sin objetivos comunes), es muy complicado dar soporte de manera práctica y eficaz a otros ingenieros que lo necesiten, ya sea, por falta de tiempo o calidad de resultado por asimilar.
  • Situación de los ingenieros: Con el actual modelo de gestión es inevitable caer en errores por falta de práctica, falta de tiempo y falta de soporte. Esto repercute directamente en la autoestima profesional de cada ingeniero incidiendo no solo en el proyecto afectado sino en otras tareas que está desarrollando en otros proyectos.

 

Objetivos a cumplir por un nuevo método:

EMPRESA:

Ser sistémicos y continuos, no intermitentes, donde ayudaría a evaluar con más eficiencia los recursos horas-hombre, material y maquinaria. De esta manera se facilitaría presupuestar con más criterio y eficiencia. Tiempo de desarrollo del producto más corto, llegar a un proceso de desarrollo más eficiente. Producir un alto nivel de calidad desde el inicio de la fabricación.

Convertirse en una estructura que englobe la habilidad del laboratorio para cambiar y adoptar nuevas tecnologias. Aceptar el proceso de prueba y error para llegar a diseñar un producto fiable.

INGENIEROS:

Con el método que explicaré en el siguiente post, creo que se podría conseguir una multidisciplinariedad más eficiente por parte de los ingenieros, unas herramientas desarrolladas por ellos individualmente y en conjunto, una implicación de todo el grupo con todos los proyectos y el laboratorio. Entregar los proyectos dentro del tiempo estimado (un deseo). Un control de prioridades más flexible. Mejorar el know-how del proceso de desarrollo.

Próximos post, la propuesta.

Consideraciones para la gestión de proyectos (Control de tareas)

El post de hoy! después de unos días de descanso… Control de tareas! Directos al meollo!

En la lista que a continuación se muestra, se identifican ciertas tareas que forman parte de la gestión más técnica, dejando de banda la económica aunque el éxito de estas vaya totalmente ligadas con el éxito del proyecto. Cualquier tarea de la lista adoptada por el desarrollador o técnico se ha de valorar como un aporte extra al trabajo del Project manager, ya que suelen ser responsabilidad de este.

  • Identificar las tareas.
  • Determinar las habilidades necesarias para realizar cada tarea, utilizando, por ejemplo, una matriz de responsabilidad.
  • Identificar el personal disponible, tras negociar con los responsables departamentales.
  • Garantizar la competencia personal, es muy probable que sea imposible casar las habilidades requeridas con los técnicos disponibles.
  • Establecer la formación imprescindible para complementar la deficiencia en habilidades indispensables.
  • Asegurar que los puestos físicos, maquinaria y stock de material para el personal seleccionado estén disponibles.
  • Consideración lógica de subcontratación.
Cronograma

Aunque parezca una aberración tener que subcontratar personal o servicios a empresas externas teniendo una plantilla de ingenieros, material y herramientas. En el mundo empresarial y de desarrollo de proyectos es una cosa habitual. Por este motivo remarcaré algunas razones por las cuales la consideración de subcontratación se hacen necesarias en según qué situaciones.

  • Lamina las puntas de trabajo que pueden producirse temporalmente.
  • Utiliza recursos humanos ocasionales para un proyecto en concreto, sin la necesidad de incorporarlos permanentemente en la empresa.
  • Reduce costes al tener la empresa subcontratada, al menos teóricamente, una mayor productividad en su especialidad o bien menores gastos generales.
  • Aporta la experiencia y los conocimientos de empresas o profesionales externos, cuando la empresa no dispone de expertos en la materia.
  • Minimiza parcialmente, los riesgos empresariales al trasladárselos al subcontratista.

Una vez comenzado el proyecto, es estrictamente necesario un control de este con un máximo rigor, ya que de ello depende el éxito del proyecto, y no se le puede responsabilizar a “los recursos”, el control de éste, puesto que es una responsabilidad ajena a su trabajo.

El control de proyecto se basa en unos ítems básicos que a continuación se detallan.

  • Obtención de datos que posibilitan medir el progreso realizado.
  • Comparación respecto al indicador planificado para detectar desviaciones.
  • Evaluación de las causas que motivan los imprevistos.
  • Corrección que reconduzca la desviación, si es negativa, o que saque partido de la misma si es positiva.

Una vez identificada la desviación es importante reaccionar ante esta, y no aspirar a que a pocos días, meses o horas antes de la entrega, se actúe sobre este último desviamiento (la entrega), haciendo imposible la recuperación sin repercutir en la calidad. Es de vital importancia el seguimiento de los proyectos durante la vida de estos y no cerca de la fecha de finalización.

  • Paralizar la tarea
  • Revisar la situación y analizar las causas
  • Proponer soluciones y seleccionar la más idónea
  • Conseguir el apoyo de todas las partes implicadas, incluso del cliente
  • Actuar o implantar la solución propuesta
  • Continuar el seguimiento y la medición.

Desde mi punto de vista, considero que si se tienen en cuenta estos factores en la gestión de los proyectos ya sea por su ausencia, o no, en el momento de evaluar si el proyecto ha sido exitoso o no, se ha de observar por quien y de qué modo se han llevado a cabo estas tareas. Considero que es importante atribuir al valor del proyecto un alto porcentaje de responsabilidad de su éxito o fracaso a su gestión.
El éxito del proyecto está muy ligado a una buena gestión, y no se puede atribuir toda la gestión interna de un proyecto a un ingeniero de desarrollo (ámbito R+D), técnico o recurso, o si, pero se ha de tener en cuenta, que el  aporte que pueda realizar a la gestión es extra a su trabajo y que el prisma por el que ve un “recurso” no es el mismo que el de un gestor.

Consideraciones para la gestión de proyectos R+D (Información)

Este post muestra algunas consideraciones a modo de información que se han de tener en cuenta en el desarrollo de un proyecto R+D (es análogo a otro tipo de proyectos). El ingeniero o ingenieros R+D que forman parte de un proyecto con esta información, se podría considerar, indispensable para poder responsabilizarse de su propio trabajo y aportar de forma constructiva al desarrollo de éste.

En un principio se considera importante que la información que ha de llegar al ingeniero, ya sea, de forma escrita o de exposición-reunión, sea la más extensa posible. La lista que se detalla a continuación sería lo que se considera a grandes rasgos la típica información que forma parte del inicio de un proyecto.

Proyectos

Gestión de proyectos

Como información general, poco técnica pero importante:

  •  Oferta de la empresa y los riesgos de las cláusulas administrativas y de prescripciones técnicas particulares.
  •  Caracterización del cliente y su organización.

 

De carácter técnico y gestión:

  • Esquema o definición del proyecto, objeto, objetivos, alcance y resultados.
  • Estructura de descomposición de tareas.
  • Programación del proyecto, incluyendo la distribución de recursos.
  • Presupuesto del proyecto.
  • Procedimientos de trabajo, teniendo en cuenta los relativos al inicio, calidad, cambios, riesgos, control y finalización.
  • Subcontrataciones previstas.
  • Normativa de aplicación técnica y legal.
  • Estudios previos.
  • Datos iniciales y estudios de campo.
  • Organigrama del proyecto, comprendiendo la distribución de funciones, responsabilidades y jerarquía.

Remarcar el punto de la lista de la distribución de recursos, importante para aclarar la cantidad de horas dedicadas a cada aspecto del proyecto, verificar si el proyecto se ajusta al presupuesto y hacer un seguimiento más exhaustivo del mismo. No hace falta decir, que considerar un cierto número de horas para todo el desarrollo a un solo recurso, como podría ser un único técnico, por ejemplo, las posibilidades de éxito son remotas. Ya que éste ha de gestionar el tiempo de todos los aspectos del proyecto sobre la marcha y esto debería haberse contemplado previamente. Son problemas causados por una asignación limitada de recursos a un proyecto.

Dentro del marco de trabajo del ingeniero del R+D hay ciertas responsabilidades que no se les puede exigir o intuir a realizar por estos, todo el esfuerzo del ingeniero ha de estar focalizado en el desarrollo de las funciones marcadas por el gestor del proyecto, denominado normalmente Project manager, ya que forman parte de la gestión del proyecto.

Seguramente tienen que haber excepciones según el tipo de ingeniería o embergadura de proyecto y variar alguas de estas consideraciones, augentar o limitar la cantidad de información.