Tecnología Móvil, M-Commerce y otras cosas

Hace un par de semanas tuve la oportunidad de platicar con un amigo que trabaja en el negocio de la tecnología móvil. Aunque actualmente se dedica a registrar equipos en México, y a asegurarse que cumplan los estándares de las Normas Oficiales Mexicanas, también tiene un interés por analizar y crear arquitecturas de soluciones tecnológicas para dar solución a una diversidad de problemas de negocios.

Un fenómeno de la charla que me pareció muy interesante es la convergencia de dos tecnologías independientes, la telefonía celular y los organizadores personales o PDAs. Esto es, los teléfonos celulares tienen cada vez más capacidad de procesamiento, y los organizadores personales tienen también ahora la capacidad de ser utilizados como teléfonos. De hecho, es muy interesante que existen aplicaciones similares a Skype para PDAs, lo que los convierte en teléfonos utilizando la tecnología de voz sobre IP.

Esta convergencia abre una gran cantidad de posibilidades de aplicaciones y de soluciones de comercio móvil, con mucho mayor alcance de lo que podría tener una aplicación de Internet. Son aproximadamente 15 millones de computadoras las que existen en México, y sólo 8.7 millones de ellas están conectadas al Internet contra un poco más de 63 millones de teléfonos celulares. Esto es, usar servicios como SMS para hacer publicidad tiene un mercado potencial mucho mayor que las aplicaciones de Internet. Con la creciente capacidad de procesamiento de los teléfonos celulares, las empresas, organismos gubernamentales y no gubernamentales tienen cada vez mayor capacidad de establecer contacto con sus clientes o con los ciudadanos para ofrecerles productos, servicios o capacidades de participación ciudadana.

Las aplicaciones van desde el consumo de objetos para personalizar los equipos como tonos de teléfono, imágenes, etc. hasta el equipamiento de fuerzas de ventas encuestadores para el levantamiento de censos nacionales, pasando por los programas de concursos de media noche. El impacto real de las aplicaciones en la vida cotidiana, aún está por descubrirse completamente... ¿Cuál será la siguiente aplicación?

Lluvia de ideas

Todo experto en tecnologías y sistemas de información necesita tener una serie de habilidades para facilitar que grupos de stakeholders puedan conversar sobre sus problemas y alternativas de soluciones. Como comenté la semana pasada, estas ideas necesitan ser representadas en objetos que representen las ideas del grupo, concretas para que puedan ser utilizadas para intercambiar significados y transformables para que faciliten el cambio.

Una forma efectiva de obtener diferentes visiones de un problema es la lluvia de ideas, y quisiera en esta entrada compartir cuáles son los pasos para llevarla a cabo.

1. Plantear pregunta evocadora.- Normalmente el proceso de lluvia de ideas inicia con una pregunta propuesta por el facilitador. El facilitador escribe esta pregunta en el pizarrón o en una hoja de papel rotafolio, y pide a los participantes en la sesión que escriban todas las ideas que se les ocurran sobre la pregunta.


2. Trabajo individual.- Los participantes escriben las ideas que se les ocurran como respuestas a la pregunta evocadora. Pueden hacerlo en una hoja de cuaderno, o el facilitador puede dar hojas de papel y marcadores, pidiendo que escriban una idea en cada hoja.


3. Round Robin.- Se pide a cada participante compartir una idea a la vez, y el facilitador escribe las ideas en el pizarrón, o recoge las ideas escritas en los papeles individuales y los pega en la pared con cinta adhesiva. El uso de hojas de papel permite ordenar las ideas en grupos o clusters, tarea que es más complicada cuando las ideas se escriben en el pizarrón. Se dan tantas vueltas como ideas existan en el grupo.


4. Resumen.- El facilitador puede terminar el ejercicio resumiendo al grupo las ideas en el pizarrón o la pared. En ocasiones, se pide a los participantes emitir "votos" para identificar el grupo de ideas más importante, o crear una lista de prioridades.

La imagen al inicio de esta entrada representa una lluvia de ideas organizada en grupos o clusters. La que se encuentra al final, representa una lista no ordenada de ideas. Hasta la próxima.

Objetos de Frontera

Hace algunas semanas he venido pensando un poco en la importancia que tienen diferentes tipos de objetos para los especialistas en tecnologías y sistemas de información. En la entrada de esta semana quiero comentar un poco de esta importancia, que está relacionada con la figura a la derecha.

