¿Cómo controlar el presupuesto de los proyectos de tecnologías de la información? En segundo lugar, no calcules todo el presupuesto. Después de hacer un presupuesto, siempre hago un descuento cuando les cuento a otros mi presupuesto. Por ejemplo, cuando nuestra empresa implementó un proyecto de ERP, el consultor de implementación de la otra parte me preguntó: ¿cuál es nuestro presupuesto para este proyecto? Según mi presupuesto anterior, planeé que la tarifa de licencia de software fuera de 600.000 yuanes, así que le dije que, según los acuerdos anteriores de nuestra empresa, el presupuesto de la tarifa de licencia de software era de 500.000 yuanes. ¿Por qué? Porque si revelas tu verdadera identidad desde el principio, la otra parte hará una oferta en el acto. Originalmente sólo había una tasa de licencia de 600.000, así que dijimos 700.000. Regateemos un poco más. Es decir, muchas empresas de software cotizan precios en función de nuestro presupuesto. Si nuestro presupuesto es alto, su cotización también lo será. Si nuestro presupuesto fuera bajo, su cotización inicial sería menor. Por lo tanto, cuando controlamos el presupuesto, no debemos mostrar nuestros antecedentes a los demás de inmediato, sino hacer un descuento primero, para que podamos tener margen de maniobra en el trabajo que se necesitará más adelante. Al mismo tiempo, no esté completamente preparado para los presupuestos de costos internos. Por ejemplo, al presupuestar partidas muy inciertas, como los costos de desarrollo secundario, se debe dejar cierto margen de maniobra. Por ejemplo, a través de encuestas de demanda preliminares o según las recomendaciones de la empresa de software, el costo del desarrollo secundario es generalmente 65,438+00% del costo del software, que es 60,000. Sin embargo, dado que el costo del desarrollo secundario es difícil de estimar con precisión, es necesario distinguir entre niveles al considerar estos costos inciertos. Por ejemplo, cuando estaba considerando el presupuesto de costos para este desarrollo secundario, se dividió en tres niveles, a saber, 30.000, 20.000 y 10.000. Si el costo de desarrollo secundario es inferior a 30.000, básicamente se puede satisfacer. Si lo solicitan, deje que la empresa de software sea responsable del desarrollo; si el total supera los 30.000 y llega a la línea de advertencia amarilla, se revisarán nuevamente las necesidades de desarrollo secundario del usuario para ver si se necesita desarrollo secundario, si supera los 50.000; mi línea roja de advertencia. En este momento, si no existe la aprobación del jefe o el consultor no recomienda encarecidamente el desarrollo del caso, sus necesidades generalmente no serán aceptadas. Este control tiene dos ventajas. Primero, para satisfacer sus propias necesidades, los usuarios empresariales tomarán la iniciativa de considerar los problemas y comprender el sistema, porque solo así podrán presentar sus requisitos lo más rápido posible y la posibilidad de ser adoptados para el desarrollo secundario será menor. mucho mayor. Esto también puede promover virtualmente el progreso del proyecto ERP. En segundo lugar, cuando todos exponen sus necesidades de manera proactiva, puedo captar tantas necesidades de desarrollo secundarias como sea posible desde el principio, lo que me ayudará a organizarlas de manera unificada. Al mismo tiempo, hay más demanda de desarrollo único y hay espacio para la negociación entre ellos, por lo que los grandes descuentos serán mucho mayores. Por supuesto que nos encantaría hacer un trabajo tan versátil. 3. Se debe fortalecer el control sobre los cambios en los requisitos del proyecto. De hecho, hasta donde yo sé, una gran parte de la razón por la que se excede el presupuesto en los proyectos de tecnología de la información empresarial son los cambios en los requisitos del proyecto. Según estadísticas relevantes, el costo de cambiar los requisitos del proyecto representa aproximadamente el 20% del gasto total del proyecto, lo que demuestra que se trata de un gasto considerable. Si podemos reducir la pérdida de cambios en los requisitos del proyecto, sin duda reduciremos el problema del apoyo excesivo al proyecto. Por lo tanto, la clave para el control del presupuesto del proyecto radica en el control de los cambios en los requisitos del proyecto. Sin embargo, la mayoría de las veces es imposible eliminar los cambios en los requisitos del proyecto. Debido a diversas razones, como investigación preliminar insuficiente, cambios inesperados encontrados por la empresa durante la implementación del proyecto, nuevos requisitos de los usuarios durante el proceso del proyecto y mejora continua del sistema después de la finalización del proyecto, pueden surgir cambios en los requisitos del proyecto. Para reducir la pérdida de cambios en la demanda, generalmente tomo las siguientes medidas durante la implementación del proyecto: 1. Transfiera la pérdida de cambios de demanda al desarrollador tanto como sea posible. El idioma chino es bueno y una oración clara puede brindar a las personas diferentes interpretaciones. En caso de que los requisitos cambien, intente devolver la responsabilidad a los desarrolladores, diciendo que se trata de una laguna en el desarrollo de su programa y un problema en su software. Las necesidades que planteamos son algunas necesidades básicas, no nuestras necesidades personales, sino problemas que todo el mundo encuentra a menudo. Si nos ponemos duros, los desarrolladores cederán. Pero debemos prestar atención a la escala y no dejar que los desarrolladores piensen que no somos razonables. 2. Tratar a los clientes como mis clientes, no como relaciones con mis empleados. En el proceso de implementación de proyectos de tecnología de la información, generalmente hay tres partes. Uno es el usuario del terminal, el otro es el responsable de nuestro proyecto y el tercero es el implementador o proveedor de software. De hecho, existen muchos problemas entre el Partido A y el Partido B. Porque en ocasiones los clientes finales no consideran claramente sus necesidades, lo que provocará cambios en sus necesidades más adelante. Esto se debe principalmente a la falta de presión por parte de los usuarios finales para que asumamos que somos responsables de sus propias necesidades.
Es porque tienen esta idea que a veces cuando piden algo, lo piden tan pronto como están calientes sin una cuidadosa consideración. Entonces, cuando los usuarios hacen solicitudes, generalmente les pido que las escriban por escrito y firmen con su nombre. Porque antes de escribir, definitivamente pensarán en sus necesidades antes de escribir. Es muy probable que durante este proceso de pensamiento, los usuarios cambien sus intenciones originales. Al mismo tiempo, los requisitos modificados requieren una aprobación especial. Porque según la ley, la primera impresión del usuario suele ser más precisa. Por lo tanto, cuando los usuarios proponen cambios en los requisitos, tenemos que echarles agua fría y hacerlos sobrios. El control del presupuesto del proyecto es una habilidad que refleja las capacidades del CIO. Mucha gente dice que la ingeniería de la información es un juego para quemar dinero, lo cual es absolutamente cierto, pero también tiene sus razones. Si el presupuesto de un proyecto se sale de control, incluso si el proyecto finalmente tiene éxito, usted, como persona a cargo del proyecto empresarial, tendrá en el mejor de los casos una bendición mixta; si el proyecto fracasa, tendrá más culpa. Por lo tanto, para ser un buen CIO y un buen líder de proyectos de información, debe comenzar con el control del presupuesto del proyecto y hacer todo lo posible para garantizar que no se exceda el presupuesto del proyecto. De lo contrario, estará aún más triste. Sería una pena esperar hasta que se supere el presupuesto antes de pedirle al jefe superior la financiación del proyecto.