Guía completa de documentación de Salesforce (en un mundo de inteligencia artificial)

La plataforma Salesforce es muy potente. Con cada nueva versión, su org se vuelve más potente, pero también más compleja. Como le dijeron una vez a Spiderman: «un gran poder conlleva una gran responsabilidad». Entonces, ¿cómo puede asumir la responsabilidad real de mantener su organización?

Con todo lo que necesita hacer, la documentación de sus cambios es probablemente baja en su lista de prioridades – pero no debería ser. Tomar sólo un poco de tiempo para la documentación en realidad acelerará los cambios futuros, ya que reducirá en gran medida el tiempo necesario para completar el análisis de impacto del cambio. Sin embargo, puede ser difícil convencer a la gente para que le dedique el tiempo necesario para poner en marcha esa documentación.

Ahora hay otra razón más importante para la documentación org. Y esa razón es la IA…

La IA necesita una gran documentación por dos razones:

1. Los datos son el combustible de la IA. Los datos son el combustible de la IA

AI + Datos + CRM. Salesforce está lanzando capacidades de IA que proporcionan a las organizaciones una enorme ventaja competitiva. Pero la IA requiere datos correctos y precisos. Salesforce ha acelerado las fechas de GA para sus ofertas GPT.

La mayoría de las organizaciones tienen poca documentación, lo que dificulta la comprensión de qué campos se deben utilizar y cómo se rellenan

¿Qué campo? Talla_de_camiseta__c Talla_de_camiseta__c Talla_de_camiseta__c.

¿Pueblado por? Diseño de página, Flow, Apex, integración de terceros, MuleSoft

2. Los metadatos son el combustible de la IA

La IA está leyendo la documentación de la org para que pueda hacerte 100x más efectivo en el mantenimiento de tu org. Usted puede tener una conversación con su org o las notas de la versión. AI puede escribir documentación. Puede crear historias de usuario. Incluso puede recomendar soluciones. ¡Y esto es sólo el comienzo!

Cuanto mejor sea la documentación de la organización, mejores serán los resultados que pueda ofrecer la IA. ElementsGPT ya está utilizando la IA para ofrecer resultados asombrosos.

¿Por qué documentar?

¿Cuántas veces has estado a punto de cambiar un elemento de metadatos y te has preguntado: «¿Por qué se ha hecho así?» y, lo que es más importante, «¿Qué implicaciones tiene hacer un cambio?» Puede que acabes deseando que alguien (quizá tú) se hubiera tomado la molestia de añadir algo de documentación.

Cada cambio que hagas conlleva el riesgo de que rompa algo en tu org. El análisis de impacto de cada cambio con una org sin documentación es una gran pérdida de tiempo. O simplemente no haces ningún análisis y esperas lo mejor

«Me encanta la emoción de borrar un campo y esperar los gritos», no dijo nadie… ¡nunca!

Ser capaz de explotar las nuevas funciones de Salesforce y rediseñar rápidamente sus procesos para responder a los cambios del mercado es el objetivo de toda empresa: ganará la más innovadora y ágil. Pero para la mayoría de los equipos, su org indocumentada supone un lastre para esa agilidad.

Existen razones de peso para que una buena documentación garantice que los desarrolladores construyan lo correcto: menos repeticiones, una implementación más rápida y una mejor adopción por parte de los usuarios. Los enlaces al resto de la documentación agilizan y facilitan la evaluación del impacto. A cambio de muy poco esfuerzo adicional (por ejemplo, enlazar documentos), se construye el conocimiento institucional y se reduce la deuda técnica. Esto significa que cada cambio posterior es más rápido y menos arriesgado.

La razón por la que la IA será difícil de implantar son los niveles de deuda técnica. Los datos de la encuesta IDC Explorer Future of Work mostraron que el 40% del tiempo de desarrollo se ocupa de la deuda técnica. Si a eso le sumamos el tiempo necesario para apagar incendios cada vez que un cambio rompe una org, ¡se desata el infierno! En este sentido, es una negligencia crear una aplicación empresarial básica como Salesforce sin documentación.

