¿Cómo puedo comunicar los riesgos de alterar el software del proveedor?

Tenemos un problema importante donde trabajo, y su nombre es "personalización". Tenemos un antiguo sistema de software de proveedores (más de 10 años) que a nuestros departamentos de TI y contabilidad les encantaba personalizar. En algún lugar a lo largo de la línea, este software comenzó a tener muchos errores. Luego, me contrataron después de la mayor parte de la personalización.

Casi todos los problemas que he encontrado con el sistema son un resultado directo de la personalización; todo lo que cambiamos corre el riesgo de romper el software financiero crítico del negocio. Sin embargo, el departamento de contabilidad sigue sugiriendo cambios (¡porque siempre dijimos que sí!) Y parece haber poco respeto por la repercusión de los cambios.

Algunos cambios no causan problemas; los formularios pueden ser (y están destinados a ser) personalizados en el software del proveedor, podemos movernos por los campos de formularios, eliminarlos, etc. Pero para cada personalización inofensiva como esa, también sugieren cambios como procedimientos almacenados y disparadores para manipular datos en la base de datos para la aplicación del proveedor.

Recientemente (apenas) conseguí que dejaran de intentar importar clientes de un programa de proveedor a otro, ya que la información era completamente incompatible. Mi problema con cómo se resolvió eso es porque descubrí que el sistema no funcionaba en el lado del usuario; la tarea fue más complicada de lo que pensaban, así que se dieron por vencidos. Independientemente de lo fácil que sea la tarea del lado del usuario, la operación que querían no debería haberse realizado.

¿Cómo puedo comunicar que cambiar el funcionamiento de este sistema tiene riesgos, particularmente cuando la validez de los datos está en juego? Soy un nuevo empleado (6 meses) y se ha convertido en el statu quo, pero está arriesgando la validez de nuestros datos financieros y nuestros contratos de soporte, una vez que el soporte del proveedor escucha "X ha sido personalizado", eso les da esa razón no para apoyarnos o decirnos que es nuestra culpa.

El riesgo / recompensa de los sistemas de personalización es proporcionar una ventaja competitiva que le permita a su empresa ofrecer algo diferente a las otras empresas en su espacio.

Las organizaciones más grandes con las que he trabajado obtienen una ventaja competitiva de la personalización y, en esa mentalidad, les hacen hacer las cosas de manera más eficiente, proporcionan más funciones o ganan más dinero.

El hecho de que me comunique en estas situaciones es que es una compensación. Al realizar estos cambios en un sistema, la organización está desarrollando su propia base de conocimiento interno / experiencia de sus sistemas que no podrán hacer fácilmente sin ellos. Esta base de conocimiento interna debe mantenerse y organizarse mejor para que estos cambios puedan ser rastreados y gestionados. También significa que podría invalidar los contratos de soporte del proveedor y otros aspectos que los activos de TI que la empresa utiliza para este proceso.

El mayor riesgo del que hablo es la actualización de versiones del software del proveedor cuando una empresa adopta esta filosofía de gestión de datos. Este es uno de los riesgos más probables en los que algo se va a romper. La compañía necesita comprender las compensaciones que se están haciendo y todos deben estar de acuerdo con el proceso que se necesita para apoyarlos.

Para su cultura, puede introducir una analogía o filosofía, pero necesita que alguien que sea responsable del negocio se dé cuenta de que está creando un entorno que tiene aún más dependencias de un especialista comercial interno que realice cambios en estos sistemas.

Para la analogía del automóvil, no es el mecánico el que necesita saber qué cambios se están haciendo en un automóvil, es el propietario quien debe comprender que puede requerir una mecánica especial, más dinero o la pérdida de ese servicio por un período de tiempo. Educar al dueño es la clave de esta conversación.

¿Comunicándose con los habitantes de la oficina? Yo iría con analogías.

Dígales que todos estos cambios están convirtiendo su sedán doméstico típico de 4 puertas en un exótico automóvil extranjero. Cada vez que lo lleve al taller mecánico, desde la puesta a punto, hasta la luz aplastada, hasta la revisión de la transmisión, será más costoso. "No tenemos las piezas, solo el distribuidor con conocimientos especiales puede tocar eso, lo intentamos pero el manual está en alemán".

Usted es el mecánico encargado de mantenerlo en funcionamiento. La base de datos es el motor. Todo el sistema es el auto. Los contadores conducen el auto. El conejito lindo que los contadores desviaron para extrañar es un personaje de diéresis en el apellido de un nuevo cliente. El poste de luz alrededor del cual envolvieron su automóvil es el error crítico que se introdujo cuando querían agregar una bola de discoteca dentro del automóvil.

