La Conferencia de Nueva Piloto de habitaciones

Posted by admin on March 20, 2013

Información general

Realización de las principales empresas funcionan los sistemas requiere una planificación, visión, liderazgo, trabajo en equipo y un gran esfuerzo. Esta presentación explica el papel del piloto de la Sala de Conferencias (PCR) para ayudar a asegurar el éxito, cómo ayudar a rediseñar el sistema de negocio de la compañía, cómo se pueden instalar y operar la misma.

¿Qué es un piloto de la Sala de Conferencias?

Una metodología para desarrollar y simular el funcionamiento de un sistema, para aprender cómo funciona / debe trabajar y la mejor manera de manejar el negocio con él – antes de “vivir” la aplicación.

On-Line, los sistemas interactivos, integrados y software de confundir a la evaluación tradicional y los métodos de planificación de la implementación. Varios “amabilidad” y temas de software “personalidad” son mucho más fáciles de evaluar y entender en una simulación en vivo que a través de revisión de la documentación, diagramas de flujo y argumentos de venta de los proveedores. Puede ser en línea o en papel.

El CRP ha sido tradicionalmente asociado con el modelado de las pruebas y de negocios con nuevos programas de computación, pero también se puede utilizar para manejar la evaluación de las políticas, procedimientos, organización, formas de capacitación y medidas de actuación. Se puede utilizar para comprobar los cambios en los sistemas existentes. El más próximo a la realidad se pone, más eficaz será la experiencia de formación. Cada vez es más común dejar una base de datos de la PCR en lugar de utilizar como banco de pruebas permanente y la educación / herramienta de formación.

Aplicaciones

Algunas personas usan el término en el sentido de la PCR de pruebas de software antes de su implementación. Si bien esta es una excelente aplicación, la lista de abajo indica que hay muchos más usos:

La PCR puede ser utilizada para:

o Explorar las cuestiones de política / procedimiento, las alternativas de solución e iniciar las mejoras.

o parcialmente o completamente rediseñar el sistema de la compañía para mejorar el rendimiento.

o Capacitar a los empleados en la operación de las políticas, procedimientos system/software-, software, formularios e informes.

o Adquirir un conocimiento práctico / evaluación de cómo el software funciona de verdad-enfoque, fortalezas y debilidades.

o exactitud de la prueba de las propuestas de los proveedores, reclamaciones y documentación.

o Ayudar a desarrollar un plan viable para la conversión, la aplicación y utilización del software como parte de un sistema global.

o Proporcionar la educación en la forma de un sistema de fabricación y el software podría funcionar-en especial las relaciones interdepartamentales.

o Facilitar la construcción de descripciones de sistemas y demostraciones de cumplimiento de la normativa.

La PCR se puede utilizar durante una o más fases del ciclo de vida del sistema:

o Identificación y desarrollo de políticas, procedimientos y el enfoque operativo.

Shakedown o cruceros para refinar / depurar el software, las políticas, procedimientos, capacitación y el enfoque, incluso de la organización.

o herramienta de formación continua.

o banco de pruebas en curso un nuevo software / modificados, políticas, procedimientos, áreas de aplicación, incluyendo la integración de sistemas.

Hay varias ventajas importantes sobre otros enfoques:

o Evaluar, probar y aprender con un riesgo mínimo.

Pon a prueba o más alternativas, más completa.

o más fácil de controlar las condiciones.

o mucho más rápido y más barato que una simulación completa, “en vivo” piloto, el funcionamiento en paralelo o “pavo frío” / “big bang” (la aplicación total de todos a la vez).

o mucho más realista que las pruebas del programa / módulo de orientación técnica.

o La PCR es lento, pero por lo general se traducirá en mejores y más rápidos resultados de la ejecución en el largo plazo.

Las desventajas también existen:

O CRP consumen tiempo.

o ¿En un principio ralentizar el ciclo de aplicación, pero puede rendir mejores resultados.