En su presentación, «Decluttering Your Org», Christopher Marzilli (Director de productos de Salesforce, Platform Success) nos aconsejó «dedicar un porcentaje de cada versión a la limpieza de la deuda tecnológica (recomendamos un 10-25%)».

Pero ahora se pone realmente interesante..

La IA te hace 100 veces más eficaz

AI puede leer mapas de procesos y generar automáticamente historias de usuario. Crea una historia de usuario para cada recurso asociado a un cuadro de actividad. Estas historias de usuario incluyen criterios de aceptación y secuencias de comandos de prueba que se basan en el texto del cuadro de actividad, las entradas, salidas y recursos RASCI (responsable, responsable, de apoyo, consultado, informado). A nadie le gusta escribir historias de usuario, y rara vez son completas o precisas al 100%. Pues bien, ¡ahora lo son! Y, por supuesto, las historias de usuario que se crean también se pueden editar.

A continuación, AI puede recomendar soluciones que respalden las historias de usuario (adaptadas a su organización), teniendo en cuenta al mismo tiempo el marco de trabajo Salesforce Well Architected (architect.salesforce.com). Las recomendaciones incluyen qué metadatos existentes deben reutilizarse o cambiarse y qué metadatos deben añadirse. Estas recomendaciones se basan en la documentación de su organización, es decir, la nomenclatura y las descripciones de los metadatos.

AI hace un buen trabajo con sólo mirar las etiquetas de metadatos y nombres de API, pero los resultados se salen de la gráfica si usted tiene descripciones que se llenan. Lo que te llevaría ocho horas se entrega en 2-3 min. Y los resultados son a menudo mejores que lo que a ti se te podría ocurrir, porque la IA ha considerado cada elemento de metadatos y también ha tenido en cuenta las mejores prácticas del marco Well Architected.

La IA necesita estándares

Para obtener los mejores resultados, la documentación necesita seguir unos estándares que la IA entienda interpretar. La IA no es magia. Las aplicaciones de IA son indicaciones muy afinadas que están optimizadas para el caso de uso. En esta situación, se trata de escribir historias de usuario y crear soluciones. Los estándares de documentación son los siguientes:

Procesos de negocio: formato UPN (Universal Process Notation) de Salesforce. Se trata de una notación establecida y utilizada en organizaciones de todos los tamaños durante los últimos 20 años. Existen excelentes cursos de Trailhead. Elements.cloud admite la notación.

Diagramas de arquitectura: estándar Salesforce Diagrams. Esto fue introducido por Salesforce en los últimos 2 años. Lucidchart, Miro y Elements.cloud soportan la notación.

Documentación de metadatos: MDD (Metadata Description Definition). Tener un estándar para esto ha surgido y ha sido impulsado por la IA. La IA lee todo literalmente, por lo que las descripciones deben ser claras, concisas y sin ambigüedades. Los elementos de metadatos de Salesforce tienen un campo de descripción, por lo que es aquí donde debe documentarlos. Los cinco principios son Campo de descripción, Por qué no qué, Claridad y concisión, Sin suposiciones y TLA del sector.

¿Por qué no documenta?

Aquí hay tres razones potenciales:

1. No hay caso de negocio
2. Parece una tarea de enormes proporciones
3. No hay tiempo

Vamos a tratar cada una de ellas:

No hay caso de negocio ni urgencia

Necesitas un catalizador. Pues ya tienes uno: LA IA.

La IA te obliga a rediseñar los procesos operativos y a entender los datos. Y lo que es más importante, la IA tendrá presupuesto y apoyo ejecutivo. El momento es ahora. La velocidad a la que evoluciona la IA significa que hay que esprintar para estar preparado para implantarla.

Escala de la tarea

Una de las razones por las que no documentamos es porque a menudo creemos que la documentación es una tarea enorme que está reñida con nuestras exigencias diarias (y nuestro tiempo limitado). Y quizás esté la sensación de que, una vez que hemos pasado por el esfuerzo de crearla, la documentación queda sin leer, perdida en un laberinto de directorios.

