Este artículo se reproduce desde: https://blog.csdn.net/Jasper2008/article/details/4698339
La explicación de CRP está tomada de la página G-10 del manual del usuario de Oracle AIM 3.0 A75149-01 : Conference Room Pilot (CRP) : una prueba del sistema en un entorno configurado para simular el futuro entorno de producción Usuarios de ORACLE AIM 3.0 Página 3 -89 del folleto A75150-01 describe CRP con más detalle: # d' q) i7 V, Z5 T n* J" x, I Puede realizar pruebas de alternativas comerciales en una sala de conferencias formal piloto (CRP)
o utilizar un enfoque más informal como continuación de las actividades de mapeo. En cualquier caso, debe probar las brechas de funcionalidad identificadas porque es probable que no se haya diseñado o construido ninguna alternativa final para cerrar esas brechas. & a9 R F1 m" D. f4 y
Un CRP es una técnica para evaluar una alternativa propuesta que simula procesos comerciales reales en un entorno controlado. A menudo se realiza en una sala de conferencias real para que todos los participantes estén juntos y se eviten los retrasos. ser minimizado. Un CRP puede revelar problemas perdidos y problemas de procesos probados de forma aislada. 4 k' q& m. G5 v9 ^
Un piloto de sala de conferencias generalmente se ejecuta por área de negocios o algún otro grupo más amplio de procesos de negocios. Esto significa que varios equipos de mapeo deben estar listos al mismo tiempo para comenzar. Como ocurre con la mayoría de las estrategias de prueba, un CRP consta de iteraciones que convergen en una alternativa práctica y factible. Una vez que todas las pruebas estén completas y confirmadas, puede documentar las configuraciones finales y las alternativas seleccionadas.
Este texto explica qué es la PCR , cómo se realiza y sus resultados.
¿ Qué es CRP (Conference Room Pilot)?
CRP se utiliza para ayudar al equipo del proyecto a establecer un modelo de proceso empresarial. La diferencia ( brecha )entre el software y la realidad también se encontraráa través de CRP , y la configuración del software se ajustará aún más. El enfoque de CRP es comprender el software, así como los requisitos organizacionales e institucionales. Durante el proceso de CRP, el equipo del proyecto demostrará las funciones y procesos de acuerdo a los datos que puedan aparecer en el negocio. CRP se enfoca en mostrar, paso a paso: cómo el nuevo sistema implementa el proceso comercial actual. Incluya todas las interfaces, informes y programas relacionados con el caso y obtenga las sugerencias del usuario para el sistema. Este proceso reflejará y documentará las siguientes preguntas :
- Diferencias entre software y requisitos
- impacto en la organización
- Impacto en los sistemas y procesos de negocio
- temas de seguridad
- Mecanismo de aprobación y seguimiento
- Modificación de medidas tras la finalización del CRP , el proyecto aún se encuentra en fase de diseño.
El CRP se asegurará de que la organización esté preparada para los cambios que vendrán con el nuevo sistema. Además, el CRP reflejará algunas necesidades de apoyo y capacitación en el futuro.
CRP puede resolver creativamente algunos problemas para satisfacer las necesidades de todas las partes. Por ejemplo, la diferencia funcional del software, es decir, la diferencia entre cómo los participantes del CRP imaginaron que funcionaría el proceso comercial y las capacidades del software. Para resolver este problema, cambie el proceso o modifique el software. Por lo tanto, un entorno de comunicación abierto es muy importante y requiere la intervención de gerentes, personal funcional, personal técnico, equipos de desarrollo y representantes de los usuarios. Al mismo tiempo, todos los participantes deben poder aceptar abiertamente los cambios en los métodos y procesos comerciales para realizar el principio general del proyecto : no hay desarrollo funcional de software.
Antes de CRP , el equipo del proyecto debe recibir capacitación en el sistema para comprender la interfaz y la ruta del sistema, a fin de enfocarse en cómo el personal comercial final usa el sistema. Además, se requiere que todos los participantes estén capacitados en el proceso y los conceptos de CRP . CRP no es capacitación de usuarios, pruebas de sistemas ni una demostración precisa del sistema final. El CRP es una parte de la fase de diseño del sistema en la que el equipo del proyecto recibe comentarios de los usuarios.
Cuando se completa el CRP , el equipo del proyecto puede formar: un diagrama de flujo comercial completo, un resumen de todas las diferencias de software y cómo resolver las diferencias, requisitos e informes de procesos comerciales a través de métodos específicos. La gestión y ejecución cuidadosa de CRP es la clave para el éxito del proyecto, porque la retroalimentación de CRP refleja una comprensión detallada de las necesidades comerciales y guiará la implementación del sistema.
La PCR no es ...
- Sesión de formación de usuarios. Los usuarios no tienen que seguir paso a paso en sus propias computadoras.
- Proceso de transferencia de datos a gran escala, importando una gran cantidad de datos comerciales formales al entorno CRP .
- Reunión de contacto de desarrollo de aplicaciones (JAD) o proceso de creación de prototipos. No discuta ni configure los valores del sistema, códigos en las reuniones.
- El equipo del proyecto no estaba preparado para la reunión. Se deben preparar posibles procesos y configuraciones iniciales antes de CRP .
- Prueba del sistema o demostración detallada de la función. Los participantes deben ser conscientes de que el proyecto aún se encuentra en la etapa de diseño y lo que quieren es recibir comentarios sobre cuestiones clave.
La PCR es ...
- Trabajo pre-guionizado y bien preparado. .
- El equipo del proyecto utiliza sistemas preconfigurados y múltiples escenarios comerciales reales para demostrar las funciones y los procesos del software.
- Demostrar con datos de muestra a pequeña escala. Por lo general, estos datos solo deben ingresarse manualmente.
- Haga preguntas a los usuarios y reciba comentarios sobre qué esperar.
- Averigüe las diferencias funcionales y los problemas clave en el sistema comercial que deben resolverse después de que se complete el CRP y prepare los documentos.
En el manual de usuario de AIM , este texto aparece en el capítulo Business Requirement Mapping .En otras palabras, ORACLE considera a CRP como una tecnología en una etapa determinada de la metodología AIM , en lugar de una metodología independiente.
Entonces, ¿por qué la industria ha estado hablando de la metodología de implementación de CRP ?
Dejando de lado la controversia, dado que la industria reconoce la metodología de implementación de CRP, y muchos de nuestros proyectos en el pasado y muchos proyectos en el futuro usarán la metodología de implementación de CRP , entonces también podríamos dejar de lado la controversia de " si CRP es un metodología de implementación independiente " e ignorar AIM por el momento. (Solo citamos su explicación del término de tres letras CRP ), primero reconozca que es una metodología de implementación independiente e intente ordenar su sistema de conocimiento.
Entré personalmente en contacto con el término CRP en 2001. Lo escuché de los implementadores japoneses de Panasonic en Hangzhou en ese momento. Antes de eso, solo conocía la metodología Quick-HAND . Por cuestiones de idioma, al principio no entendía qué era CRP , así que seguí la idea japonesa. Poco a poco, entendí lentamente el término y este método de implementación. Hay un dicho que dice que CRP es relativo a la metodología de implementación " tradicional " . Esta declaración define los métodos de implementación " tradicionales " como " investigación → diseño de anteproyecto → implementación →
Sin embargo , CRP se define como "CRP1 → CRP2 → CRP3 → UAT → Go-live " . Desde el punto de vista del rendimiento, la diferencia parece ser que CRP ahorra la investigación a largo plazo y la fase de diseño de planos , y no necesita escribir soluciones. Según CRP , no puede excluir por completo la investigación y el diseño, y no puede guardar el diseño del plano (como contenido de desarrollo adicional , es imposible completar sin investigación y diseño de planos). En mi opinión, la diferencia entre ellos es que CRP enfatiza las " plantillas estándar " , es decir, hay un conjunto de " plantillas estándar " antes de la implementación . " adapte la ropa de acuerdo con las necesidades del individuo " y cambie la forma del cuerpo cuando cambie los requisitos. En teoría, cualquier proyecto puede usar cualquier método de implementación, pero el efecto es diferente y no hay una ventaja o desventaja absoluta. Según mi entendimiento, La PCR se puede definir como " un
"CRP significa como la metodología de implementación central " , el "CRP significa " mencionado aquí puede citar los cientos de palabras en el manual de usuario de ORACLE AIM
. En comparación con AIM , la metodología de implementación de CRP debe tener el siguiente sistema de conocimiento:
1) División de implementación de etapas;
2) Propósito de cada etapa, lista de tareas, descripción de métodos de trabajo y resultados;
3) Plantillas para resultados;
4) Estructura organizativa del equipo de implementación.
[División de fases]
¿Qué etapas se incluyen en el proceso de implementación? ¿Qué tareas completar? Basado en mi experiencia personal, se resume en la siguiente tabla.
Entre las etapas definidas en la tabla anterior, se requieren las cuatro etapas CRP1 , CRP2 , UAT y GoLive .
Si después de CRP2 , todavía hay muchas diferencias por resolver y verificar, y no se puede ingresar a la etapa UAT , es posible que sea necesario implementar CRP3 o incluso CRP4 . El surgimiento de esta situación traerá mayores riesgos para la gestión de proyectos, porque generalmente el tiempo para CRP3 y CRP4 no se reservará con anticipación durante la planificación del proyecto , y agregar estas etapas después de CRP2 puede provocar un retraso en el proyecto. Por lo tanto, durante el proceso de implementación, se deben hacer esfuerzos para mejorar la eficiencia y el efecto de CRP1 y CRP2 , y evitar aumentar CRP3 a mitad de camino . En los casos en que CRP1 es particularmente bueno, también se puede omitir CRP2 .
Si no sabe mucho sobre la situación comercial y las necesidades del cliente, y no sabe cuánta diferencia se hará en CRP1 , se recomienda usar CRP1Antes se configuró una etapa Pre-CRP para realizar una investigación sobre el negocio y las necesidades actuales del cliente.Si está permitido, la plantilla que se utilizará para CRP1 se puede ajustar adecuadamente de acuerdo con los resultados de la investigación . Si ocurren muchas diferencias importantes en CRP1 , se reducirá el interés del usuario en la plantilla e incluso se creará resistencia en el debate. [c4 (Para garantizar que cada disposición en la plantilla sea " razonable " , esta " razón " puede ser el pensamiento controlador de la oficina central o el alto nivel del cliente, puede ser la experiencia en la industria, pero no puede ser simplemente " el sistema es así " . ) ]
Cuando una empresa del grupo implementa un sistema unificado, generalmente necesita formular un conjunto de plantillas de acuerdo con las características comerciales del grupo, en lugar de implementar directamente las funciones estándar del sistema o los datos de experiencia de empresas similares. (Para que un grupo grande copie los estándares de otras compañías, o empuje por la fuerza las funciones del sistema, le dolerá la cara). En este momento, habrá una etapa adicional de "Plantilla" . Algunos grupos también eligen una subsidiaria para implementar y hacen plantillas durante la implementación. Este método parece reducir el ciclo general de implementación y evita que la plantilla se desvíe seriamente de la realidad comercial. Sin embargo, causará demasiadas sombras personalizadas de la subsidiaria. lo cual no es bueno para la promoción posterior, por lo tanto, personalmente no me gusta este modelo. Me gusta configurar una etapa de "Plantilla" relativamente independiente para hacer plantillas desde una perspectiva global (en este momento, es necesario evitar " puertas cerradas "Si te pones una grúa como plantilla y vas a la fábrica de coches a hacer CRP , te van a regañar).
【definición de etapa】
Plantilla
La herramienta central para la implementación de CRP es la " plantilla comercial " , a veces denominada " plantilla estándar " , " estándar " , " estándar global " (como les gusta llamarlo a las empresas del grupo). Es un conjunto de normas comerciales imaginadas e ideales, y los implementadores (incluidos los altos directivos del cliente) creen que las empresas pueden lograr excelentes objetivos comerciales haciendo negocios de acuerdo con dichas normas. Por supuesto, este es un " ideal ” . Después de todo, cada empresa tiene sus propias características especiales, algunas de las cuales son incluso la clave para la supervivencia y la rentabilidad de la empresa. CRP es el proceso de encuentro y compromiso entre estándares y personalidades. .
La etapa de plantilla es hacer esta " plantilla estándar " . El método y las precauciones para hacerla se discutirán en detalle más adelante.
Pre-CRP
Si no conoce el negocio actual y las expectativas de la empresa, y no tiene idea del grado de coincidencia de la plantilla estándar, es necesario configurar la etapa Pre-CRP, realizar una investigación sobre la empresa y hacer los ajustes necesarios para la plantilla.
PCR1
Compare la plantilla con el negocio y las expectativas reales de la empresa, busque brechas y determine cómo resolverlas. Concéntrese en las siguientes tres áreas:
1) ¿Cuál es la diferencia entre la especificación de procesamiento comercial descrita en la plantilla y el método de procesamiento actual de la empresa? Por la diferencia, ¿puede la empresa adoptar la especificación de la plantilla?
2) ¿ Qué negocios de la plantilla no existen actualmente en la empresa y no aparecerán en un determinado periodo de tiempo en el futuro?
3) En el negocio real de la empresa, cuáles no están involucrados en la plantilla.
Con respecto a las diferencias (es decir, diferencias), los principios de procesamiento son los siguientes:
1) La empresa acepta las especificaciones en la plantilla.
2) La empresa conserva sus propias características individuales y la plantilla no corresponde.
3) La diferencia tiene cierta similitud en el grupo, y la plantilla se modifica de acuerdo con las necesidades de la empresa.
En esta etapa, también se deben incluir las siguientes tareas:
1) Explicar los conceptos básicos del sistema a los usuarios comerciales (principalmente usuarios clave que participan en CRP1 ) y permitirles comprender el funcionamiento básico del sistema a través del análisis CRP .
2) Determine los datos maestros que se migrarán (también conocidos como datos estáticos), emita un formulario de recopilación de datos y solicite a los usuarios clave que organicen al personal para comenzar a recopilar datos maestros.
3) Si el desarrollo complementario está involucrado en la solución de diferencia, después de que se determinen los requisitos de desarrollo, comience el diseño funcional y el diseño técnico. En principio, todos los desarrollos complementarios deberían probarse en CRP2 .
Una vez resueltas las diferencias en CRP2 y CRP1 (el desarrollo del suplemento puede ser posterior), inicie CRP2 .
El enfoque de CRP2 es verificar la solución de la diferencia. Si no se ha completado algún desarrollo complementario al principio, la parte de la función estándar se puede verificar en la primera mitad y la función de desarrollo complementario se puede verificar en la segunda mitad.
Cabe señalar que en CRP2 , no es posible probar solo la parte de diferencia, sino probar todo el negocio, para evitar el impacto de la solución de diferencia en el negocio original sin diferencia. La diferencia con CRP1 es que para los servicios sin diferencia en CRP1 , siempre que el resultado de la prueba sea el mismo que el de CRP1 , no hay necesidad de prestar atención.
Puede haber algunas diferencias nuevas en CRP2 (incluida la parte inapropiada de la solución en las diferencias en CRP1 ). Después del final de CRP2 , se requiere un juicio sobre las diferencias. Si el impacto de las diferencias en el negocio se considera aceptable, ingresar a la etapa UAT , en caso contrario, insertar la etapa CRP3 .
En CRP2 , para las normas comerciales determinadas, es necesario comenzar a capacitar a los usuarios finales, incluido el aprendizaje de nuevas normas comerciales y el aprendizaje de las operaciones del sistema.
UAT
UAT ( Prueba de aceptación del usuario ), también conocida como ejecución de prueba.
Antes de que comience UAT , los datos maestros deberían haberse clasificado e ingresado en el sistema utilizando el mismo método que cuando se puso en marcha.
En UAT , la situación en línea se simula para probar todo el negocio de la empresa. Aunque la prueba aún toma el negocio como pista, además del negocio, UAT también presta atención al grado de cooperación entre varios departamentos y usuarios, y presta atención a la aplicación de los principales documentos e informes en el negocio real.
UAT no es solo una prueba, sino también un encuentro entre departamentos y usuarios.
Una vez finalizada la UAT , para realizar un juicio en línea, considere los siguientes aspectos:
1) ¿Los pasos de procesamiento y los resultados del negocio son aceptables para el sistema?
2) ¿Es la diferencia restante lo suficientemente pequeña como para afectar el funcionamiento de la empresa?
3) ¿Es fluida la cooperación entre departamentos y usuarios?
4) ¿Son aplicables los informes y documentos ?
5) ¿Están listos los datos maestros necesarios para conectarse en línea?
6) ¿Es factible el plan de cambio en línea?
Si la empresa no puede utilizar con éxito el nuevo sistema al final, el trabajo de las etapas anteriores se desperdiciará. Debemos corregir la práctica de " centrarse en el plan e ignorar el lanzamiento " , y hacer el último esfuerzo para asegurar el éxito del lanzamiento de la empresa.
Cuando todas las etapas hasta UAT se completan con éxito, el éxito o el fracaso del lanzamiento depende principalmente de la racionalidad y ejecución del plan de lanzamiento. Es muy útil tener una lista de todas las tareas detalladas para el lanzamiento. La lista debe incluir la descripción, la carga de trabajo, la persona responsable, la hora de inicio, la hora prevista de finalización, los revisores, etc. de cada tarea. Para el PM que es responsable del lanzamiento del proyecto por primera vez , no es suficiente simplemente copiar la información de otras personas u otros proyectos, y se debe pedir a un consultor senior experimentado que lo ayude a verificarlo.
Esta etapa también debe incluir soporte de procesamiento comercial y soporte de liquidación mensual durante el primer mes después de que se completa el cambio en línea (excepto para proyectos individuales que no compran este servicio).
( Según la implementación de CRP de un proyecto, ¿cuántos documentos deben completarse? Cada proyecto específico, la respuesta será algo diferente. En todo esto, según mi comprensión personal, se enumera una lista de documentos. Considerando la conveniencia de comunicación, la codificación de nombres de documentos Trate de ser consistente con AIM ( versión 3.0) .
Descargo de responsabilidad: Las reglas del documento en esta sección son solo mis opiniones personales y no han sido reconocidas oficialmente. Puede entrar en conflicto con las reglas o hábitos de algunas empresas y personas.
Reglas de nombre de archivo sugeridas:
Abreviatura en inglés de proyecto_ ( abreviatura en inglés de subproyecto )_número de documento_descripción del documento_caracteres diferenciadores_versión.sufijo
Entre ellos, " abreviatura en inglés de subelemento " es opcional.
" Número de documento " es un código como CR010 , MD050 , DO070 ; " Descripción del documento " es una cadena de palabras en inglés concisas que se utilizan para explicar la función del documento, como "SOA" , "Diseño funcional" , "Manual de usuario" etcétera. El " carácter distintivo " se completa para que el nombre del archivo sea único. Por ejemplo, se pueden usar múltiples DO070 (manuales de operación) en el proyecto. Para distinguir estos archivos, el nombre del módulo y el nombre comercial se pueden usar como " carácter distintivo ” .
Ejemplo 1 , un proyecto se llama HAIF en inglés para abreviar, y la primera versión del libro de diseño funcional en Golden Tax Interface compilado en este proyecto puede llamarse HAIF_MD050_Functional Design_GoldenTaxIF_V1.0.doc .
Ejemplo 2 , un MFO de proyecto a gran escala se divide en varios subproyectos de acuerdo con la ubicación de implementación, y la abreviatura de una determinada ubicación (abreviatura de subproyecto o abreviatura de la empresa) es AB El manual de operación versión 1.1 del mantenimiento de las facturas por pagar compiladas por este proyecto se pueden nombrar como MFO_AB_DO070_User Manual_AP Invoice Maintenance_V1.1.doc .
Recomendación fuerte: evite usar caracteres de doble byte en los nombres de archivo, especialmente cuando trabaje con personas de otros países, los caracteres de doble byte pueden aparecer distorsionados en otros sistemas operativos de idiomas.
¿Utiliza WORD , EXCEL u otros?
Hay muchos usuarios de MS OFFICE , pero no se descarta que algunas empresas utilicen WPS de manera uniforme . Afortunadamente, estos editores son compatibles hasta cierto punto, y no necesitamos instalar editores nuevos para los clientes. Sin embargo, al comienzo del proyecto, el gerente del proyecto debe tomarse un tiempo para unificar el formato del documento con el gerente del proyecto del cliente. Tome MS OFFICE como ejemplo. A algunas empresas les gusta usar WORD , mientras que a otras les gusta especialmente use EXCEL Después de confirmar la herramienta, pero también para determinar la versión, algunos consultores están más de moda, siempre instale la última versión de la herramienta, si se guarda directamente como WORD 2007 , es posible que el cliente no pueda abrir el documento escrito por el consultor utilizando WORD 2003 . Todos están de acuerdo en una versión. Los usuarios de versiones superiores, al guardar archivos, elijan un formato compatible con las versiones inferiores. ( Si al cliente no le gusta probar un nuevo formato de documento, no hay necesidad de obligarlo a cambiar, y el consultor debe seguir los hábitos del cliente en este sentido) .
【Gestión de Proyectos】
1. CR010: SOA
Los caracteres anteriores constan de dos segmentos, el ":" está precedido por el " número de documento " , seguido de la " descripción del documento " .
El nombre completo de SOA es Alcance, Objetivos y Enfoque , que define el alcance, los objetivos y los métodos de implementación del proyecto para garantizar que tanto los consultores como los clientes tengan una comprensión común de estos aspectos. Esta documentación debe completarse durante la fase de negociación comercial. Después de que las dos partes lleguen a un acuerdo sobre este documento, comenzará el trabajo de implementación del proyecto específico.
2. CR020: Reglamento
En AIM , la descripción de CR020 es "Definir estrategias, estándares y procedimientos de control y reporte" . Además de CR020 , también hay documentos como CR030 , QM010 , RM010 , RM025 , etc. Cada documento se enfoca en una meta. I Siéntete así Los documentos múltiples son demasiado engorrosos (cada documento debe tener un conjunto de portada, historial de modificaciones, objetivo y otras tres páginas, el contenido real puede ser solo una página, un desperdicio), por lo tanto, a menos que el cliente requiera el cumplimiento estricto del AIM sistema de documentos ( aún no lo he encontrado ), escribiré todos estos contenidos en CR020 , como el gráfico de estructura de miembros del proyecto, proceso de informes, sistema de trabajo y descanso, reglas diarias de oficina, sistema de reuniones, estándares de inspección de calidad, servidor de archivos, información seguridad, etc
3. Control de documentos CM020
Enumere los documentos requeridos para la implementación del proyecto (entradas) y la lista de documentos que deben completarse (salidas). Como se mencionó anteriormente, los documentos en cada proyecto pueden ser diferentes, y el director del proyecto debe determinar la lista de proyectos de acuerdo con las características del proyecto.
Algunos contratos comerciales incluyen una lista de " presentaciones " , pero esta no es la documentación completa del proyecto.
El gerente del proyecto debe completar esta lista de verificación durante la etapa de preparación del proyecto. Además del nombre del documento, la lista de verificación también tiene tiempo (tiempo de uso o tiempo de finalización), y para los documentos de salida, debe haber una plantilla.
El director del proyecto debe obtener la aprobación del director del proyecto del cliente para este documento y luego entregárselo a todos los miembros del proyecto para garantizar que todos los miembros tengan una comprensión común del documento y evitar que aparezcan documentos con diferentes estilos en el proyecto.
4. WM020: EDT5 _0
Un plan de proyecto detallado, que incluye descripciones detalladas de tareas, recursos necesarios, fechas de inicio y finalización, entregables, etc. MS Project es una herramienta profesional para hacer y rastrear WBS , pero es muy costosa. Si no tiene este software, puede considerar usar EXCEL o un software de gestión de proyectos de código abierto. Algunos software de código abierto tienen las mismas funciones básicas que MS Project. , e incluso es compatible con MS Project , algún tipo de formato de documento.
5. CR040: Control de Riesgos
Describa el proceso de manejo de riesgos e incluya una plantilla de manejo de riesgos, use la plantilla para completar el contenido de riesgo y los métodos de prevención sugeridos.
6. CR060: Gestión del Cambio
Describa el proceso de gestión de cambios (como cambios en el alcance comercial, cambios en los requisitos funcionales después del desarrollo, etc.), el envío incluye una plantilla de procesamiento de cambios, use la plantilla para completar el contenido del cambio y la carga de trabajo estimada requerida para el cambio correspondiente .
7. PJM11: Informe Semanal
En AIM , PJM01 ~ PJM10 se definen como otros documentos de gestión de proyectos, y sigo usando su secuencia, comenzando desde el número 11 , para definir algunos otros documentos de gestión de proyectos.
Informe semanal , informe semanal del proyecto, complete el resumen del trabajo de esta semana, el gerente del proyecto escribe el informe semanal de resumen de todo el proyecto, y el gerente del proyecto puede designar al líder del equipo para escribir el informe semanal del equipo.
8. PJM07: Informe de fin de período
Un informe resumido al final de cada fase, y si se va a escribir un informe mensual, use este formato también.
9. PJM12: Memorándum de reunión
actas de reunión.
10. PJM02:
Memo de proyecto memo de proyecto.
11. PJM13: Hoja de Problemas
Libro mayor de materias.
En el proceso de implementación del proyecto, los problemas en la gestión del proyecto, el negocio, el sistema, los recursos y otros aspectos, para evitar que se olviden, deben registrarse en el libro mayor del proyecto.
Para cada tema, es necesario registrar la descripción general (título), descripción (se pueden usar anexos cuando hay muchos textos), grado de influencia, proponente, fecha de la propuesta y plazo esperado de resolución.
Después de que el gerente del proyecto discuta el nuevo tema con la persona a cargo relevante, determine la persona a cargo del tema.
La persona a cargo del proyecto debe seguir monitoreando el progreso del proyecto y actualizar el estado del proyecto a tiempo.
Después de resolver el problema, complete el método de solución y la fecha real de la solución.
En principio, el emisor confirma y cierra la emisión.
【Investigación y plan de negocios】
1. RD020: Cuestionario de Investigación Empresarial
Cuestionario de encuesta empresarial.
2. BP040: Modelo de negocio actual
Describa el modo de procesamiento comercial actual de la empresa y la demanda del cliente para negocios futuros. Con base en los resultados de la investigación comercial, cree este documento.
3. BP080: Módulo de Negocios Futuros
Describir el flujo de procesos de negocio de la empresa en el futuro.
4. BR100: Configuraciones
Registre los parámetros de configuración del sistema.
En AIM , BR110 se usa para registrar configuraciones relacionadas con la seguridad del sistema (como menús, responsabilidades), y creo que estos contenidos también pueden incluirse en la categoría de BR100 . Por supuesto, algunos clientes también insistirán en que la configuración general del sistema y la configuración de seguridad se separen en números de documento para que puedan asignarse a diferentes departamentos o usuarios.
Se recomienda mantener un documento de configuración en cada etapa de CRP , para poder verificarlo después. Es una buena práctica determinar primero el documento de configuración y luego configurar el sistema de acuerdo con el documento, para evitar omisiones durante el proceso de configuración.
5. RD050: Escenarios de Requerimientos de Negocio
Guión CRP . Este documento está escrito de acuerdo con el proceso comercial. Para cada proceso comercial, describe qué aspectos de las pruebas se llevarán a cabo, por ejemplo, qué tipos de datos se ingresan, qué informes se generan y cuáles son los puntos clave de confirmación.
Al ejecutar CRP (como CRP1 , CRP2 ), confirme uno por uno de acuerdo con este script y complete el resultado (documento de formulario BR030 ).
Dado que cada etapa de CRP tiene énfasis diferentes, el RD050 para cada etapa debe hacerse por separado . (A algunas personas les resulta problemático, solo haga una copia de RD050 y luego agregue algunas columnas para marcar qué contenido usa CRP1 y qué contenido usa CRP2 ).
Algunos proyectos usan TE040 para escribir scripts CRP.Mi definición es que TE040 está dedicado a la prueba de programas de desarrollo adicionales ( la definición de AIM es similar), y RD050 es un script completo de prueba de procesos comerciales.
6. PT040: Guiones de prueba de rendimiento
Guión de prueba de rendimiento. Algunos proyectos prestan especial atención a los procesos comerciales, pero ignoran el rendimiento del sistema. Es posible que esto no tenga ningún impacto en las empresas con un volumen comercial pequeño. Sin embargo, si la empresa genera una gran cantidad de datos todos los días, tiene muchos usuarios, lugares de trabajo dispersos y capacidad de red limitada, se requieren pruebas de rendimiento para evitar la apertura lenta de la interfaz del sistema después de estar en línea. Las solicitudes simultáneas no pueden finalizar a tiempo, los datos no se pueden exportar, etc., lo que afecta el progreso del negocio. Las pruebas de rendimiento deben centrarse en dos puntos: 1 ) la cantidad de usuarios; 2 ) la cantidad de datos históricos en la base de datos. Para programas desarrollados adicionalmente, los problemas de rendimiento deben ser considerados en particular.
7. Documentos de la serie TA
Si los términos de servicio incluyen hardware y red, se deben producir documentos del sistema TA , como TA120 (plataforma de servidor y estructura de red), TA110 (planificación de capacidad del sistema).Si es necesario, puede consultar las plantillas relacionadas con AIM , que no son listado aquí.
【Análisis de diferencias】
1. BR030: Requisitos comerciales asignados
Los resultados de CRP también se pueden denominar tabla de resumen Fit/Gap . Registra los resultados coincidentes entre el nuevo proceso comercial ( BP080 ) y el negocio actual y las necesidades de la empresa, y hay partes que coinciden y partes que difieren. Para discrepancias, se propone una propuesta de solución.
De acuerdo con el contenido de RD050 , realice un análisis de diferencias y complete el resultado en BR030 .
Cuando hagamos CRP , tomaremos como premisa "BP080 es totalmente compatible con el nuevo sistema " . Si durante el proceso de CRP , encontramos algunos enlaces que deben manejarse en el nuevo sistema, y los métodos de procesamiento o los resultados del nuevo sistema no son satisfactorias, También registrado en BR030 .
En AIM , el análisis de aplicabilidad del informe está escrito en BR070 , y mi costumbre es incluir el informe en BR030 , porque el informe también forma parte del análisis de procesos comerciales.
2. PT120: Resultado de la prueba de rendimiento
Realice una prueba de rendimiento de acuerdo con PT040 y escriba los resultados de la prueba en PT120 y brinde sugerencias de mejora para las piezas con bajo rendimiento.
【Desarrollo complementario】
1. MD010: Estrategia de extensión de aplicaciones
Definir las reglas que deben seguirse durante el proceso de desarrollo.
Algunos proyectos no prestan mucha atención a este documento y, después de recibir la tarea de desarrollo, dividirán el trabajo entre los técnicos para el desarrollo. El resultado de esto es que diferentes técnicos escriben programas de acuerdo con sus propios hábitos, y los estilos de los programas son diferentes, lo que genera problemas para la integración y el mantenimiento posterior. Por lo tanto, vale la pena tomarse el tiempo para finalizar este documento.
No tomará mucho tiempo hacer este documento. La compañía ha acumulado información relevante en proyectos a gran escala. Solo necesita capturar el contenido relacionado con el proyecto actual y hacer un procesamiento simple. Después de todo, la especificación de desarrollo es más Versátil Potente.
Después de compilado este documento, todo el personal técnico debe estar familiarizado con él y cumplirlo, de lo contrario, no se logrará el efecto esperado.
2. MD020: Definición de Extensión y Estimaciones
El esquema define las funciones que realizará el programa personalizado y estima el tiempo de desarrollo (incluido el diseño, la codificación, las pruebas, la documentación y el mantenimiento). La plantilla MD020 de AIM 3.0 tiene un formulario de cálculo para estimar la carga de trabajo, el cual está escrito con código VBA , el usuario selecciona el nivel de dificultad del programa personalizado, y la carga de trabajo de cada tarea se calcula automáticamente en el formulario.
3. MD050: Diseño de función de extensión
Escriba en detalle las funciones que realizará el programa personalizado, la lógica de procesamiento de datos, el diseño de la interfaz, el contenido y el formato de salida y el uso. La firma de este documento garantiza que los consultores y los usuarios tengan un entendimiento común del proceso de personalización.
4. MD060: Extensiones de base de datos
Defina objetos de base de datos personalizados, como tablas de datos, vistas, campos flexibles de descripción, conjuntos de valores, etc.
5. MD070: Diseño Técnico de Ampliación
De acuerdo con los requisitos de MD050 , enumere los métodos de implementación técnica, como la estructura del programa, la lógica técnica, etc. Los codificadores escriben códigos de programa específicos según MD070 .
6. MD120: Rutinas de instalación
El manual de instalación del programa personalizado enumera los pasos de instalación y los métodos de instalación del programa personalizado.
7. TE040: Guión de prueba del sistema
Guión de prueba del sistema. En este script, enumere qué aspectos de la prueba se realizarán en el programa personalizado, qué datos usar, qué pasos probar y cuáles son los criterios de aceptación. La prueba del sistema la realiza un consultor funcional, generalmente el mismo consultor que diseñó el programa MD050 .
En AIM 3.0 , también hay TE020 (prueba unitaria) y TE030 (prueba de conexión). Estos dos tipos de pruebas son realizadas por los desarrolladores. Después de pasar las pruebas, se entregan al consultor funcional para que las pruebe. Dado que es inevitable verificar el contenido de este aspecto (aunque puede que no sea particularmente completo) durante la prueba del consultor funcional, y la mayoría de los clientes no requieren la presentación de los resultados de TE020 y TE030 , estos dos documentos de prueba se enumeran en AIM como " opciones disponibles " .
8. TE110: Resultado de la prueba del sistema
Documentar los resultados de las pruebas del sistema.
La práctica habitual es copiar TE040 y cambiarle el nombre a TE110 en TE040 , donde hay una columna en blanco de " resultados de medición reales " , y completar la columna en blanco con los resultados de la prueba.
Para los puntos de función cuyos resultados medidos son inconsistentes con MD050 , se registra como BUG , y se requiere que el desarrollador modifique el programa.
Durante el proceso de prueba, si el resultado medido es consistente con MD050 , pero el consultor o el usuario desea modificar la definición de la función, se registrará como " cambio de requisito " , y MD050 debe modificarse primero , y luego el desarrollador debe modificar el programa. Después de cierto punto en el proyecto (generalmente antes de que comience la UAT ), los " cambios de requisitos " requieren una aprobación muy rigurosa.
【Usuarios de formación】
1. AP140: Plan de aprendizaje del usuario
programa de entrenamiento. En este plan, explique cómo los usuarios pueden dominar nuevos servicios y sistemas.
Debe incluir capacitación conceptual para la gestión, capacitación para usuarios clave y capacitación para usuarios finales.
Se debe definir el tiempo de formación, métodos de formación, criterios de evaluación.
2. DO070: Guía del usuario
manual de usuario.
De acuerdo con el proceso comercial, escriba el método de procesamiento del negocio en detalle, incluida la operación en el sistema y el procesamiento fuera del sistema.
Para fines de uso, los manuales de usuario deben agruparse por publicación.
En algunos proyectos, los manuales están escritos en unidades de funciones del sistema, que involucran principalmente funciones del sistema.Dichos manuales deben llamarse manuales de referencia del sistema, y el código del documento es DO060 . Creo que en la implementación del proyecto, DO070 es necesario y DO060 se puede omitir (reemplazado por la ayuda en línea).
A menos que existan disposiciones especiales en el contrato de implementación, haré arreglos para que los usuarios clave hagan DO070 como uno de los contenidos de evaluación para su capacitación.
3. DO030: Glosario
Al implementar un nuevo sistema, debe haber algún vocabulario profesional que no sea familiar para los usuarios, AIM recomienda hacer un documento para registrar este vocabulario. Si solo se explica
desde la perspectiva del " sistema " , este documento es fácil de hacer, porque ORACLE proporciona una lista de términos (no sé si SAP lo tiene, debería serlo).
En mi opinión, dicho documento no solo debe incluir el vocabulario del sistema, sino también términos específicos del negocio del lado del cliente. Como consultor, cuando ingrese por primera vez a esta empresa, también encontrará algunos términos nuevos. Es muy significativo registrarlos y dar explicaciones desde una perspectiva comercial, como acumulación de experiencia y como referencia para los seguidores de seguimiento.
Incluso si se trata de un vocabulario del sistema, será más significativo si se puede dar una explicación en combinación con los términos comerciales y habituales del cliente que copiar el glosario de ORACLE .
4. Otro
Preguntas del examen de capacitación, tabla de resumen de puntaje de prueba, ¿qué números se usan para estos documentos? Tampoco lo encontré de AIM , personalízalo en la secuencia AP , como AP210 , AP220 .
【Datos iniciales de migración】
1. CV010: Requisitos de conversión de datos
Enumere la lista de datos que se van a migrar, los requisitos de datos, el tiempo de migración y la secuencia.
Después de que algunos proyectos se pusieran en línea, se encontró que se omitieron algunos datos iniciales, lo que causó un gran impacto en la producción normal de la empresa. Dichos problemas se pueden evitar si existe una lista de verificación de migración que se haya estudiado cuidadosamente y confirmado con anticipación.
2. CV020: Estándares de conversión
normas migratorias.
Para cada tipo de datos a migrar, explique el formato de datos, el método de recopilación de datos, el método de importación y el método de verificación.
3. Otro
Si desea escribir algunos programas especiales para la migración, como la carga del proveedor, la carga de la lista de materiales, etc., que involucran el diseño funcional y la prueba del sistema, se recomienda utilizar documentos de la serie TE ( AIM ha enumerado especialmente un conjunto en la serie CV ) al igual que los programas personalizados. , el contenido del documento se puede simplificar adecuadamente.
【Conéctese en línea y maneje negocios reales】
1. PM010: Estrategia de Transición
Estrategia de puesta en marcha.
Incluye el plan de lanzamiento, los recursos comprometidos, las contingencias y contramedidas previsibles y los equipos de apoyo.
2. PM060: Infraestructura de Apoyo a la Producción
Método de apoyo.
Un proceso de soporte eficiente y poderoso es muy importante para el funcionamiento normal del nuevo sistema.
Antes de entrar en línea, el equipo del proyecto debe determinar el método de soporte operativo y escribirlo en este documento, que incluye el siguiente contenido: a quién contactar si hay un problema, información de contacto de emergencia, horario de trabajo del equipo de soporte, cómo usar el sistema de ayuda en línea, etc.
【otro】
Hay bastantes documentos arriba, pero en el proyecto, es posible que algunos documentos no se encuentren en la lista anterior. Por ejemplo, el saldo de la cuenta a transferir lo proporciona EXCEL , también es un documento y tiene valor retenido, ¿qué código se debe usar para el nombre del documento? En este caso, puedes buscar uno similar de la lista anterior, como CV020 , o numerarte tú mismo en la misma serie (intenta no solapar con AIM ), como CV210 .
Casos de aplicación de CRP enno EBS :
El Metro de Beijing-Hong Kong ha incorporado el método CRP en la construcción e implementación del sistema de información, para que el personal comercial pueda participar plenamente en la construcción del sistema y comprender los conceptos contenidos en el sistema de información durante el proceso de participación, para que los usuarios puede tener confianza en el proceso de construcción e implementación del sistema. Aceptar y familiarizarse con los sistemas de información. Poco a poco, el Metro de Beijing-Hong Kong ha desarrollado su propia metodología de gestión de proyectos de sistemas de aplicaciones, y CRP se ha convertido en una parte clave de la misma. Esta metodología también jugará un papel en la construcción de otros sistemas de información del Metro Beijing-Hong Kong en el futuro.
"¿ Qué quiere hacer? ", La gente de TI a menudo pregunta de esta manera a los empresarios al comienzo de un proyecto de TI . Lo mismo sucedió cuando el Metro Beijing-Hong Kong llevó a cabo su primer proyecto de informatización , el sistema de recursos humanos. Pero como una empresa recién establecida, el personal comercial a menudo no tiene muy claro lo que quiere.
Posteriormente, el Metro de Beijing-Hong Kong incorporó el método CRP en la construcción e implementación del sistema de información, lo que permitió que el personal comercial participara plenamente en la construcción del sistema y comprendiera los conceptos contenidos en el sistema de información durante el proceso de participación, lo que permitió a los usuarios participar en el proceso de construcción e implementación del sistema Aceptar y estar familiarizado con el sistema de información. Poco a poco, el Metro de Beijing-Hong Kong ha desarrollado su propia metodología de gestión de proyectos de sistemas de aplicaciones, y CRP se ha convertido en una parte clave de la misma. Esta metodología también jugará un papel en la construcción de otros sistemas de información del Metro Beijing-Hong Kong en el futuro.
Introducción a la PCR
" Como empresa nueva, el Metro de Beijing-Hong Kong no está muy familiarizado con sus propias cosas, por lo que el método CRP es más adecuado para el Metro de Beijing-Hong Kong " , piensa Lin Zeyin, gerente del sistema de información de MTR (China e internacional).
CRP es en realidad un proceso de este tipo. En primer lugar, hay un sistema estándar, que puede contener muchas mejores prácticas internacionales. De esta manera, no hay necesidad de preguntar a los usuarios qué es lo que quieren primero, y el equipo de implementación puede decirles a los usuarios que esto es un proceso estándar, se pueden hacer modificaciones dentro de un cierto rango. Tras la modificación, se pide la opinión del usuario, y así sucesivamente. " Para una empresa nueva como la nuestra, creo que este método es muy adecuado " . Huang Yingjun, gerente del departamento de tecnología de la información de Beijing Jinggang Metro Co., Ltd. dijo: " Porque somos solo una hoja de papel en blanco. Dado que es un proceso estándar, si nos sentimos bien puede seguir su ejemplo. ” Debido a que muchos negocios de la nueva empresa no están claros, la mejor manera es seguir los estándares internacionales.
Usando el método CRP , el personal comercial del Metro de Beijing-Hong Kong participó plenamente en la construcción e implementación del sistema. Cuando se realiza el proceso de CRP en el Metro de Beijing-Hong Kong, lo primero que hace el equipo de implementación es preguntarle al vendedor qué negocio está haciendo, y luego registra todos los negocios mencionados por el vendedor. El personal dedica alrededor de una semana a decirle al personal comercial cómo se realiza su trabajo en el proceso del sistema. Esta vez es la primera ronda de CRP .
Después de la narración de esta semana, el personal comercial puede sentir que algunas partes del sistema no son buenas o que algunas partes están en conflicto, por lo que los implementadores deben modificar el sistema de información y luego informar al departamento comercial nuevamente después de la modificación.
" Cuando se trabaja en proyectos de sistemas de información, el personal del departamento de negocios en realidad está más cansado que el personal de TI " . Huang Yingjun dijo: " Porque tienen que hablar constantemente sobre su negocio y luego tienen que pensar en qué negocio van a hacer". tener en el futuro " . En Beijing Hong Kong MTR generalmente realiza tres rondas de CRP , y cada ronda de CRP toma alrededor de un mes para permitir a los usuarios más tiempo para comprender el negocio. En la primera ronda de CRP , es básicamente el equipo de implementación quien habla, opera y explica; en la segunda ronda, el equipo de implementación habla y el departamento de negocios realiza las operaciones; opera.
" Después de tres rondas de CRP , el proceso de aceptación del usuario se llevará a cabo muy rápidamente " , dijo Huang Yingjun.
Implementación del Sistema de Logro
Después de aproximadamente 3 años de construcción e implementación del sistema de información, Beijing-Hong Kong Metro ha desarrollado gradualmente su propia metodología de gestión de proyectos de sistemas de aplicaciones. " Desde el análisis de requisitos hasta la planificación de proyectos, análisis funcional, diseño, construcción, UAT , producción, resumen, independientemente del tamaño del proyecto, seguimos este vínculo " , dijo Huang Yingjun.
Entre ellos, el proceso de CRP se incluye en el proceso de análisis y diseño funcional . La comunicación con el usuario, la capacitación y el emparejamiento de usuarios clave es una ronda de CRP . Después de CRP , ingresará a la etapa de diseño, modificará algunos procesos comerciales y de diseño, y luego combinará tras modificación. Esto es equivalente a tres rondas de CRP y luego ingresará al desarrollo. , prueba y fase de aceptación del Usuario. Hay casi tres rondas de desarrollo, prueba y aceptación del usuario. " De esta manera, básicamente, no habrá problemas importantes en el sistema " , cree Huang Yingjun.
Todo el método de gestión de proyectos del sistema de aplicaciones del Metro de Beijing-Hong Kong es casi el mismo que el del MTR. " Solo nos falta una etapa de selección de productos " , dijo Huang Yingjun, " porque la mayoría de nuestros sistemas son de MTR " .
Con todo el conjunto de métodos de gestión de proyectos del sistema de aplicaciones, el Metro de Beijing-Hong Kong será útil en la futura construcción del sistema de información, lo que permitirá a los usuarios comprenderlo y aceptarlo durante el proceso de construcción e implementación del sistema.