Consultor de proyectos

Gestión de proyectos / apoyo a proyectos

Con la mano en el corazón: ¿realmente tiene tiempo para prestar a la implantación de un nuevo ERP la atención que merece? ¿Además del día a día?

¿Puede juzgar si los procesos de trabajo se han trazado según lo acordado?

¿Es capaz de documentar sus propios flujos de trabajo de forma tan fiable que su empresa de sistemas Navision/Business Central pueda implementarlos según sus deseos y requisitos?

Si ha dudado o negado aunque solo sea una vez, un consultor de proyectos con experiencia le resultará muy rentable, aunque cueste dinero. Los errores y escollos son más baratos de eliminar cuanto antes se descubran en el proyecto.

Cuanto antes me subas a bordo, antes evitarás un accidente. Y tu gran ventajaPuesto que usted me paga, yo también trabajo y analizo en su interés, y no en el interés de la casa del sistema.

Un consultor independiente (autónomo) de Navision o Business Central puede evitarle lo peor .

¿Por qué fracasan los proyectos?

La razón es sencilla: los proyectos o, más en general, las compras fracasan muy a menudo siguiendo el mismo patrón. Por eso no he utilizado la palabra ERP o Navision/Dynamics/Business Central en este epígrafe.

Puede encontrar más razones para el fracaso, así como instrucciones para proyectos exitosos aquí.

El patrón es siempre el mismo

Usted, el cliente, está planeando una compra. Un sistema de gestión de mercancías, una nueva nave, un nuevo cableado de red o una nueva vivienda particular. La lista podría continuar durante mucho tiempo.

Sin embargo, esta lista no incluirá, por ejemplo, una máquina especial o unas vacaciones muy particulares. Entenderá por qué es así después de los párrafos siguientes.

Dos cosas elementales se unen para causar el fracaso

a) Un producto comparable en sus características y ofrecido por distintos proveedores independientes.

b) Un cliente que quiere pagar lo menos posible por ese producto.

¿Qué ocurre?

Ahora entro directamente en el mercado de los ERP, independientemente de si el producto se llama Navision/Dynamics/Business Central o si se llama SAP, Concord XAL, Sage KHK, Axapta o lo que sea. Eso no supone ninguna diferencia para este modelo.

El cliente intenta protegerse fijando un listón de definición alto, a menudo debido a malas experiencias anteriores. Los casos especiales y las excepciones más abstrusas se incluyen en las especificaciones (a menudo etiquetadas incorrectamente por el cliente como "especificación de requisitos"). Ningún caso especial es lo suficientemente raro como para que el empleado que toma las notas no reciba una palmadita en la espalda. Siempre se puede complicar más, nadie quiere simplificar. Porque muy poca gente sabe hacerlo.

Proveedores competidores en un dilema

Varios proveedores de la competencia se ponen en contacto con estas especificaciones. Los proveedores se encuentran ahora en un dilema:
Si los proveedores abordan el tema con seriedad, necesitan mucho tiempo para procesar las especificaciones.

Un proveedor tendría que separar el grano de la paja, lo importante de lo intrascendente. Las reclamaciones sin sentido tendrían que explicarse detalladamente como tales, y habría que elaborar propuestas de cambio sensato de un proceso estándar.

Sin embargo, el licitador no cobra por este tiempo. En este momento, aún tiene que tener en cuenta que NO se le adjudicará el contrato.
El proveedor debe calcular los costes de forma razonable. Al mismo tiempo, solo dispone de un pequeño margen sobre la propia licencia ERP.

Los buenos programadores son caros, así que, para ser competitivo, tiene que calcular y trabajar con programadores menos buenos (=más baratos). Sin embargo, esto puede significar que muchos requisitos no puedan realizarse a la satisfacción (al menos prevista) del cliente. En este artículo de Heise , este dilema se ilustra con bastante claridad desde la perspectiva de las empresas de contratación.

Para que su oferta sea menos comparable, recurre a soluciones adicionales ya preparadas. Éstas proporcionan al minorista el margen necesario para sobrevivir, pero hacen que partes de la gama sean menos comprensibles y menos comparables.

¿Por qué a los buenos programadores sólo se les paga por horas, nunca por líneas?