Sin tiempo / No es una prioridad

Sin una documentación org clara, tendrás dificultades para entregar un proyecto de IA, y esto pondrá a tu organización en una seria desventaja competitiva. Tampoco podrá aprovechar las ventajas de que la IA apoye su desarrollo.

Incluso antes de la IA, el coste actual de una documentación pobre es muy claro – ¡sólo tienes que leer algunas OrgConfessions!

Enfoque de la documentación de Salesforce

El reto que escuchamos todo el tiempo es el siguiente: «Mi organización es un caos y no tengo ni idea de por dónde empezar». La gente piensa que necesita documentarlo todo. Esto es un error, y es contraproducente. Documenta las cosas que importan.

Entonces, ¿cómo saber lo que importa?

Tenemos este sencillo enfoque de 3 pasos que es práctico, alcanzable y ayuda con el progreso medible – probablemente tendrá algunos proyectos en vuelo a los que puede aplicar este enfoque.

Paso 1: Construir un Diccionario de Metadatos

Todo comienza con Org Discovery. Necesitas construir un diccionario de metadatos que también creará una gran cantidad de documentación automatizada – ahorrándote una enorme cantidad de trabajo. Entonces puedes usarlo para añadir o enlazar tu documentación. He aquí algunas consideraciones sobre diccionarios de metadatos basadas en nuestro análisis de más de 15 mil millones de elementos de metadatos:

• Necesita un diccionario de metadatos para cada organización de Salesforce: Producción y Sandbox.
• Puede que necesite un diccionario de metadatos para otros sistemas fuera de la plataforma principal de Salesforce: Data Cloud, Tableau, MuleSoft, Marketing, Slack, Netsuite, ServiceNow y aplicaciones personalizadas, etc. Pero no nos preocupemos de eso por el momento.
• Los metadatos cambian con el tiempo
• Los metadatos cambian con frecuencia por lo que cada diccionario de metadatos necesita mantenerse sincronizado – esto podría ser tan a menudo como cada noche.
• Los diccionarios de metadatos deben estar sincronizados
• Deberías poder crear elementos propuestos, es decir, que aún no estén en ningún org. Esto es para que puedas documentarlos. Si dejas esta documentación para cuando se hayan creado los ítems de metadatos, será demasiado tarde.
• Para que puedas documentarlos
• Alguna documentación de metadatos se puede crear automáticamente utilizando APIs. Algunos ejemplos son:
  • Etiqueta y nombre de la API.
  • Información específica de metadatos, por ejemplo, Apex – API y cobertura de código.
  • Información específica de metadatos, por ejemplo, Apex – API y cobertura de código
  • Historial de cambios.
  • Dónde se utilizan esos metadatos (análisis de dependencias de varios niveles)
  • Qué tan poblados están los campos y las listas de selección (análisis de impacto)
  • Cuán importantes son los elementos de metadatos (análisis de impacto)
  • Con qué frecuencia se utilizaron los metadatos por última vez (supervisión de eventos de Salesforce)
  • Identificación de duplicaciones y limpieza potencial.
  • Cuándo se utilizaron los metadatos por última vez (supervisión de eventos de Salesforce)
  • Cuándo se utilizaron los metadatos por última vez.
• Deberías ser capaz de mantener documentación de cualquier metadato. En el caso de AI, el principal es el campo Descripción.
• Deberías ser capaz de añadir/enlazar documentación creada manualmente a cualquier metadato. Algunos ejemplos son:
  • Propiedad de las partes interesadas.
  • Propiedad de las partes interesadas
  • Acciones de limpieza sugeridas.
  • Enlaces a todos los tipos de documentos (enumerados más adelante en este artículo)
