Development

Connection Pooling

What Is Connection Pooling?

Connection pooling enables the reuse of existing connections to reduce the overhead of continuously creating and disposing of connections that have the same configuration. In other words, opening and closing connections that use the same connection string and credentials can reuse a connection that is available in the pool. Typical applications use the same connection objects to continuously fetch and update data from a database. Connection pooling provides a much higher level of performance by eliminating the need for the database to constantly create and dispose of connections. Connection pools are separated by process, application domain, and connection string. For connection strings that use integrated security, a separate pool is created for each unique identity.

Controlling Connection Pooling Options

Connection pooling is enabled by default when creating ADO.NET connection objects. You can control connection pooling behavior (or disable pooling altogether) by setting connection string keywords specific to connection pooling. For example, to specifically disable connection pooling, you set Pooling=False in your connection string. Table 5-7 provides a list of connection string keywords that can be used to control how a specific connection interacts with the connection pool. Not all keywords are available for every provider. For example the OLE DB provider controls connection pooling (also known as resource or session pooling) based on the value set for the OLE DB Services keyword in the connection string.

Table Connection Pooling Connection StringIn addition to connection string properties that control connection pooling behavior, there are also methods available on connection objects that can affect the pool as well. The available methods are typically used when you are closing connections in your application and you know they will not be used again. This clears the connection pool by disposing of the connections instead of returning them to the pool when they are closed. Any connections that are already in the pool and open will be disposed of the next time they are closed. Table 5-8 lists the available methods for interacting with connection pools.

Configuring Connections to Use Connection Pooling

By default, all .NET Framework Data Providers available in ADO.NET have connection pooling turned on, but the level of control available for working with connection pooling varies  based on the provider being used.

Configuring Connection Pooling with SQL Server Connections

By default, the SqlConnection object automatically uses connection pooling. Each time you call Sqlconnection.Open with a unique connection string, a new pool is created. Control connection pooling behavior by setting the connection pool keywords in the connection string as described earlier in Table 5-7. For example, consider a connection where you want to set the minimum pooi size. By assigning a value greater than zero to the Mîn Pool Size keyword you ensure the pool will not be destroyed until after the application ends. To set the minimum pooi size to 5, use a connection string similar to the following:

Data Source=SqlServerName;Initial Catalog=DatabaseName; Integrated Security=True;Min Pool Size=5

The minimum pool size is 0 by default, which means each connection needs to be created and initialized as they are requested, by increasing the minimum pool size in the connection string the indicated number of connections are created and ready to use, which can reduce the time it takes to establish the connection on those initial connections.

Configuring Connection Pooling with Oracle Connections

Connections that use the .NET Framework Data Provider for Oracle automatically use connection pooling by default. You can control how the connection uses pooling by setting connection string keywords. Table 5-10 details the connection string keywords available for altering connection pooling activities.

Handling Connection Errors

When SQL Server returns a warning or an error, the .NET Framework Data Provider for SQL Server creates and throws a SqlException that you can catch in your application to deal with the problem. When SqlException is thrown, inspect the SqlException.Errors property to access the collection of errors that are returned from the SQL server. The SqlException.Errors property is a SqlErrorCollectíon class (a collection of SqlError classes) that always contains at least one SqlError object.

MORE INFO SQL Server errors

SqlConnection will remain open for messages with a severity level of 19 and below, but it will typically close automatically when the severity is 20 or greater.

Summary

  • Connection pooling is enabled by default.
  • Connection pooling options are set in the connection string except for the ODBC provider, which uses the ODBC Data Source Administrator dialog box in Windows.
  • A SqlException object is created when an error is detected on the SQL server.
  • Every instance of a SqlException exception contains at least one SqlError warning that contains the actual error information from the server.
  • Windows Authentication (also called Integrated Security) is the suggested method for connecting to data securely.
  • Store connection strings that contain sensitive information in the application configuration file and encrypt all settings that contain confidential information.
Uncategorized

PMBOK, Project Management/Gestión de proyectos

El Project Management Institute (PMI) es una organización que intenta establecer un orden y unos criterios estándares para la gestión de proyectos. Con esa finalidad, PMI mantiene el libro Project Management Book of Knowledge (PMBOK) donde se establecen todo un conjunto de herramientas y buenas prácticas que todo jefe de proyecto debe conocer y aplicar.

En contraposición a otras metodologías (p.ej. las metodologías ágiles como Scrum), PMBOK se encuentra orientado a una gestión predictiva de los proyectos. PMBOK presenta diversas fases de un proyecto de forma lineal (una vez superada una fase, no se volverá a ella), donde la necesidad/solución, el alcance y la planificación (p.ej. coste y duración de cada una de las tareas a realizar) se establece en las fases iniciales (de ahí que sea denominada gestión predictiva).

Por tanto, podríamos considerar PMBOK como perteneciente a la rama más clásica de la gestión de proyectos (al igual que el estándar complementario PRINCE2, popular en UK). No obstante, este hecho no implica que parte de las herramientas que ofrece no puedan ser utilizadas en combinación con otras metodologías más ágiles y flexibles.

Antes de empezar en materia es necesario establecer la definición y las características de un proyecto según el PMBOK:

  • Un proyecto intenta dar solución a un problema (cubrir una necesidad).
  • Es temporal
  • Es único en el tiempo y no repetible bajo las mismas circunstancias
  • Conlleva incertidumbre
  • Consume recursos: Tiempo, dinero, materiales y trabajo.

Los proyectos disponen de su propio ciclo de vida, el cual se divide en las siguientes fases:

  • Inicio: Se identifica la necesidad y se cuestiona si es posible llevar a cabo el proyecto.
  • Planificación:
    • Se desarrolla una solución en un mayor detalle.
    • Definición de tareas, calendario.
    • Estimación de costes en tiempo y dinero.
    • Se vuelve a plantear si es factible el proyecto.
  • Ejecución: Monitorización y ajustes a la planificación.
  • Cierre: Se comprueba si el proyecto satisface la necesidad a cubrir

Todas estas fases, implican los siguientes procesos generales:

  • Identificar el problema o la oportunidad
  • Identificar y definir la solución idónea
  • Identificar las tareas y los recursos necesarios.
  • Preparar el calendario y la obtención de recursos
  • Estimar el coste del proyecto y preparar un presupuesto
  • Analizar los riesgos y establecer relaciones con los stakeholders (toda persona que tenga un interés directo o indirecto en el proyecto): Gestión del riesgo periódico
  • Mantener el control y la comunicación en el nivel adecuado durante la ejecución: Reuniones periódicas para detectar y comunicar desviaciones
  • Gestionar un cierre satisfactorio
    • Punch list: listado de tareas para poder acabar el proyecto.
    • Los miembros del equipo tienden a dispersarse dado que el proyecto se encuentra casi cerrado.

No obstante, un proyecto puede ser visto desde otras perspectivas, como por ejemplo desde el punto de vista de las relaciones interpersonales:

  • Motivar al equipo: Crear el clima adecuado
    • Invertir tiempo en explicar como cada función contribuye al proyecto
    • Invertir tiempo en las reuniones para destacar contribuciones positivas de los miembros.
    • Confiar en el trabajo delegado
    • Asignar objetivos a los individuos y permitir que ellos escojan el camino.
    • Reconocer los esfuerzos que van más allá de lo solicitado.
    • Predicar con el ejemplo
  • Gestionar la diversidad
    • Identificar posibles objetivos personales para minimizarlos o convertirlos en objetivos grupales.
    • Buscar la cohesión del grupo (armonizar costumbres, culturas, etc.).

