Proyecto Upgrade SAP B1


#1

Hola a todos de nuevo…

Bueno aquí mi consulta será sencilla y más fácil que las demás a las que casi nunca le encuentro respuestas jajajaja…

A ver. ¿Alguno de ustedes ha realizado el upgrade de versión 9.0 a 9.2?, o de 9.1 a 9.2? si lo ha hecho solo necesito saber un punto:

¿Tienen por casualidad el plan de proyecto de Upgrade? no me importa si es en Excel, Proyect, un documento de word… lo que sea…

Es que me solicitaron que realizara un plan nuevo para un upgrade, y tengo una idea del proyecto que esto conlleva, pero tengo ciertas dudas sobre como manejar o como colocar la posibilidad de que el upgrade arroje errores.

En mi experiencia personal he realizado los upgrade y me he encontrado con 2 escenarios:

  1. Todo perfecto: Es decir, no existió error en el ambiente de pruebas, se realizó el upgrade, se probó las funcionalidades, conexión con PAC y todo lo demás y PERFECT…

  2. Arroja Errores el Upgrade: En este caso si fue más feo… El trabajo de Upgrade que se suponía se podía hacer en apenas unos días, se tomó mas de mes y medio mientras se consideraban y se buscaban respuestas de parte de SAP, aplicando notas y luego levantando un ticket con SAP Directamente porque el Upgrade no funcionó.

Entonces bien, mi jefe me acaba de pedir que quiere que le arme una propuesta de upgrade, con planificación general, que pasos debemos correr, que pruebas se deben de realizar y demás. En otras palabras, que me saque de la manga un proyecto armado que de una vez contemple las posibilidades de errores en el upgrade y puesta en vivo en productivo.

¿Alguien tiene un plan así sea generico que me pueda compartir? no lo necesito para copiar sino para ayudarme a tomar la idea de como hacerlo.


Upgrade SAP B1 9.2 pl04 a 9.2 pl08
Pasos para una migracion de pl01 a pl06 sap b1 9.2
Migración SAP Business One PL9
#2

Hola compañero.

La migración más reciente que presentamos fue un salto grandísimo de 8.81 a 9.2, la verdad un plan como tal nunca hemos manejado, a grandes rasgos hacemos lo básico, “lo normal” levantar varios ambientes de pruebas (diferentes equipos) y realizar las migraciones correspondientes, posterior realizamos una exhaustiva fase de pruebas, realizando varios escenarios con cada documento que se maneja en el sistema y comparando que los resultados sean los mismos en ambas versiones, la verdad esto nos lleva muchísimo tiempo pero nos asegura que todo seguirá manejándose de manera normal, a muchos les parecerá exagerado pero hemos detectado varios puntos a tiempo que de no haberlos detectado, hubieran afectado muchísimo ya estando en productivo. Una vez que las pruebas unitarias han sido satisfactorias, programamos la migración en productivo, obvio fuera de horario laboral y por lo general en fin de semana para que en caso de existir algún caso extraordinario, tengamos suficiente tiempo para resolverlo o bien, echar todo para atrás.

Un plan de los posibles errores y sus soluciones es algo ambicioso, es buena idea para una empresa que se dedica a dar servicios de ese tipo pero para un cliente final como nosotros, no tendría mucha relevancia, aunque nunca está de más.

Mucha suerte con tu documento.


#3

Hola estimado.
Lo mas recomendable es que instales un ambiente de pruebas. Es decir una computadora (bastante robusta) o un servidor aparte donde instales la nueva versión de SAP (en tu caso la 9.2).

Luego allí, migres cada una de tus bases de datos productivas (en el ambiente de pruebas). Sacas un backup de cada base productiva (si en caso tenes varias) y luego las migras.
Por lo regular te van a dar (si todo va bien) solo warnings, si tuvieras algun error que no te deje pasar tendras que ver la nota asociada, si lo tenes que escalar a tu partner de SAP te tocará hacer eso y eso te llevará mas tiempo, hasta que ellos te indiquen que procede para resolver ese error.

Tienes que solicitar a tu partner de SAP B1 que te envie unas licencias de pruebas (por lo regular te envian una licencia para manager, y una licencia de cada tipo, por lo regular te dan como 5 licencias aprox.)

En tu ambiente de pruebas te sugiero que realices un plan de pruebas donde calendarices al menos a un usuario por departamento (usuarios claves) que prueben todo lo correspondiente a su departamento. Y te digan que les funcionó bien y que no.
Deben probar Busquedas formateadas, reportes en el Query manager, formatos de impresion PLD y tambien en Crystal reports. Ademas deben probar sus operaciones del dia a dia.
Si tenes addons (de otros proveedores o propios de tu empresa) tambien deben probarse en la nueva version. Si tenes SAP en moviles tambien debes hacer pruebas.