• <li
• Necesitas poder reportar la información para poder realizar un análisis externo.
• Los tipos de documentos que necesitas
• Necesita notificación de cambios: por ejemplo, un paquete gestionado instalado podría actualizarse e introducir cambios en los elementos de metadatos que usted desconocía.
• El Paquete gestionado es una herramienta de notificación de cambios
• Las API de metadatos de Salesforce pueden cambiar con cada versión importante y se añaden nuevos tipos de metadatos. Las API de metadatos de Salesforce a menudo arrojan errores de sincronización falsos que lleva tiempo analizar y resolver.
• Las API de metadatos de Salesforce pueden cambiar con cada versión importante y se añaden nuevos tipos de metadatos
• El tamaño, la complejidad y la escala de las organizaciones pueden ser significativos. Un diccionario de metadatos y el análisis de impacto podrían ser millones de registros.
• ¿Dónde va a gestionar y controlar las versiones de la documentación de la org: requisitos, historias de usuario, mapas de procesos, notas, especificaciones, capturas de pantalla, etc.?
• ¿Cómo controla el acceso a los equipos que pueden actualizar, ver, colaborar e informar sobre el diccionario de metadatos y la documentación org? Son sólo sus administradores, o incluirá arquitectos y desarrolladores? ¿Cómo colaboran los consultores externos?
• ¿Puede utilizarse también parte de la documentación org como ayuda al usuario final? En caso afirmativo, ¿cómo proporciona un acceso sencillo desde las páginas de registro de Salesforce a las versiones maestras de la documentación?
• Puede utilizar las utilidades gratuitas, crear objetos personalizados en Salesforce o utilizar aplicaciones de AppExchange de pago para crear y mantener el diccionario de metadatos y gestionar la documentación. Pero cada enfoque tiene sus costes, que deben tenerse en cuenta en cualquier decisión. «Gratis» no es gratis; utilizar un enfoque gratuito cuesta el tiempo y el esfuerzo necesarios en:
  • Creación y mantenimiento a medida que cambian las API
  • Mantener actualizados los diccionarios de metadatos.
  • Completar manualmente el análisis de org.
  • Arreglar una org rota porque no tenía suficiente análisis de impacto.
  • Tiempo de inactividad de los usuarios de negocio cuando el org está roto.
• <li

La persona que firma el coste de la licencia de Salesforce puede crear un caso empresarial para comprar una solución completa para gestionar toda la documentación de la organización. Pueden ver los beneficios y presupuestarán hasta un 5% de lo que gastan en Salesforce. El término para esta herramienta es Plataforma de Inteligencia de Cambios – más sobre esto más adelante.

Por lo tanto, si usted es un administrador y está leyendo esto, no piense que tiene que piratear una solución de forma gratuita (cuando sabe que realmente no es compatible con lo que necesita) porque no hay presupuesto. Salesforce se está convirtiendo en una aplicación estratégica, y la alta dirección entiende que necesita presupuestar las herramientas: Change Intelligence Platform, Backup, y DevOps, etc.

Si usted es un consultor que está leyendo esto, puede estar interesado en un proveedor de Change Intelligence Platform. Elements.cloud ofrece una licencia de consultor a un precio que hace que sea una obviedad ($ 500 / año) para su uso en cada compromiso con el cliente.

Paso 2: Elegir un proyecto

No ponga en marcha un proyecto de «documentación orgánica». Será demasiado amplio y tardará demasiado en completarse y mostrar los beneficios. Como consecuencia, nunca dará resultados. En su lugar, utilice un proyecto nuevo o en curso para empezar a crear documentación como parte del ciclo de vida del proyecto.

Algunas documentaciones son más fáciles que otras. Ha creado una especificación, así que vincúlela a los metadatos y procesos afectados. Ha creado un nuevo elemento de metadatos, así que cree una nota especificando por qué lo hizo.

Otra documentación puede llevar más tiempo si tienes que introducir un análisis de negocio más riguroso antes de empezar a construir. Esto es mapeo de procesos, es diseños de arquitectos, es la evaluación del impacto de los cambios, es escribir historias de usuario y agruparlas en lanzamientos.