A su vez, aparte de los procesos internos propios de la gestión del proyecto y las relaciones interpersonales, los proyectos se gestan y ejecutan dentro del ámbito de una organización. Actualmente podemos encontrar compañías cuyo negocio principal es la ejecución de proyectos, por ejemplo en el sector de la Consultoría y la Auditoría. Ese es el escenario más positivo, dado que toda la organización se encuentra orientada hacia la gestión de proyectos.

Sin embargo, la mayoría de empresas tienen una estructura jerárquica constituida por departamentos con funciones diferenciadas y empleados que realizan tareas específicas, cuya movilidad tiende a ser más bien esporádica. En este tipo de escenario, la ejecución de un proyecto (que como se ha establecido es temporal) con empleados internos presenta un escenario más difícil de gestionar (esta es una de las razones por las que en multitud de ocasiones los proyectos son contratados a consultoras y auditoras externas).

Esta segunda situación puede aportar empleados con “Silo Mentality”, es decir, personas cuyos objetivos se encuentran ligados a su área funcional y no al proyecto al que han sido asignados; puede que no les importe el éxito del proyecto, dando preferencia a cumplir con sus obligaciones estables de su unidad departamental. Esta problemática puede bloquear la cooperación del equipo de trabajo (horitzontal thinking).

En definitiva, el grado de madurez de la organización y los procedimientos internos establecidos pueden contribuir al éxito o fracaso del proyecto:

  • Si la organización trabaja habitualmente en proyectos, se dispone de pautas ya definidas.
  • Vías de comunicación formal: Si son muy rígidas pueden entorpecer el trabajo
  • Vías de comunicación informal (amistades, conocidos, etc.): Si son muy frecuentes puede producir desinformación

Finalmente, PMBOK establece que para poder considerar que un proyecto ha sido exitoso se deben cumplir las siguientes expectativas:

  • Nivel I. Alcanzar los objetivos del proyecto
  • Nivel II. Eficiencia del proyecto.
    • Nivel de interrupción del trabajo del cliente.
    • Eficiencia en el uso de los recursos
    • Crecimiento del número de miembros del equipo
    • Gestión de conflictos
  • Nivel III. Utilidad para el usuario/cliente final.
    • ¿Ha sido solucionado el problema inicial?
    • ¿Se han incrementado los beneficios o se ha producido ahorro real?
    • ¿El usuario se encuentra actualmente usando el producto?
  • Nivel IV. Mejora organizacional: Aprender sobre la experiencia

Jefe de proyecto

Un jefe de proyectos o project manager tiene las siguientes responsabilidades:

  • El proyecto: Objetivos de coste, calendario, funcionalidad y calidad.
    • La organización
    • Retorno de la inversión.
  • Flujo de información: proporcionarla de forma proactiva, si un supervisor se sorprende de algún dato es que no hemos informado correctamente.
  • El equipo: Proporcionar feedback y reconocimiento.
  • Sobre él mismo: Crecimiento personal.

Por otra parte, el jefe del proyecto se enfrenta constantemente a retos entre los que se pueden encontrar los siguientes:

  • Responsabilidad versus Ausencia de autoridad
    • Alto nivel de responsabilidad.
    • Trabajo con personas sobre las que no existe una autoridad directa.
  • Objetivos no realistas
    • Es uno de los problemas más habituales.
    • Refuerza la idea de analizar y planificar correctamente el alcance del proyecto.
  • Orientación funcional
    • Las personas tenderá a centrarse en su área de conocimiento funcional.
    • Es más importante su área funcional que el proyecto dada su temporalidad.
  • Conflicto fundamental sobre la incertidumbre
    • Toma de decisiones rápidas con poca información.
    • Estimaciones de rango (e.g. costes)
    • Intentar hacer entender las dificultades de las estimaciones a los superiores y a los miembros del equipo.

Con la finalidad de afrontar exitosamente las responsabilidades y retos que presenta la gestión de proyectos, un jefe de proyectos debe mejorar de forma constante las siguientes habilidades:

  • Gestión del proyecto: Herramientas para la planificación y monitorización.
  • Relaciones interpersonales
    • Capacidad de liderazgo, negociación y delegación.
    • Capacidad comunicativa oral y escrita
    • Resolución de conflictos.
    • Habilidades para desarrollar el rol de mentor (coaching)
  • Conocimiento tecnológico
    • Conocimiento de la industria y de las áreas tecnológicas
    • Conocimiento del producto y/o procesos
    • Habilidades de diseño
  • Habilidades personales
    • Honestidad, integridad
    • Pensar globalmente
    • Alta tolerancia a la incertidumbre y a la ambigüedad
    • Persuasivo y asertivo
    • Abierto y accesible
    • Decisivo
    • Comercial. Capacidad para vender ideas o las propias virtudes del proyecto.
    • Profesor. Transmitir conocimiento a los miembros del equipo.

Definición del proyecto

La definición del proyecto se encuentra constituida por las siguientes fases:

  • Fase I. Entender el problema o la oportunidad.
  • Fase II. Identificar la solución más optima
  • Fase III. Desarrollo de la solución y elaboración de un plan
  • Fase IV. Lanzamiento del proyecto

Fase I. Entender el problema o la oportunidad.

Es fundamental identificar la necesidad real que el proyecto pretende cubrir. El trabajo se evaluará en función de si esta necesidad ha sido cubierta satisfactoriamente o no.

En primer lugar se requiere diferenciar entre necesidad y solución.

Una necesidad:

  • Describe el fin para el cliente
  • Especifica metas y objetivos
  • Deja abierta la pregunta de cómo hacerlo.
  • La respuesta al porque se esta haciendo debe apuntar a una justificación de negocio.

En cambio, una solución:

  • Describe los medios para el equipo
  • Especifica estrategias e ideas para conseguir las metas y objetivos.
  • Especifica cómo hacerlo.
  • La respuesta al porque se esta haciendo debe apuntar al requerimiento del cliente.
  • Preguntar para identificar la necesidad real puede hacer sentir incomodo a terceros por desconfiar de su criterio.

En base a estas definiciones, esta fase debe tener como output la generación del documento de requerimientos del proyecto, el cual no ofrece una solución sino que únicamente describe una necesidad. Este documento debe contener los siguientes apartados:

  • Descripción del problema o oportunidad
  • Impacto o efecto del problema
  • Identificar quien o que se encuentra afectado por el problema
  • Impacto de ignorar el problema
  • Situación deseada
  • Beneficios asociados a conseguir la situación deseada
  • Alineación con la estrategia de la organización
  • Conflicto de compatibilidades con otras áreas de la organización
  • Incertidumbres
  • Suposiciones clave
  • Limitaciones de la solución
  • Consideraciones del entorno
  • Información histórica de soporte

A partir de la recopilación de toda esta información, se requiere valorar nuevamente si merece la pena resolver el problema y determinar si existe una solución potencial.

Fase II. Identificar la solución más óptima

Con objeto de identificar soluciones que cubran la necesidad establecida se puede seguir el siguiente procedimiento:

  • Brainstorming grupal con miembros del futuro equipo de trabajo o stakeholders.
  • Comprobar en que grado satisfacen los planteamientos del documento de requerimientos del proyecto.
  • Seleccionar entre 2 y 5 soluciones candidatas.

Para las soluciones candidatas seleccionadas conviene realizar un análisis detallado para identificar cual de ellas es la que mejor se adapta a la necesidad a cubrir e implica un coste asumible.