Como pequeña digresión, un homenaje, por así decirlo, a "los viejos tiempos": ¿Por qué no se encuentran buenos programadores a los que se pueda pagar por línea de código, algo que todavía era habitual hace unas décadas? Un buen programador es como un buen pintor o un buen fotógrafo. Rara vez está satisfecho con el primer resultado. Se introducen mejoras, se cuentan los accesos a la base de datos, se escrutan las claves, se reconocen las líneas de código innecesarias. Lo mismo ocurre con la fotografía: Se hacen cientos de fotos, sólo para acabar con unas pocas que realmente merezcan la pena. El código de un buen programa "madura". Yo mismo lo observo a menudo: se crean decenas o centenares de líneas de código de programa, que ayudan a transformar los pensamientos en código de programa. Luego este código se examina, se acorta, se "refina". Es precisamente en esta encrucijada donde se separa el grano de la paja. Para muchos programadores, "funciona" es suficiente. El resultado es un código de programa imposible de mantener, que con el tiempo devora el mantenimiento y, por tanto, el dinero. El buen (y también bonito) código de programación , como el buen vino, requiere tiempo. Tiempo que también hay que pagar. Cuando reviso algunos programas, me encuentro fácilmente con proporciones de 10:1 a bastante más de 25:1: Los programas que constan de 10 líneas de programa al final, por ejemplo, han tenido antes cien o 250 o más líneas de programa. Quizá no todas a la vez, pero sí todas en total. Como buen programador, hay dos formas de enfrentarse a esto: A) Avergonzarte del hecho de que te llevas mucho dinero por 10 líneas netas de código. Eso no es sano. O, a mi manera: B) Sentirte orgulloso de haber sido capaz de resolver un problema complejo en 10 bonitas líneas.

"Resolvemos su problema por X euros"

Ahora el cliente recibe varias ofertas de distintos concesionarios, todos ellos en el dilema anterior. En todas las ofertas encontrará esencialmente: "Resolvemos su problema por X euros".

Algunos de estos distribuidores (cuanto más egoísta sea el cliente, más proveedores: Porque así el cliente puede seguir obteniendo muchos conocimientos gratuitos) están invitados a una presentación.

En esta presentación se muestran, en el menor tiempo posible, algunos aspectos destacados de la solución informática: Venta de inmuebles, venta de paquetes de acciones o seguros, venta de camiones. Todas siguen un patrón similar.

Al final, el cliente se da cuenta de que la mayoría de los proveedores prestarán de algún modo el servicio deseado. Suele ganar el segundo proveedor más barato. De alguna manera" no se fía del proveedor más barato, pero tampoco quiere gastar mucho más. "De alguna manera" todas las presentaciones fueron "de alguna manera" convincentes.

¿Cuál es la consecuencia?

El proveedor pone a sus desarrolladores -a menudo muy nuevos- bajo presión de tiempo e incluye algunos módulos adicionales en el paquete. El resultado para el cliente:

-Un producto informático más difícil de instalar y mantener

-Mayor dependencia del proveedor (debido a que los módulos adicionales no son intercambiables libremente, independientemente de que sean necesarios o no).

-Un producto ERP/software instalado bajo presión de tiempo

-Durante el lanzamiento, surgen discusiones sobre lo que debe incluir el producto (Desde el punto de vista del cliente: ¡Mucho! De lo contrario, costes adicionales. Desde el punto de vista del proveedor: ¡Lo menos posible! Mejor costes adicionales). Esto lleva a más discusiones y menos producción.

-y un promotor de BC atrapado entre dos frentes, tratando de conseguir un trabajo con un cliente final lo antes posible, a cambio de mejor dinero y mejores condiciones laborales.

-La tasa de fluctuación vuelve a garantizar que se envíe a los nuevos desarrolladores a cursos cortos de formación por poco dinero para avanzar en los próximos proyectos... o llevarlos al paredón.

El problema: el cliente no puede examinar el producto en detalle en el momento de tomar la decisión de compra.Y así intenta conseguir el mayor servicio posible por el menor dinero posible .

Mejora continua de la calidad

Es precisamente este detalle (la ignorancia) lo que garantiza una reducción continua de la calidad en los mercados no regulados, provocada por la mentalidad más o menos consciente del cliente de "la codicia mola" .

Esto fue analizado con más precisión por George A. Akerlof ya en 1970 en un trabajo que sólo fue premiado mucho más tarde y reconocido como fundamental. También puede leerse con más claridad en este enlace publicitario aquí:

Un proveedor especial

Ahora también sabe por qué, por ejemplo, las vacaciones muy individualizadas o la compra de máquinas especiales No suelen fracasar: El mercado de proveedores es demasiado pequeño. A menudo hay que comprar a un proveedor especializado y sólo él puede resolver el problema.

Le dará un precio justo y usted (tendrá que) aceptar ese precio como un hecho. Al final, ha pagado una cantidad de dinero por un servicio y ha recibido el servicio deseado. En este punto, la cantidad de dinero ya no es tan importante.

Proveedores competidores

Esta es la diferencia con los mercados con proveedores competidores y la necesidad de una normativa. Los vehículos de motor, por ejemplo, deben demostrar unas prestaciones de frenado (deceleración) verificables. Esto lo comprueba la ITV. Por tanto, puede confiar en que los coches vendidos en Alemania frenan bastante bien.

No hay normas para los neumáticos de los coches, sólo algunas reglas. Por eso hay a la venta neumáticos de coche que "agarran" increíblemente bien en una carretera mojada y detienen un coche (con sus frenos probados) en muy poco tiempo. Y hay neumáticos de coche muy baratos. A menudo, pero no siempre, proceden del Lejano Oriente. Es más probable que te hagan derrapar que detenerte bajo la lluvia.