Si se realiza un análisis más por adelantado, se obtendrán enormes beneficios en la adopción por parte de los usuarios, se reducirá la repetición de tareas y habrá menos reversiones. La entrega en general será más rápida – confía en mí en esto. Sin embargo, habrá una gran presión por parte de la empresa, que considera este análisis como una prolongación del proyecto. Además, existe la tendencia natural a querer lanzarse a la construcción. Por favor, resista esta tentación y luche por un análisis de negocio suficiente.

Una forma de combatir esto es señalar el alcance de la certificación de análisis empresarial y la enorme inversión en el contenido de Well-Architected que está desarrollando Salesforce. Esto demuestra que Salesforce está fomentando y respaldando un enfoque más riguroso.

Algunas reflexiones sobre la selección de un proyecto:

• Asegúrese de que tienen suficiente tiempo presupuestado para hacerlo en cada fase del proyecto: análisis, construcción/prueba, despliegue. Dales tiempo suficiente ya que es la primera vez que lo hacen y puede que necesiten aprender nuevos enfoques y técnicas como UPN o ERD. También necesitarán configurar el diccionario de metadatos.
• No deje la documentación en manos de los usuarios
• No deje la documentación como una tarea a completar al final porque:
  • Se dejará de lado para ahorrar tiempo, o el exceso de proyecto se comerá el tiempo.
  • Se dejará de lado para ahorrar tiempo, o el exceso de proyecto se comerá el tiempo
  • Es más fácil y rápido documentar «en el momento»
• Decida hasta qué punto desea cambiar su enfoque de implementación actual para incluir un análisis de negocio más riguroso.
• Prepárese para un análisis de negocio más riguroso
• Tome nota del tiempo que se tarda en documentar para que pueda añadir el presupuesto correcto a futuros proyectos.
• Tome nota del tiempo que se tarda en documentar para que pueda añadir el presupuesto correcto a futuros proyectos
• Tome nota del tiempo ahorrado en el análisis de impacto porque dispone de un diccionario de metadatos.
• Tome nota del tiempo ahorrado en el análisis de impacto porque dispone de un diccionario de metadatos
• Realice un seguimiento de las reversiones (si las hay) y del tiempo total desde la Idea hasta la Adopción.
• Piense en cómo va a crear los diferentes tipos de documentación y mantener el control de versiones y los vínculos.
• Si dispone de un diccionario de metadatos, piense en cómo va a crearlos
• Si tiene una empresa de consultoría involucrada en el proyecto, necesita asegurarse de que la documentación está en su declaración de trabajo (SoW).

Paso 3: Cómo, qué y por qué

• Cómo: ¿cómo funciona esta parte de la org/negocio?
• Qué: ¿Qué ha cambiado en Salesforce para admitirlo?
• Por qué: ¿Por qué se realizaron los cambios y dónde está la documentación que describe por qué y cómo cambió Salesforce?
• Por qué

Elige un área

Primero elige un área de capacidad, app o proyecto. Elige el área que tenga el mayor nivel de cambio. La documentación marcará la mayor diferencia para el análisis de impacto incluso antes de aplicar la IA. Es posible que desee elegir un área para practicar y probar el enfoque que es de bajo riesgo y bajo perfil.

Para cada área, realice Cómo, Qué y Por qué.

¿Cómo funciona?

Cómo consiste en comprender cómo funciona la empresa y se describe mejor como un simple diagrama de procesos UPN. Se trata de cómo los usuarios utilizan Salesforce para realizar su trabajo. Es cómo funciona la automatización o integración entre bastidores.

Los diagramas de procesos son activos valiosos y tienen tres audiencias. También tienen una vida más allá del proyecto:

1. Administradores, analistas de negocio y desarrolladores: Para el desarrollo de apps.
2. Usuarios finales: material de formación para impulsar la adopción.
3. Usuarios finales: material de formación para impulsar la adopción
4. Auditores: Para las industrias reguladas los diagramas de procesos son la prueba de que estás diciendo lo que haces y haciendo lo que dices.
5. Auditores