Análisis financiero (Costes vs Beneficios):

Para validar la viabilidad financiera del proyecto es necesario identificar los flujos de entrada de dinero que este puede generar, por ejemplo beneficios obtenidos por la implementación del proyecto (incremento en ventas, reducción en costes, etc…) y los gastos que representa la puesta en marcha y gestión del proyecto.

Por tanto, estimando la magnitud de los diferentes cash flows y calculando los 4 indicadores básicos, podemos identificar que proyecto nos aporta una mayor rentabilidad financiera.

Conviene estudiar al menos los siguiente indicadores:

  • Net Present Value (NPV). Determina cuanto dinero va a generar el proyecto teniendo en cuenta el valor del dinero en el tiempo.
  • Internal Rate of Return (IRR). Determina la rentabilidad de la inversión.
  • Payback period. Determina cuando se recuperará la inversión (NPV = 0).
  • Cash hole. Determina la máxima inversión necesaria.

Análisis no financiero (Modelo de puntuación de factores ponderados – Decision matrix)

El análisis mediante el modelo de puntuación de factores ponderados (“Decision Matrix”) se inicia mediante la elaboración de un listado de atributos a valorar. Para cada uno de ellos se establece una ponderación y se asignan puntuaciones que denoten el nivel de cumplimiento de cada una de las soluciones candidatas:

Ventajas:

  • Permite el uso de diversos datos, incluidos los financieros.
  • Permite la implicación de gerencia y el análisis de sensibilidad.

Desventajas:

  • Proceso altamente subjetivo.
  • Muestra el atractivo del proyecto pero no representa una justificación de negocio.

Aparte de los análisis financieros o de matrices, la decisión final sobre que solución escoger se puede basar en el uso de otras herramientas:

  • Estudios de mercado
  • Pruebas piloto. Prueba en área limitada.
  • Prototyping. Construcción de una pequeña parte del proyecto para validar las correctas predicciones.
  • Simulación por ordenador.

En definitiva, los análisis efectuados no solo ayudaran a elegir una solución sino que también permitirán determinar si las soluciones son viables y si vale la pena continuar con el proyecto.

Próximo Post: las demás fases.

Uncategorized

Microsoft Solutions Framework

Microsoft Solution Framework es una metodología para el desarrollo de software para la planificación, desarrollo y gestión de proyectos tecnológicos. Se centra en el modelo de procesos y de equipo dejando los demás aspectos en segundo plano.

MSF se compone de varios modelos que se encargan de cada una de las fases del desarrollo de un proyecto: modelo de arquitectura del proyecto, modelo de equipo, modelo de procesos, modelo de gestión de riesgo, modelo de diseño de procesos y modelo de aplicación.

Fase 1 Estrategia y alcance:

  • Elaboración y aprobación del documento de alcances del proyecto.
  • Formación del equipo de trabajo y distribución de competencias y responsabilidades.
  • Elaboración del plan de trabajo.
  • Elaboración de la matriz de riesgos y plan de contingencia.

Fase 2 Planificación y prueba de concepto: 

  • Documento de planificación y diseño de arquitectura.
  • Documento de plan de laboratorio (son las pruebas de conceptos)

Fase 3 Estabilización

  • Selección del entorno de pruebas piloto.
  • Gestión de incidencias.
  • Revisión de la documentación final de la arquitectura.
  • Elaboración de plan de despliegue.
  • Elaboración del plan de formación.

Fase 4 Despliegue

  • Registro de mejoras y sugerencias.
  • Revisión de las guías y manuales de usuario
  • Entrega del proyecto y cierre del mismo

msf2

 

Otras características del MSF

Fases y definiciones del proyecto presentadas por el MSF:

  • Prever: Identificar el objetivo del proyecto. Crear documento con ámbito del proyecto y declaración de objetivos.
  • Planear: Desarrollar especificaciones funcionales. Aquí se desarrolla el diseño del proyecto que incluye diseños conceptuales, lógicos y físicos.
  • Desarrollo: Crear un laboratorio de pruebas para examinar como funcionan las soluciones en el mundo real.
  • Implementación: Se alcanzan los objetivos indicados en la fase de desarrollo.

Una forma de llevar paso por paso está metodología es a través de las herramientas de Microsoft como es el caso de Visual Studio. MSF es flexible ya que permite agregar y extender nuevas características.

MSF no es rígido ya que sabe que no existe una sola estructura que se pueda acoplar a todo los tipos de proyectos.

Es una metodología integrada, ya que combina muchos elementos y características y además, es una metodología productiva, ya que incrementa la productividad de todo el equipo de trabajo.

MSF es una metodología de mejores prácticas para el desarrollo del software. Los modelos de procesos que maneja son ágiles y formales.

Los modelos de procesos ágiles fueron desarrollado por un conjunto de profesionales conocidos como la Agile Alliance, quienes rechazaron la noción de que los procesos son más importantes que la gente.

Se enfoca más en las habilidades y cualidades de las personas que en la eficacia de los modelos de procesos.

MSF está basado en mejores prácticas del mundo real, basado en las experiencias de Microsoft.

Algunas capacidades de extensión del MSF son: guía de procesos, estructura de iteración, vistas de criterio de entrada y salidas, definición de tipos y reglas de elementos de trabajo, políticas de revisión de código, seguridad de grupos, plantillas de documentos, reportes y portales.

Introducción al riesgo

  • En el desarrollo de software existe una gran cantidad de cosas desconocidas.
  • Principios de fundación de riesgos:
    • Mantenerse ágil, esperando cambios.
    • Comunicaciones abiertas
    • Aprender de todas las experiencias
    • Responsabilidad compartida, contabilidad clara
  • El riesgo está inherentemente en cualquier proyecto de procesos.
  • La administración de riesgo proactivo es más eficiente:
    • Anticipar problemas antes de que puedan ocurrir
    • Tener un plan de resolución de problemas antes de que éstos ocurran
    • Usar procesos repetibles, estructurados y conocidos para la resolución de problemas
    • Usar medidas preventivas cuando sea posible.

Pasos para el proceso de manejo de riesgo del MSF

La administración de riesgos es una de las actividades principales del MSF. Tiene las siguientes características:

  • Es comprensivo, direccionando todo los elementos del proyecto: personas, procesos y elementos tecnológicos
  • Incorpora procesos reproducibles, sistemático, y paso a paso de la administración de riesgos

Prácticas recomendadas para el modelo de procesos del MSF

  • Concentrarse en la creatividad por medio de características envolventes y restricción de recursos.
  • Establecer calendarios fijados.
  • Calendarización para futuro incierto.
  • Uso de equipos de trabajo pequeños, trabajando en paralelo, con puntos de sincronización frecuentes.
  • Uso de prototipos
  • Uso de implementaciones frecuentes y pruebas rápidas

El establecimiento de equipos de trabajos es una de las partes que mayor importancia tiene cuando se desarrolla un proyecto, ya que si se realiza en forma equivocada los integrantes del proyecto no podrán colaborar de buena manera y hacerlo bien.

Miembros de equipos sinergizados:

  • Estar preparado para hacer comisiones de otros.
  • Determinar claramente las comisiones que los miembros del equipo entienden.
  • Hacer razonable cada esfuerzo para entregar las comisiones.
  • Comunicar honestamente cuando las comisiones puedan tener riesgo.

Algunas sugerencias para el manejo de riesgo:

  • Sinergizar el equipo para conocer las comisiones que le han sido asignadas.
  • Centrarse en el valor del negocio
  • Mantener una visión compartida del proyecto