o Requerir alto grado de disciplina, pero también lo es la implementación de un sistema mayor – piensa en ello como una buena práctica.

¿Cómo funciona?

Recomendados elementos clave de un éxito PCR se describen y explican brevemente:

A. Planificación / organización

o Objetivos – Es una buena idea para reiterar los objetivos del sistema o escritura sobre ellos si no lo ha hecho. Los buenos objetivos son claros y cuantificables siempre que sea posible. Se apoya directamente los objetivos estratégicos de la compañía y objetivos del plan. Objetivos de PCR debe ser seleccionado en la sección de aplicaciones por encima y por adaptarse a los objetivos de la empresa.

o Alcance – Es importante señalar lo que está incluido – y no incluido – en el CRP. Indique las aplicaciones, las organizaciones de afectados y la profundidad deseada de la participación. Por ejemplo, ¿desea rediseñar por completo el proceso para eliminar todas las operaciones sin valor agregado, o simplemente automatizar o convertir un enfoque actual? ¿El proyecto abarca todos los sistemas de negocio de la compañía, o simplemente de compras, planificación de necesidades o cuentas por pagar?

o Organización – ¿Quién será responsable de dirigir, realizar y actuar sobre los resultados? ¿Cuál es el papel de cada jugador? ¿Qué grado de autonomía / empoderamiento se asume? ¿Cómo va a MIS, vendedores, consultores estar involucrados?

Enfoque o – ¿Cómo funcionará el proyecto de la PCR? ¿Cómo va a ir a los jugadores acerca de sus tareas asignadas? Qué herramientas se emplearán para llevar a cabo el proceso?

o Plan de Proyecto – Crear los principales hitos, fechas, actividades de apoyo, tareas de responsabilidad, las relaciones de precedencia, la duración, requisitos de recursos (personas, equipos, en las afueras de apoyo). El plan se convierte en la herramienta de gestión del proyecto principal y puede ser en realidad un subconjunto de un plan más amplio, como la aplicación MRPII. Cada área de aplicación tiene que tener sus propias metas, responsables y plan de actividades. Hemos encontrado que funciona mejor para utilizar al menos a algunas personas cuya regularmente las responsabilidades del trabajo se encuentran en las zonas afectadas.

B. Definición de requisitos y / o documentación

Algunas personas dicen que esto no debería ser parte de una PCR. Al parecer, aquí por tres razones:

o Asegúrese de que no se ha olvidado.

o poner un negocio en lugar de un énfasis técnico en el CRP.

o Ponga la estructura en el esfuerzo de la PCR.

Sin una base metódica para la operación prevista de un nuevo sistema, el CRP tienden a vagar sin rumbo y estarán sujetos a la manipulación de los proveedores u otras personas con una agenda diferente. Si los requisitos están definidos ya – grande. Sin embargo, mi experiencia es que la mayoría de las empresas que afirman tener esta completa han hecho un trabajo superficial o incorrecta. No te sumerjas en el software antes de esta tarea importante que se hace primero!

Es imprescindible saber a donde vas y cuando vas a venir desde el momento de emprender el peligroso viaje de un cambio importante en el sistema. La. Tal cual y a ser el enfoque de definición de los sistemas sólo pueden shortcutted mucho antes de meterse en problemas A pesar de que no creo que un sistema existente, si es que ser reemplazado, debe ser exhaustiva y documentada minuciosamente, es necesario entender cómo funciona y qué cuestiones y problemas existen. Después de eso, un primer corte más detallada y completa “a ser” la definición debe ser creado. Puede ser sucesivamente refinado como el programa se mueve hacia adelante.