Siempre he pensado que los expertos en tecnologías y sistemas de información deberían funcionar como vínculos o enlaces entre los tecnólogos como los científicos de la computación o los ingenieros en sistemas y los encargados de los procesos de negocios en las organizaciones (marketing, planeación, finanzas, producción o desarrollo de política, turismo, salud, educación, etc. si se trata del sector público).

Una parte importante de las relaciones que se dan entre ambas áreas es a través del trabajo en proyectos. Este trabajo está normalmente plagado del uso de objetos. Los expertos en procesos traen ejemplos de los formatos que usan, ejemplos de la forma en la que recopilan, almacenan y recuperan la información, etc. Los ingenieros necesitan, por su lado, representaciones que les ayuden a sistematizar o "incrustar" en la tecnología estas necesidades de negocios. Para lograrlo, utilizan representaciones formales (matemáticas, lógica) y no formales (dibujos, gráficas, descripciones) del problema. Quizá la forma de crear representaciones más conocida consiste en diagramas de procesos, pero también se cuanta actualmente con todos los modelos en UML, mock-ups, prototipos, pseudocódigos, diagramas de entidad-relación, etc.

La pregunta que normalmente me hago al pensar en esta situación es por qué si contamos con tantas herramientas para ser enlace y comunicarnos existen tantos problemas de transferencia de conocimiento en estos proyectos? Bueno, tal vez se deba a la falta de congruencia entre estos modelos u objetos y la necesidad de compartir sintáxis, semántica y promover el cambio.

Paul Carlile (2002) apoyaría este punto de vista, ya que él considera que para que exista un intercambio de conocimiento de calidad, necesita darse en exactamente esos tres niveles:

1. Sintáctico.- En este nivel se hace énfasis en la necesidad de compartir un vocabulario común. De no existir tal vocabulario, compartir conocimiento se hace complicado. Piensa por ejemplo que quisiéramos discutir sobre formas de calcular el ROI para un proyecto. Antes de que cualquier cosa suceda, deberíamos estar de acuerdo en que ROI es la sintaxis de Retorno sobre la inversión.


2. Semántico.- Además de compartir un vocabulario común, las palabras deben de tener significados comunes. Piensa en Retorno sobre la inversión... puede significar años de recuperación de la inversión, TIR, NPV, etc.


3. Pragmático.- Finalmente, compartir información y conocimiento está vinculado a costumbres y prácticas locales. Esto es, cuál es la mejor forma de calcular el ROI? Eso definitivamente depende de mi experiencia y de lo que sea aceptable en la cultura en la que vivo. Si alquien quisiera convencerme de otra cosa, pasaríamos un mal rato discutiendo... tal vez.

Para facilitar el proceso, Paul Carlile comenta que los objetos con los que se trabaja en estos proyectos colaborativos deberían de cumplir al menos con 3 características.

1. Representativos.- Para que podamos ver en ellos reflejado nuestro vocabulario y sintaxis prefereida


2. Concretos.- Suficientemente concretos como para ayudarnos a compartir significados.


3. Transformables.- Para que nos ayuden en el proceso de cambio.

Aunque Paul Carlile aplica estos conceptos en el ámbito del desarrollo y diseño de piezas, definitivamente se han encontrado aplicaciones en otras áreas como en el desarrollo de nuevos productos (Blacj et al. 2004), y por supuesto, en el desarrollo de sistemas de información (Luna-Reyes, 2004).

Referencias

• Black, L. J., P. R. Carlile, et al. (2004). "A dynamic theory of expertise and occupational boundaries in new technology implementation: Building on barley's study of ct scanning." Administrative Science Quarterly 49(4): 572-607.


• Carlile, P. (2002). "A pragmatic view of knowledge and boundaries: Boundary objects in new product development." Organization Science 13(4): 442-455.


• Luna-Reyes, L. F. (2004). Collaboration, trust and knowledge sharing in information-technology-intensive projects in the public sector. School of Information Science and Policy. Albany, NY, University at Albany.

La Organización como un Sistema Socio-técnico

Durante las últimas clases que he tenido con mis estudiantes de Introducción a las Tecnologías de Información y Negocios, hemos estado platicando sobre las relaciones entre diferentes componentes de la administración y los sistemas y tecnologías de información. Estas conversaciones, así como las entradas en los blogs personales de quienes participamos en esta comunidad me han hecho pensar en la conceptualización de las organizaciones como sistemas socio-técnicos.