El modelo de equipo del MSF:

  • Los equipos motivados son más eficientes.
  • Clarificar la visión del equipo.
  • Construir una identidad de equipo, usando nombres códigos a los proyectos.
  • Gastar tiempo en eventos sociales en el equipo.
  • Calendarizar actividades para discutir temas en equipo
  • Asegurarse que las metas personales no interfieran en el desarrollo del proyecto.
  • Celebrar el éxito
  • Equipos multidisciplinarios y pequeños.
  • Trabajo en conjunto

Principios de un equipo exitoso

  • Pueden trabajar independientemente.
  • Demostrar las habilidades del equipo.
  • Poseer habilidades específicas para resolver el problema.
  • Pueden compartir conocimiento con la organización
  • Pueden desarrollar efectivamente métodos de trabajo.

Equipos de proyecto de Microsoft

  • Vista del modelo de equipo
  • Administración del producto
  • Administración del programa
  • Desarrollo
  • Pruebas
  • Experiencias del usuario
  • Administrador de versiones

Roles y responsabilidades

La característica principal de cualquier modelo de equipo consiste en asignar a cada uno de los intregrantes del equipo de algunas actividades

Rol del administrador de producto

  • Marketing:
    • Manejar marketing y relaciones públicas.
    • Diferenciar el proyecto del resto de los competidores.
    • Poner la distribución en formas fácilmente accessible para los clientes.
    • Proveer soporte a los clientes.
  • Valor del negocio:
    • Definir y mantener la justificación para el proyecto.
    • Definir y medir el valor del negocio del usuario.
  • Avocado al cliente:
    • Manejar una vision y solución del proyecto compartida.
    • Manejar las espectativas del cliente y las comunicaciones
  • Planeación del producto:
    • Analizar y priorizar los requerimientos de los clientes
    • Mejorar el análisis e inteligencia de la investigación de mercado y la demanda del Mercado.
    • Determinar las métricas del negocio y los criterios de éxito
    • Identificar múltiples versiones del plan de entrega.
  • Agrupación de roles en la administración de proyectos

Administración del proyecto:

  • Seguimiento y manejo del presupuesto.
  • Gestionar la calendarización del proyecto maestro.
  • Manejar el proceso de gestión de riesgos
  • Facilitar la comunicación y negociación dentro del equipo.
  • Seguimiento del progreso y gestión del estado del reporte del estado del proyecto.
  • Manejar la relocalización de recursos

Arquitectura de solución

  • Manejar todas los posibles diseños de solución.
  • Manejar las especificaciones funcionales.
  • Manejar el alcance de la solución y acuerdos de decisión críticos.
  • Mejora de procesos:
    • Definir la calidad de los procesos
    • Definir y recomendar mejoras

Servicios administrativos

  • Implementar los procesos de administración de proyecto y el soporte de liderazgo al equipo de trabajo.
  • Proveer un rango de servicios de administración para soportar eficientemente equipos de trabajo.
  • Actividades de la arquitectura de solución incluyen:
    • Crear el concepto de solución y revisar el plan de requerimientos.
    • Captura de requerimientos, manejo de procesos de diseño lógico.
    • Manejo de cambios de la especificación funcional.
    • Proveer actualizaciones al equipo de arquitectura empresarial.

Desarrollo de agrupación de roles

Área funcional de consulta de tecnología:

  • Servir al equipo como consultor de tecnología.
  • Evaluar y validar tecnologías
  • Participar activamente en la creación y validación de las especificaciones funcionales.
  • Contribuir para definir estándares de desarrollo para la organización.

Arquitectura de implementación y diseño funcional de áreas

  • Hacer un mapa de la arquitectura de la empresa para la implementación de la arquitectura de solución proveyendo detalles específicos de la solución para las vistas de la arquitectura de datos, tecnología y aplicación.
  • Implementar el diseño lógico y físico de la solución.

Área de desarrollo funcional de aplicaciones

  • Características de código para conocer especificaciones de diseño.
  • Revisión de conductas de código durante el desarrollo y compartición de conocimiento y experiencia.
  • Llevar acabo pruebas de unidad así como un plan de pruebas.

Área de desarrollo funcional de infraestructura

  • Desarrollo de características que conozcan el diseño de especificaciones.
  • Revisión de conductas de código durante el desarrollo y compartición de conocimientos y experiencias.
  • Llevar acabo pruebas de unidad así como un plan de pruebas.
  • Desarrollo de scripts para automatizar despliegue.
  • Desarrollo de documentación de despliegue

Agrupación de roles de pruebas

  • Planeación de pruebas
  • Desarrollo de pruebas a través del plan.
  • Participar en la configuración de la barra de calidad.
  • Desarrollo de especificación de pruebas.

Ingeniería de pruebas

  • Desarrollo y mantenimiento automatizado de casos de pruebas, herramientas y scripts.
  • Conducción de pruebas adecuadamente para determinar el estado del producto desarrollado.
  • Administración del proceso de construcción
  • Reporte de pruebas
    • Proveer al equipo con datos relacionados para la calidad del producto
    • Seguimiento de todos los errores y comunicarlos para su solución antes de sacar el producto al mercado

Agrupación de roles de experiencia del usuario

  • Internalización
  • Comunicaciones tecnológicas: diseño y desarrollo de documentación para sistemas de soporte manuales de ayuda, artículos KB (base de conocimiento), Documentación de ayuda y asistencias.
  • Entrenamiento
  • Usabilidad: analizar y priorizar los requerimientos de usuarios, proveer retroalimentación y entradas para el diseño de solución, desarrollo de escenario de uso y casos de uso.
  • Diseño de gráficos: diseño de la interfaz de usuario.
  • Accesibilidad: la incorporación de secciones de accesibilidad dentro de cada característica de especificación, integrando información de accesibilidad en cada sección de ayuda, asegurarse que la documentación es accesible y completa, asegurarse que la documentación está en formatos accesibles.
  • Globalización
  • Localización

Agrupación de roles de la administración de versiones

  • Actuar como mediador entre el desarrollo de proyectos y los grupos de operación.
  • Manejar la selección de herramientas para actividades de entrega y manejo de automatización optimizada.
  • Configurar un criterio operacional para la entrega de versiones.
  • Participación en diseño, concentrándose en la manejabilidad, soportabilidad y despliegue.

Infraestructura

  • Planeación de infraestructura empresarial.
  • Ambiente físico de configuración usado y planeación a través de la geografía (centro de datos, laboratorios, oficinas).
  • Proveer al equipo con políticas y procedimientos para concientizar estándares y manejos de infraestructura.
  • Proveer infraestructura de servicios al equipo de MSF (construcción de servicios, imágenes estándar, instalación de software).
  • Gestionar la procuración de hardware/software para el equipo.
  • Construcción de pruebas que sirvan de espejo en los ambientes de producción.

Soporte

  • Proveer soporte al cliente de TI.
  • Soporte para los negocios por medio de comités.
  • Proveer resolución a problemas e incidentes; respuestas rápidas a las peticiones de los usuarios.
  • Dar retroalimentación del desarrollo y diseño al equipo.
  • Desarrollar procedimientos de recuperación ante las fallas.

Operaciones

  • Control de configuración de sistemas y cuentas, administración de cuentas de usuarios y permisos.
  • Mensajes, base de datos, operaciones de telecomunicaciones y redes.
  • Administración del sistema, procesamiento de lotes
  • Administración del firewall, administración de seguridad
  • Servicios de aplicaciones
  • Servicios de integración de hosts
  • Servicio de operaciones de directorio