Si ya dispone de documentación similar a procesos (flujos rainstorm, diagramas de flujo, mapas de procesos, mapas de capacidades, SIPOC, BPMN, UML, etc.) en otras aplicaciones y siguen siendo actuales, redibújelos utilizando Elements.cloud en formato UPN.

Usted puede pensar que esto es una pérdida de tiempo o retrabajo. Sin embargo, nuestros más de 20 años de experiencia nos dicen que:

• Le llevará mucho menos tiempo de lo que piensa.
• El contenido raramente se pierde
• El contenido rara vez está actualizado, por lo que podrá racionalizarlo.
• Podrá simplificar los diagramas a medida que los redibuje para que sean más fáciles de leer.
• Los diagramas son más fáciles de leer
• Obtendrás desgloses, control de versiones y enlaces a otros activos.
• La IA puede leerlos.

El mapeo de procesos puede parecer desalentador, especialmente cuando se empieza a hablar con los equipos de TI, que a menudo utilizan una notación de modelado compleja. Para el mapeo de procesos de negocio, recomendamos una notación simple que ha sido probada en miles de proyectos en los últimos 20 años.

Los diagramas se pueden dibujar en cualquier formato o estilo, pero UPN realmente funciona, por eso es el estándar de Salesforce:

• Dibuje los diagramas en un flujo de proceso simple de izquierda a derecha, con el objetivo de no tener más de 8-10 pasos de proceso por diagrama (llamados cuadros de actividad)
• El cuadro de actividad es un bloque de construcción único y sencillo para mostrar qué se hace y quién lo hace. Es todo lo que necesita; no necesita muchas formas diferentes, ¡créanos!
• Debe tener líneas entre las cajas con texto. Estas definen los traspasos, que es donde la mayoría de los procesos se rompen – cuanto más específico, mejor.
• Cualquier cuadro de actividad puede ser definido por el usuario
• Cualquier cuadro de actividad puede tener «diagramas hijos» de nivel inferior. Esto hace que cada diagrama sea simple, con el detalle en los niveles inferiores. Piense en las tres audiencias al crear estos diagramas: admin/desarrolladores, usuarios finales, cumplimiento/auditores.
• Los diagramas de actividad pueden ser de cualquier tipo

Lo bueno de esta notación es que sólo hay que preocuparse de una forma. Puedes describir cualquier proceso, por complejo que sea, de forma que todo el mundo lo entienda, sin necesidad de formación.

Así pues, la forma de pensar en un diagrama de proceso es la siguiente: lo que sucede en términos de acciones (verbo y sustantivo) que juntas producen el resultado deseado.

¿Por qué lo iniciamos y por qué lo completamos (entrada/salida)? Quién lleva a cabo estos pasos (rol/recurso) – puede ser un humano o un sistema.

Cómo se lleva a cabo cada paso en detalle (desplácese al diagrama de nivel inferior – esquina azul) o enlace a la documentación de apoyo (clip).

¿Qué metadatos utiliza en Salesforce?

Ahora trabaje paso a paso en cada diagrama de proceso y formule la pregunta para cada paso de actividad: «¿Qué utilizamos en Salesforce para realizar este paso?»

Podría tratarse de un objeto, campo, diseño de página, plantilla de correo electrónico, flujo, etc. – puede vincularlos al paso del proceso.

No se sorprenda cuando descubra que los mismos elementos están vinculados a una serie de pasos de proceso diferentes y son utilizados por diferentes departamentos. Aquí es donde la documentación se convierte en un recurso crítico para el análisis del impacto de cualquier nuevo cambio. Aquí no hay «lo correcto y lo incorrecto», pero decida un enfoque y sea coherente para ayudar a la gente a aprovecharlo. Algunas personas vinculan los niveles más altos de su mapa de procesos a los objetos implicados.

Luego, en los diagramas detallados de nivel inferior, los pasos del proceso pueden tener enlaces a reglas de validación, disparadores específicos o una actividad automatizada detallada que se creó en la automatización.