Con tu ERP no es diferente. Siempre hay alguien que puede ofrecer un servicio un poco peor y un poco más barato. Y como la calidad no siempre es visible de inmediato, como cliente a menudo te decides por el precio que siempre es visible.

Comprar Navision o Business Central

Si no quieres entrar en este círculo vicioso de la culpa en primer lugar: Usted puede comprar BC (SÓLO Business Central, Navision y Dynamics ya no están disponibles. No vendo SAP y KHK y todo lo demás) a través de mí y mi socio. Sin embargo, esto entonces funciona de manera diferente a los patrones habituales explicados anteriormente..
Mis "Best Practice„:

1. Usted me proporciona sus 15 documentos más importantes.
   Algunos de ellos ya están reservados:
   I. Factura de venta
   II. albarán de venta
   III. confirmación del pedido de venta
   IV. Oferta de venta
   V. Orden de compra
   VI Liquidación sustitutoria
   VII Valoración de las acciones
   VIII. BWA
   
   Si no lleva a cabo ninguna valoración de existencias especial, por ejemplo, simplemente valor de existencias = existencias reales en la fecha clave x último precio de coste, o si no crea ninguna oferta de venta, estos puntos se omitirán por supuesto de la lista.
   
   Recopile usted mismo los análisis/informes más importantes de su empresa. También del PDE en la sombra, por ejemplo, de las listas de Excel que se crean semanalmente con mucho sudor. "15" no es un número fijo. Decide por ti mismo en este paso lo que es importante para ti. Si le falta una evaluación desde hace mucho tiempo, ¡descríbala brevemente!
   
2. Usted me proporciona esta lista con ejemplos comprensibles. Simplemente anota cualquier particularidad adicional en los ejemplos.
   
3. Yo analizo estos informes. Esto nos da una base para el diálogo.
   A partir de aquí tenemos una base -muy aproximada- para la estimación de costes..
   
4. Usted cuenta sus empleados que van a trabajar con Business Central. De ello se derivan los costes de licencia de la solución.
   

A partir de estos valores, calcularé una cantidad "pi x pulgar" para usted, sin ninguna pretensión de finalidad. El tiempo necesario para este procedimiento es opcional y correrá de su cuenta. Independientemente de su decisión posterior.

Realización del proyecto:

Voy a verle y empezamos a trabajar juntos. Le especifico qué datos maestros y de transacciones necesito de usted y qué departamentos debo visitar.

Cada paso se lleva a cabo en diálogo, es decir, usted puede recibir de mí en cualquier momento una estimación (!) del esfuerzo posterior y también decidir en cualquier momento si este proceso le merece la pena por esta cantidad estimada.

De este modo, los requisitos se clasifican rápidamente entre "esencial", "agradable de tener" y "a qué idiota se le ocurrió eso". Sí, este último punto también es sorprendentemente frecuente. Si, por ejemplo, se han establecido en la empresa algunos procesos de trabajo que hace tiempo que perdieron su razón de ser. O que nunca la han tenido. Pero que, hasta que yo llegué, nunca se cuestionaron.

Mis proyectos crecen con el paradigma: prefiero pasar 10 horas discutiendo que una programando. Suena fatal. Pero te lo prometo: te encantará el resultado.

Tantos cambios como sean necesarios, tan pocos como sea posible. Esto garantiza bajos costes de seguimiento, tiempos de familiarización más cortos, sistemas ERP completos de una sola fuente y flujos de trabajo rápidos en lugar de interminables orgías de clics.

Cada paso, cada esfuerzo es facturable. Esto le permite apreciar automáticamente el trabajo realizado. Y conozco tan bien su empresa sin presiones financieras que puedo darle recomendaciones bien fundadas para optimizar los procesos. Sin que yo venga con la manta de "despide al 10% de tus empleados". Dejemos eso para algunos consultores de gestión, recién salidos de la universidad como economistas de empresa.

Mi experiencia de casi 30 años de implantaciones informáticas: Una empresa que necesitaun consultor de gestión ya tiene un pie en la insolvencia.

Requisitos y especificaciones

También ayudan. Si ya tiene algo así, es un buen documento de trabajo. También podemos organizar algunos talleres juntos en su empresa y crear un documento de trabajo conjunto que establezca condiciones marco importantes.

Usted decide si lo llamamos especificación funcional o especificación de requisitos. Sigue siendo un documento de planificación orientativo y puede corregirse en el transcurso del proyecto en función de la creciente experiencia de ambas partes.
Por supuesto, este esfuerzo también es opcional.

¿Estoy hablando en serio?

Sí.
No tiene por qué comprar Navision y Business Central así. Y tampoco tiene que comprármelo a mí. También estoy encantado de acudir a usted cuando el niño hace tiempo que se ha caído al pozo. Tanto como salvador como mediador.