Administración de entregas comerciales

  • Código de registro de productos, proceso de verificación de registros.
  • Administración de licencias
  • Empaquetado
  • Administración del canal de distribución
  • Publicaciones electrónicas e impresas

Uncategorized

La Competitividad Empresarial

competitividad-empresarial

 Concepto competitividad. Matices.

La AECA define competitividad como la capacidad de una organización para obtener y mantener sistemáticamente unas ventajas comparativas que le permiten alcanzar, sostener y mejorar una determinada posición en el entorno socioeconómico en que actúa.

La OCEDE la define como el grado en que bajo condiciones de libre mercado, una país puede producir bienes y servicios, que superen el examen de la competencia internacional, y que permite mantener el crecimiento sostenido de la renta nacional. Como matices principales tenemos:

1.       Concepto ambiguo por la multiplicidad de factores.

2.       Se puede aplicar a cualquier organización.

3.       Se requiere un esfuerzo permanente del equipo directivo.

Obstáculos de los agentes.

La competitividad es una referencia de la capacidad de respuesta y de anticipación de la organización ante las demandas y necesidades del entorno. Los colectivos son:

1.       Accionistas

2.       Directivos

3.       Empleados

4.       Acreedores

Evaluación competitividad de la organización

Como indicadores más representativos tenemos:

1.       Posicionamiento en el sector

2.       Innovación tecnológica y métodos de gestión.

3.       Eficiencia en los costes de fabricación y utilización de los RRHH.

Cultura organizativa y competitividad. Aspectos de deterioro.

La cultura de la empresa es el conjunto de valores, normas y tradiciones que determinan su forma de ser. El deterioro de la misma se encuentra:

1.       Resistencia al cambio

2.       Espíritu pesimista

3.       Enfrentamiento interpersonales e interdepartamentales

Tipos de crisis en la competitividad.

1.       Crisis estratégica: Incumple objetivos. No se adapta al entrono. Fracaso de mercado.

2.       Crisis de objetos y resultados: Caída de la rentabilidad y perdida de cuota de mercado.

3.       Crisis de supervivencia: Amenaza de cierre de la empresa.

Parques Científicos y Tecnológicos. Riesgos. Rasgos. Papel de la administración.headizqch - Competitividad Empresarila

Los PCT son uno de los múltiples instrumentos que se éstan utilizando para fomentar la innovación y competitividad de las empresas y territorios. Se basan en el intercambio de conocimientos, ideas y cooperación, entre el entorno institucional, académico y empresarial. La Administración Pública ha sido decisiva para formar las sinergias necesarias entre las empresas, centros de investigación y universidades. El estimulo empresarial se ha realizado desde los poderes públicos.

Como principales rasgos tenemos:

1.       Pequeñas y medianas empresas.

2.       Generación de empleo.

3.       Imagen de prestigio.

4.       Instalaciones de I+D que impulsan implantación de empresas.

5.       Tecnologías de información y comunicación.

6.       Participación de las Universidades.

LA INNOVACIÓN: FACTOR DE SUPERVIVENCIA.

Innovación y supervivencia. Tipos de innovación.

La innovación es el proceso que consiste en aplicar nuevas ideas para resolver problemas. El objetivo de supervivencia precisa que la empresa sea capaz de impulsar sus actividades y adaptarse a los cambios externos e internos.

Los tipos de innovación según su naturaleza:

1.       Innovación tecnológica (tanto en productos como en procesos).

2.       Innovación en métodos de gestión.

3.       Innovación social. 

Condiciones para la innovación. Funciones del equipo multidisciplinar.

1.       La dirección asume riesgos

2.       Participación de todos los miembros de la organización

3.       Incentivación de la creatividad

4.       Responsabilidad compartida

La función de innovación ha de ser distribuida por toda la organización. Las funciones:

1.       I+D

2.       Producción

3.       Marketing

4.       Compras

5.       Ingeniería de diseño

Modalidades de creatividad. Actitud de la dirección.

Tenemos tres clases de creatividad:

1.       Normativa: solución de problemas.

2.       Exploratoria: descubrir nuevas aplicaciones a las innovaciones.

3.       Aleatoria: recurre a la ingeniosidad de los empleados.

Una actitud poco receptiva por parte de la dirección en materia de creatividad producirá en la empresa un efecto de anquilosamiento por falta de regeneración.

Adhocracia. Puntos que la compone.

La adhocracia es una estructura simple, flexible, con unos sistemas de comunicación fluidos, constituida por equipos de expertos para desarrollar sistemas de innovación. Esta compuesta:

1.       Alta dirección

2.       Línea intermedia

3.       Empleados

4.       Analistas de planificación y control

5.       Staff de apoyo

Riesgos de la innovación

Los riesgos que existen cuando se realizan actividades de innovación son:

1.       Desconocimiento tecnológico

2.       Disponibilidad de recursos económicos

3.       Falta de habilidad gerencial para afrontar la innovación

GESTIÓN DE LA INNOVACIÓN

Gestión de la innovación. Funciones. Evolución histórica.

La gestión de la innovación es la capacidad de reunir, organizar, y optimizar, de una forma eficiente y eficaz, los recursos tecnológicos disponibles, con miras a la implantación y cumplimiento de la estrategia formulada por la dirección de la empresa.

La estrategia para la innovación es aquella parte de la estrategia corporativa que se refiere a los activos de la compañía relacionados con la innovación-tecnológica.

Las funciones a desarrollar para la gestión de la innovación:

1.       Optimizar los recursos tecnológicos disponibles plan-competitividad

2.       Enriquecer el patrimonio tecnológico

3.       Proteger patrimonio tecnológico

4.       Inventar los recursos tecnológicos

5.       Evaluar el entorno tecnológico de la empresa

6.       Vigilar el comportamiento innovador de los competidores directos

La evolución histórica se expone:

1.       Enfoque intuitivo: El I+d se consideraba como una partida más del presupuesto. No hay comunicación entre los distintos expertos funcionales.

2.       Enfoque sistemático: Se definen objetivos y unos presupuestos acordes a estos.

3.       Enfoque estratégico: El departamento de I+D se integra en el plan estratégico de la empresa. La asignación de recursos financieros se hace de forma flexible adaptándose a las necesidades.

Riesgo de estrategias de diversificación no relacionada con sus competencias genéricas

1.       La empresa entra en un sector desconocido para ella, necesita de un periodo de aprendizaje.

2.       No aprovecha las sinergias

3.       Ausencia de dominio tecnológico

Cuanto mayor sea el dominio tecnológico y mayores sea las habilidades para encontrar nuevas aplicaciones a sus competencias, mayores serán las probabilidades de su supervivencia. Esta valoración nos lleva a que los bienes y servicios desarrollados son producto de una experiencia adquirida.

Cambios necesarios para potencias la creatividad

1.       Inversiones para potenciar la creatividad

2.       Fomentar cultura donde las personas expresen sus ideas

3.       Permanecer abiertos para acceder a fuente externas de información

4.       Actividades para abrir la mente de los empleados. Motivar la utilización de la información.

Para ello debemos de intensificar esfuerzos en la dirección de la organización y fomentar la comunicación.

Reducción del tiempo de lanzamiento

La reducción en el tiempo de lanzamiento puede conseguirse acortando el calendario de planificación de desarrollo. Esto se consigue introduciendo procesos paralelos mediante la ingeniería concurrente. Los ahorros conseguidos son del 10 al 20 %. En lo que a retrasos se refiere se consigue ahorros del 50%.