La experiencia ha demostrado que los esfuerzos iniciales del sistema más documentación no reflejan la riqueza real, la complejidad, la ambigüedad y la diversidad de la operación del sistema real. La gente suele asumir que el sistema actual es lógico y racional, pero no siempre es así. Los primeros análisis paso a menudo aparecen “de un solo hilo”, ya que muestran lo que pasaría si todo ha ido bien. En la vida real, hay muchas excepciones, muchos, que requieren complejas ramificaciones y actividades alternativas. Para empeorar las cosas, no todo el mundo maneja las cosas de la misma en todos los casos. De hecho, por lo general hay una buena dosis de ambigüedad e incluso callejones sin salida en la mayoría de los sistemas de De facto. MRB, devoluciones de los clientes y el procesamiento de fuera son buenos ejemplos de esto en la mayoría de las empresas.

Herramientas convencionales de desarrollo y la documentación no se utiliza a menudo en una forma que se ocupa de la anterior manera efectiva. Para acabar con estos problemas se ha utilizado el “flujo de vida carta” método con un grado bastante alto de éxito desde hace algún tiempo. En lugar de la documentación de los sistemas en los diagramas de aburridas y complejas que se escondidos en los libros, intente lo siguiente:

Emplear sistemas de los usuarios o miembros del equipo del proyecto, y no profesionales de sistemas, para la construcción de las listas de éxitos. Utilice los sistemas de calidad de facilitadores. ¿Por qué?

o inculca la propiedad del usuario.

Los usuarios o conocer mejor “, donde están enterrados los cadáveres.”

Gestión de proyectos y las personas son a menudo sistemas nerviosos reales en hacer esto porque los usuarios suelen llegar a un análisis de los pobres, los requisitos poco realistas, o peor aún, tratar de automatizar el status quo.

¿Cómo evitar estos escollos

o En primer lugar, proporcionar educación en los enfoques de sistemas modernos y proporcionar una base sólida en las aplicaciones que se estudiará. Crear equipos calificados y bien equilibrado. Exponer a las personas a los métodos utilizados por las empresas más exitosas, pero permiten a las diferencias, asegurándose de que los autores no afirman que “no va a funcionar aquí porque estamos aeroespacial” o alguna tontería parecida. A continuación, explicar cuidadosamente cómo desea realizar la documentación.

o A continuación, establezca objetivos a ser alcanzados, tales como: reducir el papeleo del 50% en el procesamiento de pedidos, o reducir el tiempo de contratación en un 33%. Esto obligará a la gente a mirar más allá de los enfoques actuales para alcanzar los enfoques deseados. También ayudará a asegurar que el proyecto va a generar un saludable retorno sobre la inversión. Haga hincapié en que los procesos deben ser re-diseñado, no sólo replica en un nuevo sistema informático.

Trate de poner los diagramas de flujo en las paredes, de tamaño natural, con formas reales, pantallas e informes. Conecte los flujos con las flechas de gran visibilidad. Tiempo de grabación del ciclo, las responsabilidades y las políticas y procedimientos aplicables para cada proceso. Pon notas en la pared explicar qué se está haciendo, cómo y por qué. Revise estos flujos con varios departamentos, auditores, clientes, incluso la gente y el gobierno-a nadie que lo escuche y proporcionar retroalimentación! El día antes de que esto fue escrito, el Presidente de una de las empresas que utilizan este enfoque fue con el equipo, ya que estaban trabajando en la pared de tablas de toma de sugerencias! ¿Cuándo fue la última vez que sucedió en su empresa? Una increíble variedad de personas que han contribuido en el proceso en esta empresa.

Ahora aquí está un punto clave …

¿La gente escriba todas sus sugerencias, su nombre y la fecha en pequeñas tarjetas amarillas o “post-It” notas (TM) y una bofetada para arriba en la pared donde se aplican. El equipo del proyecto puede registrar, clasificar, editar y dar prioridad a ellos en una lista de temas, que se utiliza para impulsar las actividades de cambio. Hablar de empoderamiento! Una vez que el tal y como son de configuración se documenta, y discutir temas de dirección, a continuación, iniciar la derecha en la a-ser.