Además es importante que los usuarios te firmen un documento donde indiquen que pruebas realizaron y que les funciono y que no. si tuvieron inconvenientes o no. Eso te servirá de respaldo.

Por tu parte trata de hacer pruebas exaustivas de todo, aunque los usuarios operativos tambien las harán tratá por tu parte tambien de probar lo mas que puedas.
Calendarizá tus pruebas y como menciona el compañero @Gera_Mendez la migracion en productivo definitivamente la tendras que hacer en un fin de semana.

En el plan yo colocaría (algo similar a esto):

1.- Preparacion de ambiente de pruebas.
2.- Migracion de bases de datos en ambiente de pruebas
3.- Resolucion de problemas (warnings y errores)
4.- Pruebas de usuarios operativos (y certificacion de pruebas por los usuarios).
4.1 pruebas de operaciones del dia a dia (formatos, reportes, SAP movil, etc).
4.2 pruebas por parte de IT
5.- Solventar problemas detectados por usuarios operativos.
6.- Solventar problemas de migracion de bases de datos
7.- Determinar fecha definitiva para migracion en productivo
8.- Realizar migracion en productivo.
9.- Solventar problemas en productivo
10. fin.

Esto es mas o menos lo que tenes que hacer. Quizá se me escapa algo pero lo mas seguro que otros compañeros del foro complementen esto.

Saludos.


#4

@Gera_Mendez efectivamente es muy complicadisimo lo de generar un plan general… como dije, puede ser que no me de ningún tipo de error, como puede ser que arroje LOS ERRORES de la vida y se convierta en un mega cangrejo.

Ya tenía en mente lo del ambiente de pruebas, de hecho como dije ya lo he realizado y lo he hecho. Lo malo es que siempre lo he hecho como tu dices, sin un plan como tal, sencillamente avanzando con las pruebas, resolviendo y ya despues de todo migrando en un fin de semana que se determina en el momento.

Por eso mi dificultad para pensar en esta migración como un “plan” de trabajo, que pueda incluir sus posibles errores y soluciones no lo veo para nada viable, pero mi jefe no entiende porque lo veo inviable, es un poco obstuso en que las cosas no pueden salir tan mal como para no intentar que quede dentro de un plan específico.

Por otro lado: @saufondez… Diste justo en el clavo de lo que necesitaba… solo necesitaba una idea más o menos de que pasos generales colocar en el “plan de proyecto de migración”: que con tus 10 puntos me parecen geniales creo que incluiré un par, y ahora será ver como categorizo esto en fechas, y cuanto tiempo le doy a cada parte que para mí es en realidad lo más complicado de todo. ponerles “fechas” o por lo menos decir “tardaré 1 día en la primera parte del Upgrade y 10 días en la verificación de errores” porque son tantos pero tantos factores a influir que no puedo asegurar absolutamente nada en si me tomará 10 días o si la BD no llega a arrojar ningún error, como explicar que esa parte salió en 2 días…

Pero con esta “lista” y al leerla me ayudaste a darme una idea de como organizarlo.


#5

Gera_Mendez y saufondez te han dado los tips mas relevantes. Es muy importante que tomes en cuenta que este proceso es delicado y que lo hagas siempre en PRUEBAS.

-Montas tu servidor lo mas parecido al de producción y monta una copia de la BD
-Realizar el UPGRADER para determinar si se realizar exitosa o erroneamente.
-Después de realizado y si fue existoso…usalo testeando los escenarios criticos de tu negocio para detectar posibles bugs (Aqui si te recomendaria hagas un check list de esos procesos)
-Si sale erroneo la migración, tendras que consultar las notas que te da como referencia y de ser posible pegate al soporte de SAP en caso de ser critico.

Exito amigo!


#6

Al parecer en septiembre lanzan la 9.3. Actualmente trabajamos con la 9.1, queríamos actualizar a la 9.2 pero esperaremos un poco más para hacer todo el proceso a la 9.3

Toda la información que habéis expuesto es realmente interesante.

GRACIAS!!!


#7

La cuestión es que aquí en méxico salió una resolución del SAT (sistema tributario del país) desde diciembre 2016 que solicita unos cambios fuertes a los sistemas ERP para declaraciones de impuestos y poder facturar. Si una empresa el día 1 de Diciembre no tiene las características solicitadas no va a poder facturar a partir de ese día.

Los clientes en México deberán actualizar si o si a 9.2 PL 09 mínimo antes del 30 de Noviembre, y por eso mi jefe me pedía un plan de “cuanto tiempo aproximado se tomaría una migración y que se necesita para hacerlo”

Saludos


#8

Estimado @Ares17000

Todas la recomendaciones que te han dado son muy validas, no olvides revisar también los requerimientos de maquina y sistema (servidor y equipos clientes), pues en cada nueva versión de SAP siempre hay requerimientos mínimos, sobre todo en temas de memoria, procesador,sistema operativo.