Reducción de los costes de lanzamiento

Los costes de desarrollo se puede reducir desde dos alternativas:

1.       Reducir los costes de materiales

2.       Disminuir las horas de ingeniería, acortando el tiempo de lanzamiento, o el número de ingeniero.

Se aconseja una combinación de ambas, acortando el tiempo de lanzamiento. No se aconseja reducir el número de ingenieros, ya que reducimos la creatividad de la empresa.

EL PROCESO DE LA INNOVACIÓN

Diferencias entre invención e innovación

Una invención o invento supone la solución a un problema técnico. La innovación es un asunto social, y se basa en imponer en práctica una nueva tecnología, que interactúa con el entorno.

Tipos de innovaciones

A) Grado de novedad: grey_business_group

1.       Radical: Presenta un cambio total en los productos, servicios, procesos, o tecnologías.

2.       Incremental: Mejora de un producto, servicio o proceso. Introduce cambios menores.

B) Componentes:

1.       Modular: Modificar alguno de los componentes, manteniendo su estructura.

2.       Arquitectónica: Utiliza los mismos componentes conocidos, modificando la estructura.

Beneficios de la innovación tecnológica como proceso

El proceso de innovación tecnológico se define como el conjunto de las etapas que conducen al lanzamiento con éxito en el mercado de nuevos productos y servicios, utilizando nuevos procesos técnicos. Como beneficios:

1.       Renovación y ampliación de la gama de productos y servicios.

2.       Renovación y ampliación de los procesos productivos

3.       Cambios en la organización y en la gestión

Limitaciones de los modelos lineales de procesos de innovación

El modelo lineal considera la innovación tecnológica como un proceso secuencial y ordenado que, a partir del conocimiento científico, sigue el desarrollo, producción, comercialización de producto o servicio. Tiene como limitaciones:

1.       Innovación como proceso racional

2.       Ciencia y tecnología secuencial

3.       La tecnología siempre sigue a la ciencia

4.       Ignora de los conocimientos propios de la tecnología

Modelo integrado de desarrollo proceso innovación.

A partir de los años 90 se considera que el tiempo de desarrollo es una variable crítica del proceso que hay que tratar de optimizar de manera continua. La innovación de procesos se trata mediante procesos no secuenciales, sino solapados, o incluso concurrentes.

Difusión de la innovación. Características relevantes.

Es un proceso por el que una innovación se comunica a través de ciertos canales, a lo largo del tiempo, y entre los miembros de un sistema social. Como características:

1.       Ventaja relativa: Es el grado en que percibe la innovación como superior al proceso o producto que reemplaza. Las personas para adoptar la innovación ha de percibir con claridad los beneficios conómicos o sociales de su implantación.

2.       Compatibilidad: La innovación es consecuencia con los valores y practicas existentes. Cuanto mayor compatibilidad mayor posibilidad de éxito.

Tres vías a través de las cuáles se intensifiquen el proceso de difusión de la innovación20423a

1.       Precio

2.       Alcanzar un estándar

3.       Rivalidad

GESTIÓN DEL CONOCIMIENTO

Gestión del conocimiento.  Aspectos fundamentales. Mentoring.

La gestión del conocimiento consiste en un proceso sistemático de búsqueda, selección, organización, filtrado, canalización, y aplicación de la información disponible en la empresa. Esta función permite un aumento de la eficiencia, ya que los problemas se afrontan con soluciones más apropiadas. Los aspectos fundamentales son:

1.       Cultura

2.       Sistemas de incentivos

3.       Sistemas de información

4.       Mentoring

El Mentoring es el más importante, ya que el conocimiento tácito tiene un gran valor, y es difícil su almacenamiento. El Mentoring como la relación entre dos empleados de la misma empresa, de distinto nivel jerárquico, cuya relación se basa en la ayuda al desarrollo profesional y personal, por parte del empleado de

mayor nivel a de menor nivel. De esta manera el pupilo puede en cualquier momento sustituir al mentor en sus funciones. Tiene como ventajas:

1.       Mejora la comunicación

2.       Mejora los resultados globales

3.       Fidelización de los empleados

4.       Mejora el conocimiento de los empleados.

Sistema ERP. Evolución histórica. Estructura. Ventajas e inconvenientes.

Los sistemas ERP son sistemas multifunción que engloban varias actividades tales como resultados financieros, adquisición, ventas, producción, o recursos humanos. Son sistemas integrados de información. Las primeras aplicaciones estaban destinadas fundamentalmente a la generación de nóminas o contabilidad.

Mas adelante aparecen sistemas para determinar el cuando y cuanto de las necesidades de material, llamados MRP. La inclusión de funciones de proceso de pedidos o costes de producción da lugar al MRP II. Desemboca en el sistema ERP.

El ERP incluye módulos integrados de contabilidad, finanzas, ventas, distribución, recursos humanos, etc. Tiene como ventajas del ERP:

1.       Simplificación y ajustes en toda la empresa

2.       Reduce el costo de mantenimiento de la información euskadi2015

3.       Fuerza la integración de los sistemas

4.       Minimiza los costes de implantación de procesos

Los inconvenientes del ERP:

1.       Implantación muy costosa

2.       Instalación lenta

3.       Aumento en los costes de tecnología de información.

Uncategorized

Preparación final y Go-Live

  • Realizar la formación del usuario y administrador. preparacion final
  • Ajuste final del sistema SAP Business One.
  • Compleción de las pruebas del sistema final.
  • Realización de los ajustes necesarios para resolver los asuntos pendientes importantes.
  • Compleción de las actividades de transición

Preparación final: Documentación

  • Lista de verificación para la transición
  • Lista de verificación para Go-Live
  • Log de modificaciones
  • Log de emisión

La Lista de verificación para la transición y la Lista de verificación para Go-Live son documentos exclusivos de la Preparación final (fase 4) de SAP Business One Accelerated Implementation Program. El Log de modificaciones se utiliza para esta fase y la fase de Realización del proyecto. El Log de emisión se utiliza para esta fase, así como para las fases de Realización del proyecto y Go-Live y soporte.

Los documentos adicionales para la fase Preparación final, son también "documentos adicionales" para todas las fases de la metodología e incluyen:

  • Agenda de reunión
  • Acta de reunión
  • Project Plan
  • Aceptación de fase del proyecto

Lista de verificación para Go-Live

  • Operatividad del sistema SAP Business One
  • Gestión de proyectos
  • Test final de integración
  • Necesidades delta
  • Gestión de sistemas
  • Operatividad del sistema (producción)
  • Administración del sistema
  • Disponibilidad de la empresa
  • Disponibilidad de los usuarios finales
  • Documentación
  • Plan de soporte de la producción
  • Operatividad de los datos
  • Transición
  • Migración de datos

La finalidad de esta lista de verificación es documentar que se ha completado la preparación final para la entrada en productivo. Por tanto, todas las comprobaciones se deben haber completados (respondido con "Sí").

Operatividad del sistema SAP Business One

Verifique que todas las acciones necesarias para la configuración adecuada del sistema SAP Business One de acuerdo con el blueprint se hayan llevado a cabo y probado en el entorno productivo.

Disponibilidad de la empresa

Confirmar que los usuarios finales y el personal de soporte del sistema están preparados para la entrada en productivo.

Operatividad de los datos

Confirmar que todos los datos se han migrado adecuadamente, tal como se acordó en el blueprint, y que están disponibles en el sistema nuevo.