Las tablas a-ser puede ser reelabora de la que es-, pero parece que funciona mejor con nuevas cartas, codo a codo con los antiguos. Por cierto, estos cuadros pueden llegar a ser masiva. Vimos uno que consume once grandes paredes. La re-ingeniería “a ser” la versión fue menos de la mitad de eso. Más palabras de consejo: no deje que los especialistas trabajan de manera aislada a emplear equipos multi-funcionales para obtener una imagen equilibrada y con pleno conocimiento de las interacciones del sistema.

Además, estimula la creatividad del equipo si se proporcionan algunos de los objetivos difíciles, tales como: “reducir los tiempos de ciclo y los trámites administrativos en un 50%.”

C. Administración

La administración competente contribuye de manera significativa al éxito del PCR. Se recomienda que un administrador puede asignar a un centro de coordinación de todas las actividades de PCR. En un proyecto más pequeño, esta persona podría ser muy probable que el gerente general del proyecto o de una persona de informática. En proyectos más grandes, esto normalmente sería una actividad que todo lo consume desde hace meses.

Trabajo para el plan del proyecto para la asignación de tareas, programación, control, seguimiento y presentación de informes ayuda a mantener el programa a tiempo, en presupuesto y en el buen camino.

El administrador debe planificar el PCR, el proceso de conjunto y de los estándares de documentación asegurar que los líderes funcionales publicar anuncios de reuniones, liberar minutos completos de reuniones, mantener registros adecuados de las reuniones y decisiones no se pueden resolver los problemas y se refieren al comité directivo. Esta persona también debe supervisar el proceso para asegurarse de que está siendo seguido según lo prescrito.

Mantener los parámetros del sistema – por defecto, la configuración de las cosas tales como redes de los métodos, los métodos de cálculo de costos, reglas de excepción de presentación de informes, normas contables, cuentas por defecto de carga, etc

Asegúrese de que las bases de datos se mantienen:

PCR o bases de datos, utilizado para las pruebas de negocio estructurados de diferentes escenarios probables.

o “jugar” bases de datos de forma libre / experimentación ad hoc.

o base de datos de entrenamiento, que se utiliza para la instrucción formal e informal.

o MIS deben mantener vivos (de producción) bases de datos para las diversas organizaciones que emplean el software después de la implementación.

Se requiere el mantenimiento de la PCR bases de datos incluye cosas tales como el mantenimiento de los parámetros según las instrucciones de administración de proyectos. Por ejemplo, el administrador puede recibir instrucciones de un líder funcional para cambiar un parámetro, como el inventario de registro por defecto número de cuenta. Antes de que se hace, es aconsejable revisar el impacto con el grupo y tomar las medidas adecuadas antes / después de su aplicación. Puede ser que sea necesario informar a los otros miembros del equipo sobre el impacto de este cambio. Los cambios ensayados en el CRP puede ser posteriormente se trasladó a otras bases de datos después de que el equipo ha indicado que es la dirección a seguir. Para obtener los mejores resultados, MIS probablemente debería llevar a cabo este después de evaluar el impacto y la consulta con el equipo, que ya debería haber consultado con los usuarios de los sistemas de clave.

El administrador también puede pedir para mantener los archivos de bases de datos de PCR y dar marcha atrás / restauración de varias versiones en distintos momentos. MIS debe dar el administrador de una mano libre y las herramientas adecuadas o de servicios públicos para llevarlo a cabo de manera eficiente y rápida.

D. Equipo / instalaciones

El establecimiento de instalaciones adecuadas pueden mejorar los resultados, reducir los costos y el tiempo requerido para completar con éxito la PCR. Un área de la sede del proyecto debe proporcionar un espacio adecuado para que los equipos reúnen, realizan actividades de diagramas de flujo de pared, llevar a cabo formación en el aula y las pruebas de simulación. La figura 2 muestra una instalación utilizada para una empresa de medianas empresas la implementación de un MRPII integrado / sistema financiero.