Pregunte por qué lo hace de esa manera. A continuación, para cada elemento de metadatos que adjunte, actualice el campo Descripción.

Construye sólidos hábitos de documentación

Reserve tiempo para una revisión posterior al proyecto utilizando WWW (lo que salió bien) y EBI (aún mejor si) para ayudarle a refinar su futuro proceso de implementación del proyecto, presupuesto y enfoque.

Utilice el primer proyecto como escaparate para extender el enfoque a todos los proyectos. Tiene que demostrar a la empresa que el tiempo invertido en el análisis de negocio y la creación de documentación les dio un mejor resultado, más rápidamente.

No dé esto por sentado. Asegúrese de que está haciendo un seguimiento de los números del proyecto piloto para que pueda construir una historia fuerte.

La documentación está construyendo el conocimiento institucional de su organización y sistemas. Cada vez que vuelva a visitar y hacer cambios en un área de metadatos que tiene una buena documentación, usted será capaz de acelerar los cambios con confianza. Haga de la documentación una parte cotidiana de cada cambio o acción para evitar futuros problemas. Después de todo, algunos clientes no liberarán cambios que no estén documentados.

El momento más rápido y sencillo para añadir documentación es «en el momento», cuando está fresca en tu mente y recuerdas la lógica que hay detrás – no hay «después». De hecho, Nike lo dijo mejor allá por 1988: «Just Do It»

Pongamos el ejemplo de una regla de validación. Se tarda 30 minutos en construir, validar y probar, pero esto podría tomar dos horas para resolver cuando estás en la misma posición tres meses más tarde. Añadir documentación lleva un máximo de cinco minutos. Podría ser incluso más rápido si crea un diagrama de procesos para comprender el proceso necesario para la regla de validación. Entonces tardará diez segundos en conectar el diagrama del proceso con la validación, sin necesidad de crear documentación adicional.

Como mínimo, rellene las descripciones en Salesforce. ¿En el mejor de los casos? Su proceso de gestión de lanzamiento dice que no puede ir en vivo a menos que exista el nivel mínimo de documentación. Unos rápidos 280 caracteres o una foto serán oro en polvo dentro de seis meses, el equivalente a un tweet para decir «wow – mira lo que acabo de crear, y aquí está el porqué».

El poder de una plataforma

La documentación es algo más que la lista de qué metadatos has añadido en una nueva versión en Salesforce. Hay que añadir la razón por qué lo añadimos, ya que esto da una mayor visión de cómo se utiliza. Por el contrario, se trata de una combinación de diferentes formas de contenido, conectadas entre sí para proporcionar información valiosa, y entregadas en el contexto de las diferentes audiencias que las utilizan: analistas empresariales, arquitectos, administradores, desarrolladores, usuarios finales y auditores normativos.

La razón de tener documentación es que, cuando vuelvas a ella en seis días/semanas/meses, puedas entender el impacto de cambiarla.

Tener toda la documentación en una única plataforma o aplicación significa que puedes utilizar el poder de las conexiones entre la documentación. La IA puede entonces hacer su magia y hacerte 100 veces más productivo.

Nos gusta pensar en ello como las 3 Cs:

La primera C es Contenido. Cualquier cosa creada durante el ciclo de vida de la implementación no debe residir como un silo de información acumulando polvo en un disco duro o en la nube. Todo es contenido valioso.

El poder está en las conexiones. Por ejemplo, puede ver que los elementos de metadatos fueron modificados por tres historias de usuario a lo largo del tiempo debido a dos requisitos empresariales diferentes, y que son utilizados en cuatro procesos empresariales operativos por otros 17 elementos de metadatos.

Cuando se trata de análisis de impacto, se trata de entender el Contexto. Esto significa ser capaz de ver los diferentes elementos de metadatos que podrían verse afectados por un lanzamiento, que es una colección de historias de usuario. A continuación, se trata de poder comprender el riesgo técnico (basado en los elementos de metadatos en Salesforce y otros sistemas) y los riesgos empresariales y normativos (basados en los procesos empresariales operativos).