Busca el documento Sizing de la versión a la que piensas migrar e incluye en tus pruebas la concurrencia de usuarios, el consumo de memoria según numero de usuarios, Addons, reporting, otros.

Saludos.

JAMS


#9

Buen día Ares17000 yo tengo un caso similar al tuyo justo el dia de mañana iniciare la migración definitiva de 8.82 pl10 a 9.2 pl5. yo tambien soy de mexico y conozco las resoluciones que comentas. En mi caso es mas complejo por que tengo 6 sociedades de diferentes paises cada una instaladas en el mismo servidor y hemos optado por contratar para mexico y brazil Addons que nos ayuden a librar estas resoluciones de la mejor manera y que en caso de nuevos cambios podamos cumplir tan solo con actualizar los addons lo cual es mucho mas sencillo que actulizar todo el aplicativo.

En mi caso lo hacemos asi por que entre las sociedades que tengo hay algunas en suramerica que no estan oficialmente soportadas entonces no podemos actualizar de una version a otra si no hay soporte para los addons que tenemos en esos paises.

Por otra parte te puedo comentar que en esta migración hemos utilizado servidores virtuales lo cual nos ha facilitado muchas cosas entre ella el tema de respaldos y como bien comentan es indispensable probar en un ambiente de pruebas antes de hacer la migración

Se que mi caso es muy diferente al tuyo pero esa es mi experiencia con SAP B1


#10

hola buen dia

me podrian confirmar cuanto es el tiempo para realizar un upgrade de una pase de datos de pl01 a pl07 y que tan factible es realizarla en estos momentos por los cambios que vamos a tener en agosto del 2017 por la contabilidad electronica

de igual forma tengo una duda si subir de p01 a p07 o de pl01 a pl06

quedo a la orden


#11

Justamente estoy negociando con un cliente para una posible propuesta de soporte a su plataforma que tienen la empresa principal aquí en México pero su servidor está en España en la casa matriz y ahí tienen otros países.

Por el momento ellos están trabajando con un partner con soporte ON DEMAND aquí en méxico que resultó que no era un partner de SAP sino que tienen su propio sistema de facturación y solo les crearon una aplicación intermedia, que toma información de SAP, facturan en su sistema propio, y luego devuelven a SAP lo mínimo para operar, pero TODO lo necesario para declaración y demás lo deben llevar luego por fuera con el otro sistema de este “partner”.

Hasta cierto punto puede resultar beneficioso… si… Pero es muy engorroso. Por el momento ellos tienen dos opciones, les propuse que verifiquen la posibilidad de tener un segundo servidor, con bases de datos, con sap actualizado a 9.2 PL Necesario (en este caso será el 08 o 09 según libere SAP para esta solución) y por el tema de licencias que no se preocupen, que esté en la misma red, y ambos servidores pueden usar el mismo servidor de licencia.

Si no tienen la posibilidad de este segundo servidor, si o si deben de pagar una buena ccantidad de dinero para la actualización de esta aplicación que le permite la facturación… pero ya les puse la alarma. Ya no estamos hablando únicamente de facturación sino de pago electrónico y eso es un desarrollo fuerte en SAP. no será tan sencillo y deben prestarle MUCHA atención al tema. es la misma recomendación que te puedo dar.


#12

@wlberth90 buenas tardes…

Los tiempos dependen mucho de tu servidor y el tamaño de la base de datos.

Te lo pongo con las siguientes pruebas realizadas:

Servidor con 32 GB de RAM,
Base de datos de 45 GB de tamaño aproximadamente.
Tiempo de migración aproximado: 2 - 3 horas.

Pero luego de esto debes tener presente un periodo amplio y muy variable. Por una parte tienes la posibilidad de que la migración no se de a la primera, y debas empezar a resolver errores y warnings que te entregue la herramienta de upgrade y migración. por lo que una migración de 3 horas te puede tomar días mientras resuelves los warnings y alertas y buscas notas de SAP y demás para resolverlo.
Después tienes un periodo de pruebas de TODA la operación. Esto puede ser muy variable dependiendo del tamaño de la operación de la empresa, mientras mas procesos y reportes tengan más días se tardará estas pruebas, deben asignar usuarios que prueben cada una de las operaciones para buscar detectar errores antes de realizar la migración en productivo. Puede ser de 3 días a incluso semanas…

Luego de todo esto, y según los resultados que observen en todas las pruebas viene la migración propiamente dicha en productivo, yo a esa migración le doy 3 días. empezarla un viernes, y luego tener el fin de semana para cualquier tipo de inconveniente que se pueda presentar en la migración en productivo y no se observara en pruebas.

Así te digo que el upgrade más rápido yo le daría 1 semana o 1 semana y media… y no debería de tardarse mas de 4 semanas en la medida de lo posible.


¿Pasos para pasar de sql server 2014 a 2016?
#13

Este tema se cerró automáticamente 7 días después del último post. No se permiten nuevas respuestas.