Un número adecuado de terminales o puestos de trabajo y ambas impresoras de línea y el esclavo deben estar disponibles en estrecha proximidad entre sí y de las instalaciones para habitación las impresoras esclavos son necesarios para documentar contenido de la pantalla en los puntos de prueba críticos). Esto permite una interacción más eficaz del grupo de ejercicio de sus funciones. Equipo más tarde puede ser reciclado para la producción, a menos que una pequeña cama en curso prueba PCR se mantiene.

E. Técnica

O MIS debe proporcionar las bases de datos como los descritos anteriormente, los respaldamos con regularidad, dar marcha atrás / capacidades de restauración y / o servicios, equipos y servicios adecuados de apoyo.

o Proporcionar ayuda con flujos de trabajo por lotes.

o la continua participación de MIS PCR en la prestación de apoyo técnico y aplicaciones ayudará a asegurar resultados favorables. Consultores técnicos, software y fabricantes de hardware pueden desempeñar un papel importante aquí.

F. Fase Operacional

Hay muchas maneras de organizar las actividades de PCR. Aquí hay una buena:

líderes o funcionales de la construcción directa de tal cual y los flujos a-ser, identificar los problemas.

o equipo trabaja en la priorización, asignación y solución de los problemas identificados.

PCR o administrador lo hace una carrera informal a través de diagramas de flujo del sistema, el juicio corre el software en línea y desarrolla una “línea de la historia” para guiar a los escenarios para ser escrito.

o administrador de la PCR presenta plan general de la PCR y el horario.

o administrador de la PCR se establecen las directrices de PCR escenario. Mantenga los casos de prueba pequeña. ¿Quieres una buena muestra de productos, procesos y organizaciones que participan, no es un ejercicio masivo de datos de entrada.

Los líderes funcionales construcción detallados escenarios funcionales a partir de las directrices, los conocimientos propios de las funciones, la lista de temas y consejos de los usuarios del sistema, los administradores y otras partes interesadas legítimas. Otros revisar y aumentar este producto.

Los líderes funcionales a pie equipos multi-funcionales y los posibles usuarios del sistema a través de diagramas de flujo. Manejo tema se discute. Los líderes toman grupo a través de ejercicios de escenarios on-line. Varias preguntas y adiciones a los problemas previstos se elevan y los enfoques alternativos que se evalúan se. La mayoría de los problemas deben ser resueltos por el equipo durante los ejercicios o delegada para la acción futura. En ocasiones, las cuestiones se refiere al comité de dirección, cuando el grupo es incapaz de resolverlos. Esto debería ser inusual si la composición del grupo es correcta y que están facultados para hacer frente a la mayoría de los temas. Es recomendable haber tenido por lo menos parte de la formación de los vendedores de software y, ciertamente, “genérico” o la educación específica de la industria antes de intentar estos pasos.

Es una buena idea hacer los tutoriales y resolver la mayoría de las cuestiones sobre el papel en primer lugar, antes de comenzar la simulación por ordenador. Por qué: Demasiado duro para mantener a cargar la base de datos, volver a hacer ejercicios y restablecer los parámetros de todo el tiempo.

No tenga miedo de probar enfoques ad-hoc a los problemas encontrados. Si preocupados por la contaminación de la base de datos mediante una desviación de lo probado y verdadero, trate de pruebas en virtud de contratos diferentes, piezas, cuentas, o incluso sobre una base de datos separada. Esta es una de las razones por las que recomienda tener un “juego” base de datos anterior.

No caigas en la trampa de probar las distintas funciones o los proveedores de software de “módulos”. Ejecutar un ensayo completo, integrado de todo el sistema, con los datos que fluyen a través de todas las porciones, de modo que la interacción puede ser probados en un entorno tan cerca como sea posible a la una a implementar.

