Vamos a hablar de algo que me ha sucedido a mí (y me sigue sucediendo) y a mucha otra gente cuando asume ciertas responsabilidades o estatus en sus áreas de conocimiento y trabajo. No, no es que debido a eso atraigas más al sexo opuesto, eso sólo me pasa a mi. Estoy hablando del Síndrome del Impostor.
Y es que llegas a un proyecto, hablas con un amigo o compañero de profesión, hablas con un cliente o asumes una responsabilidad acorde a tu conocimiento y sientes que estás engañando a los demás, que tu no tienes los requisitos ni el conocimiento para asumir ese estatus, o responsabilidad. Sientes que eres un impostor, asumiendo un rol para el que no tienes capacidad o conocimiento.
¿Qué es el Síndrome del Impostor?
El síndrome del impostor se caracteriza por la creencia persistente de no ser lo suficientemente bueno o competente, a pesar de evidencias que demuestran lo contrario. La persona puede sentir que su éxito se debe a la suerte, o que ha engañado a los demás para que piensen que es más competente de lo que realmente es.
Esto puede suceder en muchos ámbitos de la vida pero se expresa con más claridad en el mundo laboral, al estar muy marcadas las responsabilidades y los perfiles.
Características Principales
Hay varias características del síndrome del impostor que se pueden dar
Auto-duda: Una desconfianza constante en las propias habilidades y logros.
Atribución a factores externos: Tendencia a atribuir el éxito a la suerte o a la ayuda externa.
Miedo al fracaso: Miedo constante de no cumplir con las expectativas y ser descubierto como un «fraude».
Perfeccionismo: Estándares personales extremadamente altos y miedo a cometer errores.
Resumiendo, crees que no vales para la responsabilidad que tienes, ya sea porque crees que estás engañando al resto o porque tu visión es de llegar a retos imposibles.
No sé decir «No»
Uno de los problemas es meterte en jardines que te van a generar incertidumbre o que están por encima de tus posibilidades y habilidades. No saber decir que «No» a los demás o a ti mismo te puede meter en un hoyo, en el cual creas que cavando más y más lograrás salir, y es justo al contrario.
Alguno sale por Nueva Zelanda
No sé. No puedo. Tengo otras tareas más prioritarias. Es imposible. No es mi responsabilidad.
Decir estas frases no te hace peor trabajador. Ser sincero es un aspecto positivo, ahora bien, en la sinceridad también está la responsabilidad siempre puede ir acompañado de un «haré lo que esté en mi mano» (pero no más de lo posible).
Nadie lo sabe todo y nadie es perfecto
A veces nos comparamos con otras personas que vemos como superiores a nosotros. No son perfectos, tu tampoco y nunca lo vas a ser (menos mal).
Yo nunca llegaré a sazonar así el entrecot
La estupidez es la felicidad
Si tienes este tipo de pensamientos, es porque eres capaz de evaluar las situaciones y fijas unos niveles de conocimiento y destreza inalcanzables, que son los que tú entiendes que son los óptimos para satisfacer una tarea. Pero la gente «normal» les vale con saber atarse los cordones, hacer lo que les mandan sin pensar en mejorarlo, hablar de fútbol y de política. Ellos en su falta de metas y autoexigencia son felices, y tú no. No te digo que hables de fútbol y política, pero tómatelo con calma. «Piano, piano si va lontano».
Métete un lápiz por la nariz para mejorar la experiencia
Celebra tus éxitos, valórate
Identifica y valora tus logros, si no te salen siéntate a escribirlos, si no te salen pregúntaselo a alguien de confianza que tendrá un juicio externo más claro. Ponte metas realistas y celebra su consecución.
Acabo de ir al baño. ¡Si!
En conclusión
No sé qué hago yo hablando de esto cuando no soy experto en nada de esto. Tampoco sé porqué tengo un blog de tecnología, si no soy ningún gurú y me falta mucho por conocer, hay mucha gente con mucho más conocimiento que yo. Voy a dejar el blog, me voy a apuntar a todas las ingenierías que haya y, cuando las tenga, podré ir dando lecciones. ¿Qué me he creído?
Hoy en «palabros en ingles de moda que usar en tecnología» vamos a hablar de los tipos de implementación de proyectos TI Greenfield, Brownfield y Bluefield.
Spoiler: que uno empiece por Green no significa que no pueda ser un marrón.
Los términos Greenfield y Brownfield provienen el mundo de la planificación urbanística y posteriormente se usaron para cualquier tipo de proyecto en cualquier ámbito. En este caso vamos a hablar de proyectos de implantación de TI, pero se va a entender la esencia para cualquier tipo de proyecto.
Greenfield
Greenfield se refiere a la creación de sistemas o proyectos desde cero, sin restricciones previas por trabajos existentes como un campo verde listo para ser construido (del urbanismo). En el ámbito tecnológico, esto implica la libertad de diseñar y construir utilizando las tecnologías más modernas y las mejores prácticas sin tener que considerar la integración o compatibilidad con sistemas antiguos.
Si conoces esta imagen ya eres un poco eXPerimentado
Vamos, un unicornio alado que resuelve todos los problemas sin mirar atrás. La realidad suele ser menos mágica. Esto es que implantes una solución que no se tenga que integrar con nada pasado y que resuelva un problema que o bien el cliente no tenía nada o bien el cambio es tal que es como hacerlo sin tener en cuenta lo existente.
Yo he estado en algunas de estas implementaciones, pero más porque se olvida el pasado y se realiza reingeniería de procesos.
Ventajas de los proyectos Greenfield
Bueno pues están bastante claras. Aunque alguna de ellas puede ser un arma de doble filo y suponer un reto.
Innovación: El cliente, y nosotros como implantadores, podemos elegir los productos, tecnologías y soluciones más innovadoras, sin restricciones (más allá del coste y el conocimiento) siempre se sea justificable y aporte el máximo valor. De esto se trata este trabajo, de modernizar empresas aportando las mejores soluciones y más innovadoras para estar en la vanguardia y tener una ventaja competitiva con la competencia.
Diseño: Permite tener libertad para diseñar la solución sin nada que nos ate y nos obligue con condicionantes.
Facilidad de mantenimiento: Al construir con tecnologías actuales, los sistemas son generalmente más fáciles de mantener y actualizar. Generalmente, que yo ya he visto mounstros de pocos años de vida.
Desventajas de los proyectos Greenfield
A su vez también tiene retos que sortear. Y aquí voy a repetir algunas de las ventajas, porque pueden traer problemas asociados.
Innovación: El papel lo soporta todo, y como el comercial de turno le de por vender lo último, de lo que no hay ni especialistas en el mercado, terminas en un Shitfield de campeonato. Además las empresas como SAP, Salesforce, etc a veces sacan productos muy innovadores que fallan más que una escopeta de feria. Y ahí estas tú, arreglandoles sus errores.
Diseño: Partir de la hoja en blanco también genera algo de vértigo. Además las reuniones con negocio y los keyusers depende mucho de la gente involucrada. Puede ser algo complicado de manejar.
Costo y tiempo: Diseñar y desarrollar un nuevo sistema puede requerir una inversión significativa de tiempo y recursos. Muchas reuniones para extraer requisitos, prototipos, pruebas de concepto, etc.
Brownfield
Brownfield se refiere a la transformación o cambio de sistemas existentes. Se trata de actualizar, extender o integrar nuevos componentes en infraestructuras o sistemas de software ya existentes. Puede ser un cambio de tecnología donde el cliente quiere mantener su funcionalidad pero usar una nueva tecnología como palanca para mejora, o puede ser cambio total de una funcionalidad pero en medio de un ecosistema complejo de integraciones.
No sé porqué quieren cambiar el sistema de gestión actual. ¡Si está perfecto!
Aunque comiencen por Brown, no necesariamente son peores que los Greenfield. Son los proyectos más habituales. Cambiar una pieza obsoleta por otra en un ecosistema complejo.
Ventajas de los proyectos Brownfield
Los proyectos Brownfield también tienen ventajas asociadas, quizás en el mundo del urbanismo sea más complejo, pero en el mundo de TI el que haya ya un camino sirve para fijarse en aciertos y errores.
Diseño más guiado: Al tener ya un mapa de procesos, casos de uso, funcionalidades imprescindibles, integraciones a mantener, etc, el diseño está más claro, pudiéndonos centrar en las áreas de mejora.
Aprovechamiento de activos existentes: Permite la reutilización de partes del sistema que aún son funcionales o valiosas.
Reducción de costos y tiempo: A menudo, es más económico y rápido mejorar un sistema existente que construir uno nuevo desde cero. Podemos decir que los esfuerzos del proyecto se mueven de una a otra etapa. Cuando ya tienes un sistema o aplicación desplegado el cliente sabe identificar su funcionamiento, sus puntos fuertes y sus debilidades.
Menor riesgo: Trabajar con tecnologías y sistemas probados reduce la incertidumbre.
Desventajas de los proyectos Brownfield
Dependencias con tecnologías obsoletas: Las dependencias con sistemas antiguos pueden limitar la innovación y la eficiencia. Además de no permitir implementar toda la funcionalidad posible en el sistema que estemos proponiendo. ¿Quién iba a decir que las comunicaciones Host-Host no iban a ser para siempre? ¿Qué es eso de REST? ¿OData?.
Complejidad y mantenimiento: Integrar lo nuevo con lo viejo puede resultar en sistemas más complejos y difíciles de mantener.
Resistencia al cambio: En proyectos Brownfield, puede haber una mayor resistencia al cambio, tanto a nivel técnico como cultural, dentro de la organización. Los usuarios y el personal técnico pueden estar acostumbrados a los sistemas existentes, lo que dificulta la adopción de nuevas soluciones.
Riesgos de seguridad: Los sistemas antiguos pueden contener vulnerabilidades de seguridad no detectadas o no corregidas, lo que puede representar un riesgo significativo al integrarlos con nuevas tecnologías o al intentar modernizarlos.
Retos en la gestión del proyecto: La gestión de proyectos Brownfield puede ser más compleja debido a la necesidad de equilibrar la operación continua de los sistemas existentes con el desarrollo e implementación de las nuevas soluciones.
Bluefield
El término Bluefield, aunque no es un término ampliamente utilizado en todo TI, en SAP tiene un papel específico, específicamente en la migración a sistemas hacía SAP S/4HANA, se considera una estrategia híbrida que combina elementos de los enfoques Greenfield y Brownfield. Este método permite a las empresas adoptar nuevas funcionalidades mientras conservan elementos valiosos de sus sistemas SAP existentes.
En un proyecto Bluefield, las organizaciones pueden seleccionar y migrar sólo los datos y procesos que son relevantes para su negocio actual, permitiendo mantener personalizaciones sin necesidad de rediseñar todo el sistema. Esto facilita una transformación que es documentada y clara, y que puede ejecutarse según las especificaciones del negocio. La implementación Bluefield también destaca por ofrecer flexibilidad, ya que permite la transición de sistemas y datos de manera selectiva, lo cual es ideal para empresas que buscan minimizar interrupciones y riesgos durante la migración
Ni Green, ni Brown, póngame un poco de todo
Por ejemplo, una empresa puede decidir utilizar Bluefield cuando necesite consolidar varios sistemas SAP locales en una plataforma SAP S/4 Hana unificada sin perder la continuidad de los datos históricos. Además, esta estrategia es útil para organizaciones que requieren una integración detallada y personalizada que no sería posible simplemente con un enfoque Greenfield o Brownfield.
En resumen, Bluefield ofrece un equilibrio entre la innovación y la utilización de activos existentes, proporcionando una opción viable para las empresas que necesitan tanto mantener como renovar sus sistemas con nuevas tecnologías.
En conclusión
En el afán de ponerle nombre a todo y adaptar las palabras que vienen del inglés vamos a ir asumiendo todo este tipo de términos que, de primeras, no van a sonar nada y luego ya los usarás en tu día a día.
Ya sabéis:
Hay que dejar pasar al menos cinco minutos desde que aprendes algo nuevo hasta que miras con desprecio a quien todavía no lo sabe
Confucio, el inventor de la Confusión año 500 A.C.
En resumen, ya sea que optes por un Greenfield innovador, un Brownfield eficiente o un Bluefield equilibrado, lo importante es encontrar la estrategia que mejor se adapte a las necesidades específicas de tu negocio. Y si te pierdes entre tantos términos, al menos ya tienes un arsenal de palabros nuevos para tu próxima reunión.
Así que me voy a una Meeting vía Call sobre un proyecto Greenfield que vamos a hacer Agile, que tengo luego un Afterwork.
Ahora, después de tres de meses del cambio realizado ya puedo volver a decir de nuevo «Cambio de rumbo».
Vuelvo a ser Freelance, vuelvo a un cliente conocido, que me quiere y del que conozco el negocio a la perfección. En este caso vuelvo con la empresa Avvale que, durante este proceso de cambio, no me ha podido tratar mejor y estoy agradecido.
Esto me ha llegado gracias al Networking, a que me conocían y me han dado todas las facilidades para entrar a trabajar con ellos. Tengo grandes amigos en Avvale (y en muchos otros sitios), gente que me conoce personal y profesionalmente. Por ahora entro como Freelance, que es donde me encuentro a gusto, pero ¿Quién sabe?, ahora lo que quiero es construir y, entre todos, alcanzar metas haciendo las cosas bien.
Quien quiera saber los motivos de que me haya ido de Deloitte que pregunte, dejo grandes amigos allí también y buenos recuerdos. Espero que les vaya bien y que nos veamos en este mundo que es un pañuelo.
Hoy vamos a hablar de eso que aparece en tu vida de vez en cuando, que tu no quieres que pase, pero que es inevitable, al principio te enfada y te genera frustración, pero luego comprendes que puede ayudarte conocer y saber lo que pasa para no cometer errores mayores. No, no vamos a hablar de diarrea, bueno, un poco sí. Hoy vamos a hablar de los DUMPs y errores en SAP.
DUMPs
Lo primero que tenemos es que definir qué es un DUMP en SAP. Los DUMPs son los registros que se generan cuando un programa ABAP se ejecuta y algo sale mal que no puede ser manejado por el programa. Es un punto de ruptura o fuga de un programa ABAP en SAP.
Normalmente se tratan de errores generados por código de cliente (Z), normalmente. Pueden generarse en código estándar también, pero esto supondría una corrección por parte de SAP y una actualización del sistema vía support packages o notas. Y todos sabemos que todos los sistemas SAP están siempre, siempre, siempre actualizados ¿no? (no).
Mi cara cuando llego a un proyecto y pregunto por el nivel de parches
Sea como fuere, cuando una parte del código genera un error no controlado, se interrumpe y muestra un DUMP. Y si el programa se está ejecutando en fondo, se interrumpe y genera el DUMP igualmente pero está vez no hay usuario para verlo en directo claro.
Transacción ST22
La herramienta con la que contamos para buscar, identificar y analizar DUMPs es la ST22. Cuando accedemos a la ST22 lo primero que veremos será una pantalla de búsqueda como esta:
Donde tenemos, como importante:
Botón de Hoy: Nos permite acceder a la lista de Dumps de hoy en el sistema donde estamos logados, sea cual sea el usuario que generó el error. A la derecha del botón nos dará un contador del total de registros que coinciden.
Botón de Ayer: Nos permite acceder a la lista de Dumps de ayer en el sistema donde estamos logados, sea cual sea el usuario que generó el error. A la derecha del botón nos dará un contador del total de registros que coinciden.
Bloque de Selección propia: Nos permite buscar DUMPs por otros criterios que los simples «Hoy» y «Ayer». Por defecto vendrá con el usuario y el día de hoy, pero se puede cambiar. En mi experiencia yo solo lo he usado para buscar por otras fechas que no sean «Hoy» y «Ayer». También para filtrar por un usuario concreto.
Una vez ejecutada cualquiera de las opciones veremos la lista de DUMPs que concuerde con los criterios de selección ejecutados.
Listado de DUMPs
Donde como datos interesantes tenemos:
Fecha y Hora: Cuando se produjo el DUMP.
Usuario: Usuario de ejecución del programa que generó el DUMP
Conservar: Este campo refleja si un DUMP concreto ha sido marcado para ser guardado y no ser borrado en el job diario de limpieza de histórico. Para marcar como guardado o liberado debemos marcar un DUMP y pulsar el icono del candado de arriba.
Error tiempo ejecución ABAP: Es el tipo de DUMP que se ha generado. Luego vemos los tipos más comunes y su significado.
Programa: Lugar del código que ha generado el DUMP.
Si hacemos doble click encima de cualquier linea o le damos al primer icono de la botonera veremos el detalle de ese DUMP.
Vista de detalle del DUMP
Donde veremos que tenemos mucha información. Vamos a intentar desgranarlo porque esto es la parte importante de este artículo. No voy a explicar cada uno de los apartados, porque algunos de ellos no sé interpretarlos ni nunca me han hecho falta. Vamos a hacerlo de forma práctica en base a mi experiencia. Por lo tanto a continuación desgranaremos aquellos que creo fundamentales para saber identificar el error que subyace del DUMP.
Cabecera del Dump
Donde te da los datos básicos de cabecera del DUMP. Donde los más importante son:
Err.tmpo.ejec: El tipo de DUMP que estamos viendo
Programa ABAP: El programa que generó el DUMP
Fecha y hora: El momento en el que se generó.,
Texto Breve
Nos da un resumen muy somero del error ocurrido. Arriba he puesto varios ejemplos de distintos tipos de DUMPs. Nos da cierta información que puede ser importante, como por ejemplo la excepción no controlada que genera el DUMP o el motivo básico del error.
¿Qué ha sucedido?
Es una explicación un poco más extensa, siendo también muy resumida. Puede darnos algo de información dependiendo del tipo de DUMP.
¿Qué puede hacer?
En general este bloque no suele dar información muy valiosa, en algunos casos, como en el DUMP RFC_NO_AUTHORITY de arriba nos da algo más de los permisos que faltan por otorgar.
Análisis de Errores
Empieza la fiesta, este bloque ya puede contener información muy valiosa del error que ha sucedido. Cada tipo de DUMP contará con una información explicativa que puede ayudarnos a saber qué ocurrió.
Notas para corregir errores
Este bloque nos ayuda a buscar notas en el SAP Support Portal o para abrir una incidencia a SAP.
Info posición de cancelación
Este apartado nos da la posición del código donde se ha producido el error. Siendo importante esta información, en el siguiente punto tenemos la misma información pero con más funcionalidad,.
Detalle código fuente (Texto fuente modificado)
Ojo, que estamos en uno de los apartados fundamentales para saber interpretar un DUMP. Nos dice el punto exacto, con su posición dentro del código. Además, y más importante, si hacemos click entraremos dentro del código en cuestión. Con esto podemos poner un break point y volver a probar el proceso que da error para ver el motivo en debugging., Tambien llegamos al código pulsando el icono Editor ABAP de la barra de herramientas superior.
Llamadas/Eventos activos
Apartado también fundamental. Nos dice la pila de llamadas que se han ido haciendo para hasta llegar al código que nos da error. Esto es importante porque, en ocasiones, el origen del error no está en el código que ha fallado, sino que es consecuencia de algo que ha pasado antes. Por ejemplo, si no le pasamos una referencia a un objeto instanciada a un método subordinado, posiblemente el código dentro de ese método de error, pero el origen es anterior. Otro ejemplo, si no manejamos la excepción que devuelve un código subordinado, la excepción la da ese código, pero si ponemos un TRY-CATCH en el inmediatamente superior podemos arreglarlo.
No los considero fundamentales para la investigación y descubrir el motivo del error. Seguro que alguno habrá importante, pero yo no los uso.
Recepción de emails sobre DUMPs
Ahora bien, una vez visto como buscar e interpretar un DUMPs, tenemos claro que si estamos ejecutando un proceso y nos da un error podemos saber donde ir a verlo y cómo interpretarlo. Pero ¿si el DUMP se genera en un proceso en fondo? ¿Si es en producción por un usuario del sistema? ¿Cómo podemos enterarnos de que ha sucedido? ¿Tenemos que estar entrando todos los días varias veces a comprobarlo o esperar la incidencia?. No, para eso tenemos la posibilidad de que el sistema nos mande mails de los DUMPs.
Para eso tenemos tres opciones por un lado podemos crear un job en fondo sobre el report RSSHOWRABAX con una variante del día anterior.
Job Sobre el report RSSHOWRABAX
Luego programamos un job sobre este report con la variante que hemos creado.
Le damos al botón Destino Listas SPOOL e introducimos nuestra dirección de correo.
Elegimos la periodicidad
Y al ejecutar veremos el mail saliente en la SOST
Nota 176492 – Automatic email when an alert occurs (RZ20)
Podemos ver en la nota de SAP «176492 – Automatic email when an alert occurs (RZ20)» la forma de, usando la RZ20 y el CCMS cada vez que se produzca un DUMP recibir un mail de alerta. Pero el procedimiento de alta de esta alerta es realmente complejo, con acceso al mandante 000 incluso. No lo veo muy claro.
Hay otra opción, más rudimentaria pero más controlada, es crearnos nuestro propio Report de consulta, recopilación y envío de Dumps vía email. Para ello tendremos que hacer nuestra selección de datos en la tabla que almacena los DUMPs, la SNAP. A continuación os pongo un ejemplo desarrollado por mi, esto pasado a un JOB diario nos da una idea de los DUMPs ocurridos el día, también se puede hacer algo más inmediato programandolo cada hora o incluso como un demonio en el sistema.
&---------------------------------------------------------------------* *& Report ZJOB_SEND_DUMPS *&---------------------------------------------------------------------* *& *& Autor: Jorge Ocampos *& Descripción: Program that collects the Dumps of the system at a given *& time by the selection and sends an e-mail with the summary *&---------------------------------------------------------------------* REPORT zjob_send_dumps.
*&---------------------------------------------------------------------* * T A B L E S *&---------------------------------------------------------------------* TABLES: somlreci1.
*&---------------------------------------------------------------------* * D A T A T Y P E S *&---------------------------------------------------------------------* TYPES: BEGIN OF ty_text_dump, id TYPE c LENGTH 2, ll TYPE c LENGTH 3, errid TYPE snapt-errid, END OF ty_text_dump.
TYPES: BEGIN OF ty_data, datum TYPE string, uzeit TYPE string, uname TYPE snap-uname, errid TYPE snapt-errid, END OF ty_data.
*&---------------------------------------------------------------------* * V A R I A B L E S *&---------------------------------------------------------------------* DATA: ls_text_dump TYPE ty_text_dump, gt_data TYPE TABLE OF ty_data, gt_objtxt TYPE STANDARD TABLE OF solisti1, gt_objpack TYPE STANDARD TABLE OF sopcklsti1, gs_docdata TYPE sodocchgi1, gt_objhead TYPE STANDARD TABLE OF solisti1.
*&---------------------------------------------------------------------* * S E L E C T I O N - S C R E E N *&---------------------------------------------------------------------* SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_datum FOR sy-datum.
SELECTION-SCREEN END OF BLOCK b1.
SELECTION-SCREEN BEGIN OF BLOCK b2 WITH FRAME TITLE TEXT-004.
SELECT-OPTIONS: s_mail FOR somlreci1-receiver NO INTERVALS DEFAULT 'tu mail' OBLIGATORY.
SELECTION-SCREEN END OF BLOCK b2.
*&---------------------------------------------------------------------* * S T A R T - O F - S E L E C T I O N *&---------------------------------------------------------------------* START-OF-SELECTION.
PERFORM get_data.
IF gt_data IS NOT INITIAL.
PERFORM create_message.
PERFORM send_message. ELSE. WRITE:/ 'NO DUMPs in selection!!'. ENDIF.
*&---------------------------------------------------------------------* * F O R M S *&---------------------------------------------------------------------* *&VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV* *&---------------------------------------------------------------------* *& Form get_data *&---------------------------------------------------------------------* *& text *&---------------------------------------------------------------------* FORM get_data.
DATA: ls_data TYPE ty_data.
SELECT * INTO TABLE @DATA(lt_snap_beg) FROM snap_beg WHERE datum IN @s_datum AND seqno = '000' ORDER BY datum, uzeit.
IF sy-subrc = 0. DESCRIBE TABLE lt_snap_beg LINES DATA(lv_lines). LOOP AT lt_snap_beg INTO DATA(ls_snap_beg). ls_text_dump = ls_snap_beg-flist. ls_text_dump-errid = ls_text_dump-errid(ls_text_dump-ll).
MOVE-CORRESPONDING ls_snap_beg TO ls_data. ls_data-errid = ls_text_dump-errid. CONCATENATE ls_data-datum+6(2) ls_data-datum+4(2) ls_data-datum(4) INTO ls_data-datum SEPARATED BY '/'. CONCATENATE ls_data-uzeit(2) ls_data-uzeit+2(2) ls_data-uzeit+4(2) INTO ls_data-uzeit SEPARATED BY ':'.
INSERT ls_data INTO TABLE gt_data. WRITE:/ ls_data-datum, ls_data-uzeit, ls_snap_beg-uname, ls_text_dump-errid. ENDLOOP. ENDIF. ENDFORM. *&---------------------------------------------------------------------* *& FORM create_message *&---------------------------------------------------------------------* *& text *&---------------------------------------------------------------------* FORM create_message.
DATA: ls_data TYPE ty_data, ls_objpack TYPE sopcklsti1.
" Title gs_docdata-obj_name = 'email notification'.
PERFORM add_mail_line USING '<html> <body style="background-color:#ffe4c4;">'. PERFORM add_mail_line USING 'List of DUMPs:'. PERFORM add_mail_line USING '<table style="margin: 10px" cellspacing="0″ cellpadding="3″ width="800″ border="1″><tbody><tr>'. PERFORM add_mail_line USING '<th>Day</font></th>'. PERFORM add_mail_line USING '<th>Time</font></th>'. PERFORM add_mail_line USING '<th>User</font></th>'. PERFORM add_mail_line USING '<th>DUMP</font></th>'.
* table Contents LOOP AT gt_data INTO ls_data.
PERFORM add_mail_table_line USING '<tr><td><center>' ls_data-datum '</center></td>'. PERFORM add_mail_table_line USING '<td><center>' ls_data-uzeit '</center></td>'. PERFORM add_mail_table_line USING '<td><center>' ls_data-uname '</center></td>'. PERFORM add_mail_table_line USING '<td><center>' ls_data-errid '</center></td>'. ENDLOOP.
PERFORM add_mail_line USING '</tbody> </table> </body> </html> '.
DESCRIBE TABLE gt_objtxt LINES DATA(lv_lines).
READ TABLE gt_objtxt INTO DATA(wa_objtxt) INDEX lv_lines.
ENDFORM. *&---------------------------------------------------------------------* *& FORM send_message *&---------------------------------------------------------------------* *& text *&---------------------------------------------------------------------* FORM send_message .
DATA: lt_receivers TYPE TABLE OF somlreci1, ls_receiver TYPE somlreci1. LOOP AT s_mail INTO DATA(ls_mail). ls_receiver-receiver = s_mail-low. ls_receiver-rec_type = 'U'. INSERT ls_receiver INTO TABLE lt_receivers. ENDLOOP.
ENDFORM. *&---------------------------------------------------------------------* *& Form add_line *&---------------------------------------------------------------------* *& text *&---------------------------------------------------------------------* FORM add_mail_line USING p_var.
DATA: ls_objtxt TYPE solisti1.
ls_objtxt-line = p_var.
APPEND ls_objtxt TO gt_objtxt.
ENDFORM. *&---------------------------------------------------------------------* *& Form add_line *&---------------------------------------------------------------------* *& text *&---------------------------------------------------------------------* FORM add_mail_table_line USING p_var1 p_var2 p_var3.
DATA: ls_objtxt TYPE solisti1.
CONCATENATE p_var1 p_var2 p_var3 INTO ls_objtxt-line.
APPEND ls_objtxt TO gt_objtxt.
ENDFORM.
Como este artículo se ha quedado un poco extenso y hay más cosas que contar abordaremos más información en otros artículos posteriores.
En todos los campos, pero especialmente en Consultoría TI, y sobretodo con personas competentes que ascienden desde puestos técnicos a puestos de gestión sin formación de liderazgo , se da situación de Microgestión o exceso de control del trabajo de los subordinados.
A mi me ha pasado, pasar de ser «el que hace» a «el que manda hacer» y saber «dejar hacer» es complicado. Como tú nadie lo va a hacer (de mal), y cuando eres el responsable eres tú el que da la cara, aunque no sepas con todo detalle como se han hecho las cosas.
Identificar la Microgestión
La microgestión se manifiesta a través de:
Control Excesivo y Falta de Delegación: Los gestores microgestionan cuando no delegan tareas y toman todas las decisiones, por pequeñas que sean.
Supervisión Constante y Detallada: Supervisan cada detalle del trabajo del equipo, sin permitir autonomía.
Dependencia en Decisiones del Gestor: El equipo se siente incapaz de tomar decisiones sin la aprobación del gestor.
Esto es como tener un hijo y hacérselo todo. No dejar que se forme con autonomía, no dejando que se construya sus capacidades y que se equivoque y aprenda. (Asi tenemos la generación de cristal tan bonita que viene). Luego esos padres se quejan que les dan mucho trabajo.
Causas de la Microgestión
Pero ¿Por qué sucede la Microgestión? Bueno, algo hemos dicho ya, pero vamos a ordenar las causas:
Inseguridad del Gestor: Miedo a perder el control o a que el equipo cometa errores.
Falta de Confianza en el Equipo: Creencia de que el equipo no puede realizar tareas correctamente sin supervisión. Porque tú las sabes hacer, y nunca tuviste que aprender ni equivocarte.
Cultura Organizacional: Algunas empresas promueven un entorno de trabajo donde la microgestión es la norma. Un ejemplo claro es la micrlimputacion y control de tareas diarias. ¿Cómo pongo el tiempo de ir al baño? Estuve 30 minutos hablando de fútbol, ¿Me abres el proyecto de chorradas para imputar por favor?
Efectos de la Microgestión
Y claro, todo esto tiene consecuencias. Consecuencias que los que trabajamos en esto sabemos y vivimos. Incluso nos metemos en callejones sin salida.
Efectos en la Moral y Motivación del Equipo: La microgestión disminuye la moral y desmotiva al equipo. No deja que los profesionales se enfrenten a los retos, se equivoquen, consigan solucionar los retos y consigan exitos.
Disminución de la Productividad: El exceso de control ralentiza los procesos y reduce la eficiencia. Es obvio, mientras el gestor hace el trabajo de otros, ni deja hacer, ni hace el suyo propio.
Aumento del Estrés y Burnout del equipo: La falta de autonomía aumenta el estrés y puede llevar al agotamiento profesional.
Aumento del Estrés y Burnout del gestor: Cuando la microgestión viene impuesta por la empresa. Ya sea por cultura de querer saber que hacen los empleados cada minuto o bien porque no dota el equipo de conocimiento y experiencia suficiente o ambas cosas. En ese caso, el gestor debería gestionar, pero debajo suyo no hay capacidad para desarrollar la la labor y tiene que estar haciendo, sin quererlo, microgestión.
Del síndrome del Burnout ya hablamos en el artículo:
Bueno, como muchas otras cosas lo principal es parar, observar, analizar y sacar conclusiones. Pero muchas veces en la cultura empresarial eso se toma como una pérdida de tiempo (tiempo=dinero). Entre otras cosas se pueden ver las siguientes señales:
Supervisión Constante: Revisiones frecuentes y detalladas de cada tarea. ¿Qué os parece hacer una reunión diaria de 30 minutos para que me contéis qué hacéis?
Poca Delegación: El gestor realiza tareas que deberían ser manejadas por el equipo. Esta bien seguir conectado a los trabajos del día a día, incluso puedes darte tareas como uno más del equipo, pero deja al resto con las suyas de forma autónoma. Mide los resultados, no el proceso.
Baja Moral y Alta Rotación de Personal: Indicadores de un ambiente de trabajo tóxico. Hay empresas que sobre el papel le dan importancia a la rotación, pero en realidad, su cultura dista mucho de generar ambientes laborales sanos. Algunas solo usan ese índice para castigar o menguar los bonus de los responsables.
Estrategias para combatir la Microgestión
Bueno, esto es sentido común, el problema es que, en ocasiones, se entra en la espiral de Microgestión si darse cuenta, y además la cultura de la empresa puede ser proclive a la microgestión. No obstabte, para combatir la microgestión buenas prácticas serian:
Fomentar la Confianza y la Autonomía: Delegar tareas y confiar en las capacidades del equipo. Medir resultados pero no necesariamente el proceso.
Implementar Técnicas de Gestión Efectiva: Utilizar metodologías ágiles y fomentar la comunicación abierta. Las reuniónes de seguimiento son eso, de seguimiento. Proponer reuniones de pares para ayudas técnicas.
Capacitación y Desarrollo de Habilidades de Liderazgo: Formar a los gestores en técnicas de liderazgo que promuevan la autonomía y la responsabilidad.
Dotar al equipo de perfiles con los conocimientos necesarios: Si el equipo no tiene los conocimientos necesarios, el gestor se verá obligado a hacer su trabajo y parte de los subordinados.
En conclusión
La microgestión es un problema significativo en la consultoría IT que puede afectar negativamente tanto al equipo como a los proyectos. Reducir la microgestión a través de la confianza, la delegación y la formación puede mejorar significativamente el ambiente de trabajo y los resultados del equipo. Es crucial que los gestores y las empresas tomen medidas para evitar este estilo de gestión y fomentar un entorno laboral más saludable y productivo.
Jorge Ocampos 