Preparación final: Recomendaciones acerca de las mejores prácticas

  • Comunicar la planificación de la formación y transición a todos los clientes con una notificación oficial por escrito
  • Utilizar el e-learning de SAP Business One en las sesiones de formación, calidad y valoración
  • Por lo que se refiere a los materiales de formación, se deben utilizar los materiales para el aula de SAP Business One disponibles en SAP Channel Partner Portal
  • Se debe permitir que los usuarios trabajen individualmente en el sistema SAP Business One durante la formación

Go-Live y soporte

  • Establecer el soporte de producción.
  • Supervisar las transacciones del sistema. Go Live Soporte
  • Optimizar el rendimiento completo del sistema.

Go-Live y soporte: Recomendaciones acerca de las mejores prácticas

  • Realizar el traspaso de las responsabilidades de administración y de soporte paso a paso, y documentar el traspaso final.
  • Involucrar desde el inicio a la organización local de SAP, en caso de que se deben tratar cuestiones relacionadas con la implementación.
  • Involucrar al responsable de cuentas de SAP Business One, así como al comité de dirección del cliente (si es necesario) en el cierre del proyecto y en la "Conferencia de optimización y revisión"
  • Programar la "Conferencia de optimización y revisión" de cuatro a seis semanas después de la reunión de cierre del proyecto

Opciones para Soporte al clienteOpc Soporte Cliente

Para mantener un servicio al cliente de elevada calidad y consistente, SAP requiere que los interlocutores seleccionen diferentes opciones para proporcionar soporte a sus clientes.

Los interlocutores establecen su propia organización de soporte con un support desk con todos los empleados necesarios y con experiencia. Los interlocutores pueden utilizar la infraestructura del Portal de PYMEs. En este escenario, el cliente llama a la línea permanente de atención al cliente del interlocutor o crea un mensaje de problema en el portal de cliente de SAP Business One que se envía a la organización de soporte del interlocutor. El interlocutor soluciona el problema o lo remite a SAP.

Para ayudar al interlocutor, SAP inicialmente ofrece hacerse cargo del suministro del soporte hasta que el interlocutor tenga cincuenta usuarios (la duración mínima de la oferta son 6 meses, no más de 12 meses tras haber firmado el contrato de interlocutor). En este caso, el cliente llama a la línea permanente de atención al cliente de SAP o introduce un mensaje de problema en el portal de cliente de SAP Business One que se envía directamente a SAP. Support Tools SBO 2007

El interlocutor puede elegir aceptar esta oferta o no.

La ventaja es que el interlocutor no tiene que hacerse cargo del soporte durante el primer mes.

La desventaja es que los clientes se centran en SAP y el interlocutor no acumula conocimiento de soporte y del producto.

Para organizar el proceso de soporte correctamente, es indispensable que informe a SAP sobre su elección y sobre si desea modificar el procedimiento.

SAP Early Watch Alert: se recopilan datos del sistema (como release actual, planificación de copias de seguridad, etc.) y se genera un informe donde se pueden identificar posibles problemas.

Support Desk de SAP: se pueden crear mensajes de problema y enviarlos directamente a SAP desde SAP Business One.

Tratamiento de escalada: el campo global trata escaladas de proyectos y el equipo de soporte trata la escalada de mensajes.

SAP Business One Accelerated Implementation Program es una metodología que le ayuda durante la implementación y al operar SAP Business One a largo plazo para reducir los errores y otros problemas operativos.

Los requisitos previos para utilizar las herramientas de soporte de SAP 2007 son:

  • SAP Business One 2007 instalado
  • El add-on de las herramientas de soporte de SAP Business One instalado (las herramientas de soporte se incluyen en el producto central de SAP Business One en el Release 2007)
  • El cliente debe disponer de conexión de Internet para utilizar las herramientas de soporte
  • Licencia válida instalada
  • Se ha realizado el Customizing
    • Se ha actualizado el usuario para el Service Market Place
    • Se han actualizado las direcciones de correo electrónico

El Support Desk de SAP Business One está diseñado para facilitar el acceso al Portal de PYMEs a los clientes de SAP Business One. SAP propondrá soluciones automáticas a las preguntas que el cliente plantea a SAP Business One. Si la respuesta no se puede obtener de forma automática, el cliente podrá dirigir de manera sencilla su pregunta a SAP Support. Toda la información de contexto se adjunta automáticamente al mensaje y asegura un soporte eficiente por parte de SAP.

El flujo de trabajo del Support Desk de SAP Business One es el siguiente:

  • El cliente utiliza palabras clave para plantear su pregunta a SAP Business One.
  • El cliente envía la información al portal del cliente SAP Business One.
  • El portal del cliente SAP Business One propondrá de forma automática soluciones a sus solicitudes
  • Si el cliente todavía desea ponerse en contacto con el SAP Support, podrá hacerlo en un segundo paso. Toda la información de contexto se transmite automáticamente a SAP, lo que contribuye a facilitar un soporte rápido y eficiente.
  • El cliente puede verificar el status de su mensaje en la Carpeta de entrada de mensaje de servicio.

Debe tener un usuario S válido en el SAP Business One Customer Portal y una licencia válida para la instalación de SAP Business One.

SAP Early Watch Alert para SAP Business One
SAP EarlyWatch Alert es un servicio gratuito que permite la recopilación de información sobre hardware y software importante (como SO, versión SO, clase de servidor, clase de base de datos, etc.) por parte del cliente y de un análisis de dicha información por parte de SAP para evitar posibles problemas de hardware y software.

Antes de utilizar la herramienta SAP EarlyWatch Alert, deberán seguirse algunos pasos de customizing:

  • Proporcionar la información del usuario para el Service Market Place.
  • Proporcionar la dirección de correo electrónico a la que debe enviarse el informe.

El flujo de trabajo de SAP EarlyWatch Alert es el siguiente:

  • La recopilación de datos empieza de forma manual. Tras la recopilación de los datos, el cliente puede enviarlos a SAP Service Market Place.
  • Desde el Service Market Place, los datos se duplican en un sistema SAP para su análisis.
  • Tras la realización del análisis, se genera un informe y se envía al cliente y al interlocutor.

Puede ejecutar también Early Watch Alert automáticamente, tras haber elegido un día preferido del mes para ejecutar el informe Early Watch.

Para utilizar SAP EarlyWatch Alert, deberá tener un superusuario válido en SAP Business One y una licencia válida para la instalación de SAP Business One.

SAP Early Watch Alert

SAP Early Watch Alert

Si instala SAP Early Watch para sus clientes, deberá asegurarse de obtener una copia del informe por correo electrónico. Proporcione su dirección de correo electrónico al configurar SAP Early Watch Alert. En la primera página del informe, se puede ver fácilmente si el sistema de clientes funciona correctamente. Si detecta algún indicio de problema en el resumen, en el capítulo correspondiente del resumen tendrá que profundizar en él para analizarlo. Después, tendrá que realizar las acciones adecuadas para solucionar el problema en el sistema del cliente. En numerosas ocasiones, en el informe encontrará consejos acerca del método para resolver el problema.

Una buena interpretación del informe le ayudará a:

  • Analizar de forma proactiva su sistema SAP Business One, su sistema operativo y la base de datos.
  • Identificar posibles cuellos de botella en el rendimiento y le facilitará consejos para evitarlos
  • Asegurar un rendimiento óptimo del sistema SAP Business One, además de su buen funcionamiento y, todo ello, con el menor coste posible para el propietario.