Otros han proporcionado algunos buenos ejemplos del uso de analogías y otro lenguaje para responder a su pregunta principal, que fue "¿Cómo puedo comunicar que cambiar el funcionamiento de este sistema tiene riesgos, particularmente cuando la validez de los datos está en juego?"

Pero según su comentario clarificador sobre cómo le llega la tarea asignada, no estoy seguro de que alguna analogía lo ayude en la situación; en realidad, no parece que las personas entiendan mal lo que están pidiendo, pero más bien que no les importa. He estado allí, probablemente todos hemos estado allí, y en estas situaciones tiendo a hacer un mayor esfuerzo para ser perfectamente claro en cuanto a los problemas, en lugar de expresarlos en términos destinados a enseñar en lugar de advertir .

Concéntrese en lo que puede hacer, que no está cambiando la mente de todos los que solicitan personalizaciones que ponen en riesgo la integridad de los datos y los contratos de soporte del proveedor, sino que está hablando directamente con su CTO (y, a su vez, el CFO) y muy claro en cuanto a los problemas en cuestión.

Específicamente:

• Pídale a su CTO o CFO (o quien sea que lo tenga) que vea el contrato de servicio con el proveedor, porque (y yo diría estas palabras) se le está pidiendo que realice tareas que potencialmente violen el acuerdo y desea ser capaz de señalar eso en su informe de factibilidad de tareas. Es posible que no te lo den, pero decir esas palabras a menudo ha hecho que las personas en esas posiciones comprendan mejor que eres serio y que la situación es potencialmente grave.

• Si haces obtener una copia del acuerdo, entonces cuando usted escribe su informe de viabilidad tarea, cita directamente de ella cuando hay una violación clara.

• Si no obtiene una copia del acuerdo, haga sus reservas muy claras en cuanto a cómo el cambio podría poner a la empresa en una mala posición con respecto a la relación con el proveedor.

• Si su preocupación no es problemática debido al acuerdo con el proveedor, pero es "simplemente" problemática debido a los efectos en cascada del cambio, describa lo que eso significa: si es tan complicado como usted dice, entonces probablemente solo tenga uno o dos puntos antes de poder usar la línea "y se derrumbará como un castillo de naipes".

En resumen, haga lo que pueda para señalar de manera clara y concisa el problema y sus efectos, incluso uno o dos pasos más adelante. Es bueno que tenga la oportunidad de presentar un informe de factibilidad ante los tomadores de decisiones; no tiene la estructura o el soporte de gestión (o ethos) para decir "Necesito que firme esto diciendo que entiende que esto es algo malo y que no lo recomiendo y no voy a ser responsable de los efectos de esto mala decisión "(como lo haría si fuera un vendedor y ellos fueran un cliente), pero aún puede poner muchas cosas en papel que demuestren que está considerando lo que es mejor para la empresa y sus activos.

Si le dicen que implemente procedimientos almacenados y disparadores, tiene un problema importante en el proceso comercial.

Su mayor desafío es lograr que los usuarios cambien su forma de pensar. Necesitan proporcionarle el problema o requisito. Por ejemplo, necesitamos datos que se muevan de aquí a aquí .

Debe ser usted quien implemente la solución con el menor riesgo / mayor ganancia, y es usted quien puede hacer esto de una manera que ayude a prevenir futuros problemas de desarrollo.

También será útil cierto control en forma de cierre de sesión o requisitos del usuario, y luego cierre del desarrollo entregado. Si el usuario tiene que asumir alguna responsabilidad / responsabilidad por lo que está pidiendo, puede pensarlo un poco más.

Parece estar insinuando que su elección es entre una implementación arriesgada de un requisito comercial o ninguna. Raramente es así de blanco y negro. Me cuesta creer que los contadores soliciten directamente procedimientos almacenados, pero si lo hacen, debe darles lo que quieren decir en lugar de lo que están pidiendo. Averigüe cuál es el requisito comercial, luego descubra la forma menos riesgosa de implementarlo.

Si su proveedor no proporciona los ganchos que necesita para implementar de manera segura los requisitos que desean sus usuarios, entonces ese problema es con el proveedor, no con sus usuarios.

Básicamente está desarrollando software y, como tal, necesita una metodología de desarrollo. ¿Cómo se documentan los cambios? Probado? Desplegado a QA? Desplegado a la producción? etc. Creo que si comienzas a elaborar una metodología y los costos asociados con ella comenzarán a comprender. Quizás los costos estén bien justificados y solo necesite implementar un procedimiento para que el automóvil nunca se enrolle alrededor de un poste de luz.