No se limite a ejecutar a través de las pantallas de los vendedores y los informes, o servil replicar sus enfoques existentes. Utilice todas las políticas, procedimientos y formularios que se utilizarán para ejecutar realmente el negocio, pero mira para mejoras / simplificación en el proceso. El software es sólo una herramienta de trabajo y sólo funcionará como parte de un todo integrado.

Documentar los resultados de las pruebas y discusiones, utilizando copias de pantalla y el informe, así como notas escritas y resúmenes publicados.

En la mayoría de los casos, el grupo comenzará a darse cuenta de lo poco que se sabe realmente sobre el proceso y cómo los problemas de muchos de ellos han salido de ella en el pasado. El proceso de PCR permite el conocimiento en rápida expansión, y que les permitan resolver mejor los problemas planteados.

G. Disposición

Llevar el cierre al esfuerzo es la clave para beneficiarse de todo el trabajo por hacer. Un enfoque estructurado y metódico, la documentación de los resultados y el control de las cuestiones abiertas ayudará a hacer que esto suceda.

Es importante capturar los resultados y las cuestiones planteadas y de acosar a su resolución para mejorar continuamente el enfoque del sistema. La resolución de problemas es lo que realmente impulsa el proceso de cambio.

Utilice el equipo de la facultad de resolver los problemas cuando sea posible. Mantener un diálogo con las organizaciones afectadas. Utilice el comité de dirección como el “arma secreta” para superar los obstáculos cuando no pueden hacerlo.

No se limite a “automatizar el caos que ya tiene.” Centrarse en la reingeniería del proceso para mejorar el rendimiento, pero no se deje llevar. En algunos casos, es posible hacer mejoras importantes después de la implementación inicial.

Poner en marcha mecanismos para traducir rápidamente las conclusiones y recomendaciones en el cambio. La mejor manera de hacer esto: Los miembros del equipo competentes deben proceder de las zonas afectadas, ser autorizados por su gestión para hacer cambios, teniendo en cuenta las directrices para la aplicación de cambios rápidos y animados a hacerlo! Para romper las barreras burocráticas, se sugiere que los cambios sugeridos se aprobó por defecto, si se ha introducido en un registro de la resolución publicado con regularidad temas, debatieron en una reunión del proyecto y permanecer sin respuesta por un tiempo determinado.

Conclusión

Puede ser evidente a partir del material anterior que el enfoque de la PCR es una excelente oportunidad para la evaluación, pruebas, desarrollo, educación y formación. Esta es una gran manera de construir un equipo entrenado de antemano, para garantizar una aplicación más exitosa.

Se ha observado por los veteranos de la implementación de sistemas exitosos que las pruebas y otras actividades de la sala de conferencias piloto tomó mucho más tiempo de lo previsto inicialmente, pero que valió la pena. Algunas de estas mismas personas señalaron que era necesario para ejecutar a través de la PCR más de una vez, con el fin de incorporar las lecciones aprendidas en un nuevo intento (s). Algunos equipos de proyectos fallidos han comentado que debería haber pasado más tiempo en ellos.

Hemos encontrado que casi nadie inicia éstos por sí mismos a menos que hayan sido expuestas a ellos antes o menos que alguien con experiencia les ayuda a introducir el proceso al proyecto. De hecho, a veces hay resistencia activa o indiferencia de algunos de los no iniciados, que consideran que el enfoque sería perder demasiado tiempo. Si bien no es intuitiva, este y otros métodos de PCR se encuentran para ser lógico, fácil de entender y aceptar una vez trató con una mente abierta.

El piloto de la Sala de Conferencias es la forma más eficaz que conozco para realmente aprender y comprender un sistema de evaluación para fines de planificación, la educación, pruebas y puesta en práctica.

Este artículo también está disponible en nuestro sitio web: ProAction – Generación de Mejores Prácticas. Es un extracto de un artículo escrito originalmente por George Miller, fundador de la pro-acción. Ha sido modificado y actualizado por Pablo Deis, ProAction CEO.

Categories: Software

Comments are closed.