Etapas del duelo para científicos de datos y de TI
Medio: decideo.com
País: Latinoamérica
Sección: Opiniines de expertos
Fecha: 07/01/2019
Autores: Stewart Robbins y Greg Loxton
Páginas: ---
Tipo de nota: Nota común
La marea fluye, sin duda, en el sentido de estas nuevas herramientas. Los líderes de las grandes organizaciones se emocionan, despliegan programas de gran presupuesto, contratan a un costoso equipo de especialistas y luego el departamento de Tecnologías de la Información deja de hacer su trabajo. Así al menos es como lo ven los científicos de datos.
Esto provoca frustración y duelo tanto en los científicos de datos como en los equipos de TI, pero no tendría que volverse un problema para ninguno de los dos – si contemplamos los escenarios de problemas comunes y las posibilidades de colaborar y proveer a la compañía soluciones de largo plazo que confrontan tanto los científicos de datos como los equipos de seguridad informática.
Pero, antes de encontrar una respuesta analítica, a menudo es necesario pasar por las diferentes etapas del duelo.
Primera etapa: rabia y negación
Después de que un científico de datos se une a una compañía y quiere empezar a usar herramientas de código libre que aún no han sido aprobadas, con frecuencia tiene que pedir autorización. La conversación puede ser similar a esto:
Científico de datos: “Necesito instalar R Studio y descargar bibliotecas de CRAN (https://cran.r-project.org/), para poder crear algunos algoritmos de aprendizaje automático para generar valor de negocio real. ¿Cómo lo hago si mi computadora está bloqueada?”.
Científico de datos: “No, pero es una tecnología de código libre. No es necesario comprarla y puedes descargarla fácilmente”.
IT: “Bueno, necesitas que sea aprobada primero”.
Científico de datos: “OK, ¿cómo consigo eso?”
Lo estricto del proceso es entendible, sin embargo. La responsabilidad primordial de los equipos de TI es asegurarse de que los datos estén seguros y bajo control, que no existen riesgos para los sistemas de TI principales, que esos servicios se ejecuten sin obstáculos y que los acuerdos de nivel de servicio (SLA, por sus siglas en inglés) se cumplan.
Permitir la utilización de cualquier pieza de software que no se encuentre totalmente habilitada y que no cuente con el soporte del proveedor de la plataforma, sería un acto de negligencia. A fin de cuentas, el equipo de seguridad informática será la primera instancia culpada si algo sale mal. Por ello, tienen que ser precavidos.
Pero en este punto el científico de datos estará deseando haberse unido a una compañía de mente más abierta y con frecuencia lo hará: se irá a una “mejor” compañía, lo que significa que el proyecto no cumplió con lo prometido. O puede ser aún peor, alguien preso de la frustración hackea el sistema para instalar su herramienta de cualquier forma y eso provoca el quiebre del sistema de producción.
Esto ha pasado en el mundo real y aquí es donde la historia suele terminar: sin embargo, no tiene por qué hacerlo. La pregunta debería ser: ¿las empresas tradicionales pueden utilizar fuentes de código abierto?
Segunda etapa: negociación
Como sucede en cada empresa, los empleados deben regirse en su trabajo por las limitaciones (como las de seguridad) fijadas por la compañía y eso a menudo significa ser creativo en la forma de pensar. La primera cosa que debe hacerse es dar un paso atrás y preguntarse: “¿Cuál es el problema que debe ser solucionado?”.
Para brindarle a la empresa las soluciones que realmente necesita, los diferentes departamentos deben colaborar y ponerse de acuerdo en una estrategia analítica; definir lo que quieren conseguir, cómo quieren conseguirlo y qué herramientas necesitan para lograrlo.
No hay realmente un sustituto para el ejercicio de sentarse alrededor de una mesa e intercambiar opiniones para encontrar una solución que funcione. Realmente creemos que esto debe hacerse de esa forma: el resultado es superior al que se puede lograr con una reunión virtual o a través de una extensa cadena de correos.
La ventaja de contar con la colaboración de miembros de la organización será que la subordinación a los procesos internos hará que se llegue más efectivamente a la solución – sin burlar las normas sino sacándole provecho a la experiencia que tienen las personas haciendo realmente que las cosas se ejecuten.
Construir el caso de negocios para el cambio -cuantificando el beneficio de un “arreglo adecuado” y considerando esto frente al esfuerzo de componerlo en el contexto de una visión estructural futura – se convierte en una actividad crítica que el equipo tiene que asumir.
Los científicos de datos deseosos de incorporar nuevos programas y herramientas en sus compañías deben ser capaces de responder algunas preguntas clave:
¿Cuál es el caso de uso y por qué se identificó una biblioteca de código libre para ello?
¿Este requerimiento puede resolverse de otra forma empleando herramientas con las que ya cuenta la organización (herramientas tradicionales como SQL o SAS)?
¿Cuál es el ámbito mayor para el resultado de este trabajo -por ejemplo, ¿qué sistemas/aplicaciones se necesitan integrar para aumentar el valor del negocio a futuro?
En nuestro próximo artículo, estudiaremos cómo la sociedad entre los científicos de datos y el equipo de TI puede ayudar a proveer mejores soluciones de largo plazo para la compañía, que puedan mantener a ambas partes contentas y brindando los mejores resultados para la empresa.