Estos documentos y conexiones crecen con el tiempo. Juntos constituyen el conocimiento institucional de la configuración de la empresa y los sistemas de apoyo. Reducen la deuda técnica porque aceleran la evaluación del impacto de futuros cambios. Aunque pueda parecer que esto ralentiza la implementación inicial (en realidad no es así), también acelera drásticamente los cambios futuros.

A continuación se muestra un ERD que muestra las interconexiones entre los diferentes tipos de contenido de la documentación, con las conexiones y el contexto, o audiencias.

Objetivos, Feedback, Iniciativas de cambio: Estos son los impulsores del cambio. Pueden ser muy estratégicos («necesitamos implantar Einstein») o tácticos («necesitamos un nuevo elemento de la lista de selección»).

Requerimientos: Se trata de tomar los Objetivos, la Retroalimentación, las Iniciativas de Cambio y describirlos como requisitos de negocio discretos que los usuarios de negocio pueden aceptar. También se utilizan en las pruebas de aceptación del usuario.

Mapas de procesos de negocio: la forma de validar los requisitos consiste en implicar a los usuarios en talleres para trazar los procesos de negocio que se agilizarán con las nuevas aplicaciones. Se trata de una estructura jerárquica de diagramas, con enlaces y control de versiones. Este es el estándar UPN (Universal Process Notation) de Salesforce que recomienda Salesforce.

Metadatos de sistemas, impacto, y dependencias: Los diccionarios de metadatos de las orgs de Salesforce (Prod & Sandboxes) se mantienen actualizados mediante sincronización nocturna utilizando las APIs. El análisis automatizado de los metadatos proporciona el impacto, las dependencias y la población de campos, además de documentación automatizada. También puede incluir futuros elementos de metadatos identificados en el diseño.

ERD/data model and Architect diagrams: Son subconjuntos del modelo de datos completo que cubren el ámbito de la solución. Un ERD de todos los objetos es excesivamente complejo y no ayuda al diseño. También son los diagramas arquitectónicos que muestran las interacciones del sistema. Salesforce tiene un estándar de diseño para estos llamados Diagramas de Salesforce.

Historias de usuario: La definición técnica del trabajo que debe realizarse, a menudo denominado elemento de trabajo. Es el documento clave para DevOps, por lo que está conectado a todos los demás tipos de metadatos para proporcionar tanto contexto e información como sea posible.

«Otros» documentos: Especificaciones, wiki, documentación de ayuda, notas de reuniones, pizarras, resultados de lluvias de ideas, wireframes… Todos ellos pueden conectarse a cualquiera de los tipos de documentación anteriores para añadir más color y contexto.

Pensamientos finales

La IA está transformando el poder de Salesforce CRM pero también cómo podemos cambiarlo. La IA se basa en una gran documentación. Los equipos han estado buscando un enfoque sencillo, fácil de implementar y repetible para la limpieza, documentación y análisis. Tiene que funcionar sin importar el tamaño o la complejidad de la estructura orgánica, y debe ser más amplio que Salesforce.

Ahora existen varias aplicaciones de pago que proporcionan este nivel de capacidad, y el espacio de mercado se denomina Plataforma de Inteligencia de Cambios.

La empresa de análisis independiente InVisory acaba de elaborar un informe de investigación en el que analiza los distintos proveedores de plataformas de inteligencia de cambio, tanto las aplicaciones gratuitas como las de pago. Puede descargar una copia gratuita aquí:

Como el espacio de mercado aún se está formando y los proveedores se encuentran en diferentes niveles de madurez, el alcance y las capacidades son diferentes. Nombrado líder del mercado, Elements.cloud ofrece una verdadera solución multi-cloud que proporciona soporte para toda la documentación a lo largo del ciclo de vida completo de implementación: comentarios, requisitos, mapas de procesos, arquitectura, diccionario de metadatos, análisis de dependencia e impacto, integración DevOps y ayuda in-app. Con un modelo de precios sin complicaciones para los consultores, ¡también son capaces de justificar su uso!