Este enfoque surgió a mediados del siglo XX, cuando algunos investigadores se cuestionaron por qué a veces el uso de nuevas tecnologías o máquinas no daban los resultados esperados. En muchas ocasiones se culpaba a los humanos... argumentando que tenían muchos vicios y que no querían cambiar... No obstante, algunos investigadores identificaron que en algunos casos existía un problema de alineación entre el sistema técnico (la máquina, el software) y el sistema social (las personas y sus relaciones). Cuando esto sucede, en realidad sería muy complicado lograr un compromiso de las personas hacia el sistema... A pesar de que sabemos esto, no obstante, abundan diseñadores de sistemas que no consideran en sus diseños el componente social, las reglas de negocios, las políticas y estrategias empresariales, las reglas de relación social entre los trabajadores, etc.

Así, si queremos desarrollar tecnologías y sistemas que ayuden al crecimiento de las organizaciones y al mejor funcionamiento de todas las áreas de una empresa, es necesario hacer un esfuerzo importante por conocer las prácticas y formas de relacionarse dentro de la organización, así como los principales supuestos y valores compartidos por los miembros de la mismo. Este conocimiento es primordial para poder diseñar sistemas que logren hacer las prácticas más productivas. La siguiente pregunta es entonces cómo obtener este conocimiento. Creo que esto se encuentra relacionado con la cultura y práctica de crear modelos por los expertos en SI y TI, pero de eso les platicaré en mi siguiente post.

Si alguien quiere leer más sobre la teoría socio-técnica, puede revisar:

Luna-Reyes, L.F., Zhang, J., Gil-García, J. R., & Cresswell, A.M. 2005. "Information systems development as emergent socio-technical change: A practice approach." European Journal of Information Systems, 14(1): 93-105.

Sobre Metodología

Hola nuevamente. Esta semana quiero comentar algunas ideas relacionadas con el diagrama que nos propone Peter Checkland (1998) para reflexionar sobre los aprendizajes que se logran y la teoría que se genera a través de una práctica disciplinada.

Como se muestra en la figura, todo parte de un marco de referencia que normalmente utilizamos para interpretar la realidad. Estos marcos de referencia siempre están presentes. Su forma más común es a través de los llamados "Modelos Mentales" (Senge, 1990). Un modelo mental no es otra cosa que nuestros supuestos y creencias profundas acerca de cómo funciona el mundo y cómo guiar nuestras acciones. El consultor o profesional que trata de mejorar de manera intencional su práctica, debería tener mucha claridad en estos supuestos, y de ser posible, asociarlos con una corriente de pensamiento, que sería la forma más clara o sofisticada de estos marcos de referencia. Por ejemplo, cada vez que estudio algún fenómeno asociado con la tecnología, uso frecuentemente como referencia la "Teoría Institucional" como marco de referencia. Esta teoría (al igual que cualquier otra teoría o mis modelos mentales) organiza mi lectura del fenómeno, y me guía en la selección de información relevante.

Normalmente, en el proceso asociado con la solución de un problema o la descripción o análisis de un fenómeno en el mundo, seleccionamos también un método para actuar. El método normalmente incluye una serie de instrumentos de observación (encuestas, entrevistas, talleres grupales, etc.), y una serie de formas para analizar las observaciones.

Para Checkland, por ejemplo, el método de trabajo de preferencia es la investigación acción , que consiste en una serie de ciclos de acción y reflexión en el proceso de solución de problemas.

Finalmente, se tiene también en mente un problema específico o área de interés. Esta área, en el caso de las tecnologías de información podría ser la seguridad informática, algún sistema de soporte a las decisiones, la integración de información en un proceso, etc.

Al final, el diagrama sugiere que el profesional reflexivo debería de estar aprendiendo sobre los tres componentes. Inicialmente, necesariamente aprende algo sobre el área de interés. En segundo lugar, enriquece su modelo mental o marco de referencia. Finalmente, aprende más sobre el uso del método... Esto por supuesto no sucede forma automática, sino que se da a través de la reflexión sistemática y organizada sobre la práctica y la sistematización y documentación de la acción.

En entradas posteriores les seguiré comentando al respecto. Suerte!!!

Referencias:

Checkland, P., & Holwell, S. (1998). Information, Systems, and Information Systems. Wiley.
Senge, P. (1990). The Fifth Discipline: The Art & Practice of the Learning Organization. Doubleday.