El informe SAP Early Watch se divide en varios capítulos. Cada uno de ellos recibe una valoración total en forma de semáforo. En cada capítulo se encontrará una valoración más detallada sobre temas individuales, en los que un pequeño icono indicará la valoración.

  • Verde: Early Watch no ha detectado ningún problema grave.
  • Amarillo: Early Watch detecta problemas potenciales. Analice el informe y, en caso necesario, realice las acciones pertinentes.
  • Rojo: Early Watch ha detectado problemas graves, deberá analizar el problema inmediatamente y realizar las acciones necesarias para solventarlo.

platform

Uncategorized

Blueprint empresarial y Realización del proyecto

Blueprint empresarial

  • Realización de uno o más talleres para la recopilación de requisitos para definir y analizar procesos empresariales y requisitos funcionales a nivel individual.
  • Perfección de los objetivos iniciales del proyecto y revisión de la programación general del proyecto, en caso necesario.
  • Creación de un Blueprint empresarial que sirva como guía técnica y funcional durante las fases subsiguientes del proyecto de implementación de SAP Business One. 

Fase 2. Documento específico de la fase Blueprint empresarialblueprint empresarial

  1. Información básica del establecimiento de una empresa
  2. Parametrizaciones generales de la empresa
  3. Especificación de monedas
  4. Definición de los segmentos de cuentas de mayor y plan de cuentas
  5. Definición de la información bancaria
  6. Determinación de la cuenta de mayor por defecto para contabilización de operaciones
  7. Definición de almacenes
  8. Especificación de grupos de artículos
  9. Definición de indicadores de IVA
  10. Definición de las condiciones de pago
  11. Definición de información de la tarjeta de crédito para pagos recibidos del deudor
  12. Definición de información de la tarjeta de crédito para pagos empresariales efectuados
  13. Especificación de usuarios y contraseñas
  14. Especificación de territorios, grupos de comisiones y empleados del departamento de ventas
  15. Especificación de grupos de clientes
  16. Especificación de grupos de proveedores
  17. Especificación de fabricantes
  18. Especificación de clases de expedición
  19. Especificación de las parametrizaciones del documento inicial del sistema general

Blueprint empresarial: Recomendaciones acerca de las mejores prácticas

  • Realizar talleres tanto a nivel individual como en grupo para poder discutir los requisitos a nivel individual, así como las superposiciones y dependencias entre departmentos
  • Disponer de un sistema SAP Business One durante la realización de los talleres para poder demostrar cómo el sistema puede hacer frente a las necesidades empresariales
  • Utilizar el plan de cuentas del cliente, en lugar de crear un nuevo plan de cuentas ya que esto reducirá en gran medida los esfuerzos para llevar a cabo la migración de datos y la reconciliación de saldos pendientes
  • Comunicar y documentar que en la migración de datos se incluyen únicamente datos maestros del sistema existente a SAP Business One; si el cliente desea migrar los datos de movimientos históricos, difiera este proceso a un proyecto separado siguiendo la implementación inicial
  • Confirmar la documentación detallada de los requisitos en el Blueprint empresarial y enfatizar al cliente que incluso lo que pueden parecer pequeñas modificaciones en el alcance y/o requisitos pueden tener una repercusión importante en los costes, recursos y duración del proyecto
  • Asegurase de obtener la aprobación del cliente por lo que respecta al Blueprint empresarial

Realización del proyecto

  • Validar y actualizar la configuración y demostrar los procesos.
  • Alentar al cliente para que actualice las instrucciones de producción (procedimientos del proceso empresarial: PPE).
  • Realizar los tests de integración y de la unidad. 

Realización del proyecto: Documentación

  • Lista maestra de procesos empresariales (LMPE)
  • Guía de Change Management Communication Realizacion proyecto
  • Plan de formación
  • Guía de estrategia para pruebas
  • Plantilla de caso de prueba
  • Plan de pruebas (SAP Business One – Funcionalidad central)
    • Pedido de cliente
    • Entrega
    • Devolución
    • Factura de deudores
    • Abono deudores
    • Pedido
    • Devolución de mercancía
    • Pedido de entrada de mercancías
    • Factura de proveedores
    • Abono de compras
  • Log de emisión
  • Log de modificaciones
  • Formulario de solicitud de cambio

La Lista maestra de procesos empresariales, Guía de Change Management Communication, Guía de estrategia para pruebas, Plantilla de caso de prueba y los Planes de pruebas son documentos exclusivos de la Realización del proyecto (fase 3) del SAP Business One Accelerated Implementation Program. El Log de modificaciones se utiliza para esta fase y la fase de Realización del proyecto. El Log de emisión se utiliza para esta fase, así como para las fases de Realización del proyecto y Go-Live y soporte.

Realización del proyecto: Planes de pruebas

Plan de Pruebas Ped Cliente

  • El objetivo de este plan de pruebas consiste en poner a prueba la funcionalidad central de Pedido de cliente en SAP Business One. Este Plan de pruebas se debe completar mediante el uso de la Base de datos de pruebas que contiene los datos maestros de la empresa.
  • Complete este Plan de pruebas siguiendo los pasos y cumpliendo con la hoja de trabajo. Una vez haya verificado que el resultado actual coincide con el resultado esperado tal como se ha definido en el Plan de pruebas, firme el documento y devuélvalo al <Interlocutor de implementación>.
  • Requisitos previos para poner a prueba la funcionalidad central de Pedido de cliente.
  • (Este Plan de pruebas utiliza los Interlocutores comerciales y los Artículos que se encuentran en el OEC Demo Company, proporcionado por SAP junto con el software Business One para presentaciones.)

Recomendaciones acerca de las mejores prácticas

  • Involucrar a los miembros funcionales del cliente.
  • Comunicar claramente al cliente que la calidad y la integridad de los datos para la migración de los datos es responsabilidad del cliente.
  • Utilizar el Configuration Express Wizard (CEW) para inicializar el sistema SAP Business One.
  • Realizar todo o gran parte del test de aceptación/validación del sistema junto con el cliente en un "Conference Room Pilot" formal.
  • Los usuarios finales deberían inciar una sesión en el sistema con su ID de usuario y simular procesos empresariales desde el incio al final.
  • Imprimir una copia de todos los documentos de salida.

Configuration Express Wizard (CEW)

  • Configuration Express Wizard es una herramienta desarrollada para reducir el tiempo de implementación (básico) para todas las localizaciones.
  • Se incluye con la herramienta un informe impreso de las configuraciones detallas para la confirmación del proyecto.
  • Como ocurre con este informe impreso, se pretende incluir esta herramienta Configuration Express en la próxima entrega de productos.

SAP Business One Server Suite ManagerSBO Server Suite Manager

SAP Business One Server Suite Manager y sus servicios se instalan automáticamente al instalar el servidor SAP Business One. 

Después de la instalación debe iniciar SAP Business One Server Suite Manager ejecutando el fichero ServerManager.exe en la unidad:\\<Vía de acceso de instalación de SAP Business One>\Server Suite Manager.

Después de instalar SAP Business One Server Suite Manager, aparece un icono nuevo en la barra de tareas de Windows. Para abrir SAP Business One Server Suite Manager, haga doble clic en este icono. Puede seleccionar, establecer, iniciar, pausar o detener servicios uno a uno en SAP Business One Server Suite Manager.

Se proporcionan los servicios siguientes:

  • Servicio SAP Business One Backup
  • Gestor de licencias de SAP Business One
  • Parametrizaciones del servidor de interfase de datos
  • SAP EarlyWatch Alert

sap_Logo

 headerbar-sap-business-one-right