Per tal de reduir costos de personal de IT, costos de manteniment de la infraestructura SAP i reduir costos de llicencies SAP, les empreses multinacionals fa uns anys van començar projectes per tal de centralitzar els seus sistemes SAP dispersos per tot el món en un sol sistema SAP, anomenat SAP Central. En els darrers mesos he estat participant en un equip local de consultors SAP en un d'aquests projectes on el sistema SAP Central acabarà tenint, al finalitzar el projecte global, més de 40.000 usuaris SAP amb més de 200 societats i multitud d'idiomes (espanyol, anglès, alemany, francès, italià, portuguès,...).
M'agradaria compartir les bones pràctiques que he detectat i alguns dels reptes funcionals i tècnics que s'han de resoldre en aquesta classe de projectes.
Processos
Primer de tot cal definir per cada mòdul de SAP quins processos seran globals, comuns per totes les societats i països, i quins processos admetran variacions locals per raons de negoci i/o legals. Els conjunt de processos globals formen el Global template.
Cal analitzar l'impacte que tindrà aquesta unificació de processos globals en el sistema SAP Central. Si els processos globals son els que ja estan utilitzant en el sistema SAP Central, la complexitat del projecte es redueix a integrar les diferents societats i països dels diferents sistemes SAP Locals als processos del SAP Central acceptant les variacions locals identificades durant el anàl. lisis dels processos locals.
Per contra si el sistema SAP Central no està utilitzant els processos globals definits, la complexitat augmenta al tenir primer que coordinar l'implantació dels processos globals en el sistema SAP Central i posteriorment realitzar l'iintegració de les diferents societats i països dels diferents sistemes SAP Locals.
Gatekeepers (responsable del procés global)
La figura del Gatekeeper esdevé clau en un sistema SAP central Global. Per cada mòdul de SAP s’ha de crear la figura del Gatekeeper, que es la persona responsable del procés global. El Gatekeeper es el responsable d’autoritzar qualsevol modificació que es demani sobre el procés global del seu mòdul. Es la persona que decideix si un nou procés s’incorpora al template global o esdevé una procés local. Si s’incorpora al template global significa que qualsevol altre societat o país el podrà utilitzar sense problemes, haurà de demanar al Gatekeeper l’activació del procés per la seva societat.
Nomenclatura objectes propis
Està bastant estes entre les multinacionals la utilització de la codificació Y* pels objectes globals, es a dir per objectes que fan servir tots els països (o la majoria) i utilitzar la nomenclatura Z* pels objectes locals, aquells que per raons de negoci o legals només utilitza un país.
Customizing objectes
Cal definir quins processos son homogenis per totes les societats i països i quins processos permeten variacions a nivell de societat o país.
Si els processos son homogenis els objectes customitzats tindran el nom Y* i seran comuns entre les diferents societats i països.
En els processos no homogenis, els objectes customitzats tindran el nom ZXX* on XX serà el identificador del país.
Cada país tindrà associat un codi alfanumèric de país (el estàndard ISO) i un número, ja que hi ha objectes de customizing que no accepten lletres en la seva codificació, que s'utilitzaran per codificar els objectes de customizing segons el país pels objectes locals.
També cal tenir en compte que hi ha objectes que son limitats com les rutines condicionals de copia on només en disposem de 500 per totes les aplicacions. Semblen moltes però quan tens més de 150 societats de països de tot el món amb esquemes de preus en comandes, documents de transports i esquemes de missatges en tots els mòduls, les rutines s'esgoten ràpidament a no ser que tinguis una visió més global i defineixis una solució global per cadascú dels escenaris on es fan servir les rutines de control de copia, rutines de transferència i rutines condicionals.
User-exits i BADIs
Les user-exits i BADIs s'hauran d'encapsular de tal manera que puguin ser activades per societat (o depenen del mòdul d’una altre estructura o combinació de estructures organitzatives de nivell alt).
La codificació de la User-exit estarà feta de tal manera que es codifiqui una sola vegada i no afecti a la resta de societats i països. Per exemple la User-exit accedirà a una taula Y* accedint per Societat, si existeix un registre per la societat, aquest registre contindrà la funció que cal executar per aquesta societat (cada societat tindrà la seva funció, a no ser que varies societats apliquin les mateixes regles de negoci, aleshores compartirien la funció). L'execució d'aquesta funció serà dinàmica i la funció tindrà els mateixos paràmetres que la User-exit.
Aquelles User-exits que son Forms, com per exemple en les User-exits de la comanda de ventes o l'entrega, s'aplicarà el criteri de inserir un include global Y*, per la lògica de negoci global, i un include per cada país que tingui lògica de negoci local, aplicant la nomenclatura exposada abans.
Programes
Els programes Globals Y*, i com a bones pràctiques els locals també, no haurien de tenir cap tipus de ‘HardCode’ que impliquin nivells organitzatius (com societats, centres, magatzems, …) ni classes de documents o altres criteris que puguin diferir en funció de la societat o el centre o alguna altre dada organitzativa.
Els programes s'han de fer parametritzables per societats i amb criteris de selecció amplis per tal que puguin ser utilitzats per totes les societats i països. Dintre dels criteris de selecció sempre haurem de tenir un o dos camps obligatoris per tal que s'utilitzin els índexs de les taules de la base de dades i així fer que el rendiment del programa sigui òptim, tot i tenir uns criteris de selecció molt amplis. Cal donar molta llibertat de selecció, però a l'hora tenir molt present el rendiment del programa i els seus efectes sobre el consum de recursos del sistema.
La centralització a un sol sistema SAP implicarà fer una tasca de renombrar tots els objectes locals Z*, que s’hagin acordat que es migren al sistema SAP Central, aplicant la nomenclatura que inclou el codi del país. Per tant el programa típic que està codificat com ZMMRP** en el sistema SAP local, si l'utilitza una o varies societats espanyoles, passarà a anomenar-se en el nou sistema SAP Central: ZES+codificació del nou sistema SAP Central.
EDIs i sistemes externs
Una altra de les tasques que cal analitzar amb cura es l'impacte que te la centralització en els nostres processos EDI-IDOC i amb altres sistemes externs.
S'ha de realitzar un inventari dels processos IDOCs que cal migrar i contactar amb varis clients i proveïdors per coordinar les proves amb el nou sistema SAP Central.
Cal migrar també els processos IDOCs que es realitzaven en processos interns del sistema SAP local, per exemple entre dues societats ubicades en el mateix sistema SAP local.
També cal fer una reenginyeria dels processos IDOCs entre dues societats, una del sistema SAP local i l'altre en el sistema SAP Central, ja que ara les dues societats estaran en el mateix sistema SAP. Cal preguntar-se: ¿Podem evitar els IDOC i utilitzar un procés estàndard SAP com seria la comanda de compres Crosscompany?
Els processos d'integració amb sistemes externs s'hauran d'identificar i provar curosament, ja que l’entorn del sistema haurà canviat i ens podem trobar per exemple que ara el nou sistema SAP es troba en un altre país, amb una altre versió de SAP i corre sota un altre sistema operatiu, ¿aquests fets poden afectar a la connexió e integració dels processos amb els nostres sistemes externs?
Jobs
El usuari no podrà planificar Jobs amb cap tipus de periodicitat, si que podrà executar programes en fons. S'haurà de crear un procediment, i realitzar una utilitat si es considera oportú, per tal que els usuaris demanin la creació de Jobs amb la periodicitat desitjada i s'exposi breument perquè s'utilitzarà el Job. Amb aquest procediment hem d'evitar el descontrol que suposa que els usuaris planifiquin Jobs, ja que al final es dupliquen execucions o s'executen Jobs creats per usuaris que ja no s'encarreguen de fer el seguiment d'aquests Jobs.
Altres aspectes
Quan la centralització de dos sistemes SAP implica que la versió SAP del sistema Central es superior al del sistema local, ens podem trobar amb altres reptes que hem de superar. Per exemple, que una funcionalitat estàndard de SAP passi a ser obsoleta perquè SAP ja no li donarà suport, com passa amb una de les tecnologies del SAP Console.
Un altre exemple, si en el nostre sistema origen hem copiat un programa estàndard a un programa Z* (aquesta pràctica de copiar una programa estàndard a un Z* no s'hauria de fer mai, o si més no, només en casos molt excepcionals i amb una raó de negoci amb molt de pes i caldria que fos autoritzada pel responsable de SAP), caldrà fer una reenginyeria del procés. Com a bona pràctica s'hauria d'aprofitar la centralització per corregir aquesta mala pràctica, per tant implicaria esbrinar perquè es va copiar el programa estàndard i quines modificacions es van aplicar sobre l'estàndard. Un cop identificada la funcionalitat addicional, s'hauria de buscar una nova solució però aplicant bones pràctiques, per exemple creant un nou programa Z* amb la nostra funcionalitat pròpia e integrant-lo amb el estàndard SAP utilitzant BAPIs.
Aquests son algunes de les bones pràctiques que he identificat però em deixo d'exposar moltes altres bones pràctiques i problemàtiques com serien: el dimensionament del sistema SAP i la seva disponibilitat 24x7 (ja que donarà servei a 40.000 usuaris ubicats per tot el món), gestió del projecte global de SAP, el manteniment de dades mestres en el sistema SAP Central, la definició dels nous procediments pels nous processos de negoci que es vulguin desenvolupar en el nou sistema SAP Central, el procediment de transports de ordres de Customizing i Workbench, la definició i gestió d'autoritzacions, ....
Un projecte molt interessant que et fa enfocar les problemàtiques amb una visió totalment global i on qualsevol decisió s'ha de fer encabir dintre de la solució global del sistema SAP Central.
M'agradaria compartir les bones pràctiques que he detectat i alguns dels reptes funcionals i tècnics que s'han de resoldre en aquesta classe de projectes.
Processos
Primer de tot cal definir per cada mòdul de SAP quins processos seran globals, comuns per totes les societats i països, i quins processos admetran variacions locals per raons de negoci i/o legals. Els conjunt de processos globals formen el Global template.
Cal analitzar l'impacte que tindrà aquesta unificació de processos globals en el sistema SAP Central. Si els processos globals son els que ja estan utilitzant en el sistema SAP Central, la complexitat del projecte es redueix a integrar les diferents societats i països dels diferents sistemes SAP Locals als processos del SAP Central acceptant les variacions locals identificades durant el anàl. lisis dels processos locals.
Per contra si el sistema SAP Central no està utilitzant els processos globals definits, la complexitat augmenta al tenir primer que coordinar l'implantació dels processos globals en el sistema SAP Central i posteriorment realitzar l'iintegració de les diferents societats i països dels diferents sistemes SAP Locals.
Gatekeepers (responsable del procés global)
La figura del Gatekeeper esdevé clau en un sistema SAP central Global. Per cada mòdul de SAP s’ha de crear la figura del Gatekeeper, que es la persona responsable del procés global. El Gatekeeper es el responsable d’autoritzar qualsevol modificació que es demani sobre el procés global del seu mòdul. Es la persona que decideix si un nou procés s’incorpora al template global o esdevé una procés local. Si s’incorpora al template global significa que qualsevol altre societat o país el podrà utilitzar sense problemes, haurà de demanar al Gatekeeper l’activació del procés per la seva societat.
Nomenclatura objectes propis
Està bastant estes entre les multinacionals la utilització de la codificació Y* pels objectes globals, es a dir per objectes que fan servir tots els països (o la majoria) i utilitzar la nomenclatura Z* pels objectes locals, aquells que per raons de negoci o legals només utilitza un país.
Customizing objectes
Cal definir quins processos son homogenis per totes les societats i països i quins processos permeten variacions a nivell de societat o país.
Si els processos son homogenis els objectes customitzats tindran el nom Y* i seran comuns entre les diferents societats i països.
En els processos no homogenis, els objectes customitzats tindran el nom ZXX* on XX serà el identificador del país.
Cada país tindrà associat un codi alfanumèric de país (el estàndard ISO) i un número, ja que hi ha objectes de customizing que no accepten lletres en la seva codificació, que s'utilitzaran per codificar els objectes de customizing segons el país pels objectes locals.
També cal tenir en compte que hi ha objectes que son limitats com les rutines condicionals de copia on només en disposem de 500 per totes les aplicacions. Semblen moltes però quan tens més de 150 societats de països de tot el món amb esquemes de preus en comandes, documents de transports i esquemes de missatges en tots els mòduls, les rutines s'esgoten ràpidament a no ser que tinguis una visió més global i defineixis una solució global per cadascú dels escenaris on es fan servir les rutines de control de copia, rutines de transferència i rutines condicionals.
User-exits i BADIs
Les user-exits i BADIs s'hauran d'encapsular de tal manera que puguin ser activades per societat (o depenen del mòdul d’una altre estructura o combinació de estructures organitzatives de nivell alt).
La codificació de la User-exit estarà feta de tal manera que es codifiqui una sola vegada i no afecti a la resta de societats i països. Per exemple la User-exit accedirà a una taula Y* accedint per Societat, si existeix un registre per la societat, aquest registre contindrà la funció que cal executar per aquesta societat (cada societat tindrà la seva funció, a no ser que varies societats apliquin les mateixes regles de negoci, aleshores compartirien la funció). L'execució d'aquesta funció serà dinàmica i la funció tindrà els mateixos paràmetres que la User-exit.
Aquelles User-exits que son Forms, com per exemple en les User-exits de la comanda de ventes o l'entrega, s'aplicarà el criteri de inserir un include global Y*, per la lògica de negoci global, i un include per cada país que tingui lògica de negoci local, aplicant la nomenclatura exposada abans.
Programes
Els programes Globals Y*, i com a bones pràctiques els locals també, no haurien de tenir cap tipus de ‘HardCode’ que impliquin nivells organitzatius (com societats, centres, magatzems, …) ni classes de documents o altres criteris que puguin diferir en funció de la societat o el centre o alguna altre dada organitzativa.
Els programes s'han de fer parametritzables per societats i amb criteris de selecció amplis per tal que puguin ser utilitzats per totes les societats i països. Dintre dels criteris de selecció sempre haurem de tenir un o dos camps obligatoris per tal que s'utilitzin els índexs de les taules de la base de dades i així fer que el rendiment del programa sigui òptim, tot i tenir uns criteris de selecció molt amplis. Cal donar molta llibertat de selecció, però a l'hora tenir molt present el rendiment del programa i els seus efectes sobre el consum de recursos del sistema.
La centralització a un sol sistema SAP implicarà fer una tasca de renombrar tots els objectes locals Z*, que s’hagin acordat que es migren al sistema SAP Central, aplicant la nomenclatura que inclou el codi del país. Per tant el programa típic que està codificat com ZMMRP** en el sistema SAP local, si l'utilitza una o varies societats espanyoles, passarà a anomenar-se en el nou sistema SAP Central: ZES+codificació del nou sistema SAP Central.
EDIs i sistemes externs
Una altra de les tasques que cal analitzar amb cura es l'impacte que te la centralització en els nostres processos EDI-IDOC i amb altres sistemes externs.
S'ha de realitzar un inventari dels processos IDOCs que cal migrar i contactar amb varis clients i proveïdors per coordinar les proves amb el nou sistema SAP Central.
Cal migrar també els processos IDOCs que es realitzaven en processos interns del sistema SAP local, per exemple entre dues societats ubicades en el mateix sistema SAP local.
També cal fer una reenginyeria dels processos IDOCs entre dues societats, una del sistema SAP local i l'altre en el sistema SAP Central, ja que ara les dues societats estaran en el mateix sistema SAP. Cal preguntar-se: ¿Podem evitar els IDOC i utilitzar un procés estàndard SAP com seria la comanda de compres Crosscompany?
Els processos d'integració amb sistemes externs s'hauran d'identificar i provar curosament, ja que l’entorn del sistema haurà canviat i ens podem trobar per exemple que ara el nou sistema SAP es troba en un altre país, amb una altre versió de SAP i corre sota un altre sistema operatiu, ¿aquests fets poden afectar a la connexió e integració dels processos amb els nostres sistemes externs?
Jobs
El usuari no podrà planificar Jobs amb cap tipus de periodicitat, si que podrà executar programes en fons. S'haurà de crear un procediment, i realitzar una utilitat si es considera oportú, per tal que els usuaris demanin la creació de Jobs amb la periodicitat desitjada i s'exposi breument perquè s'utilitzarà el Job. Amb aquest procediment hem d'evitar el descontrol que suposa que els usuaris planifiquin Jobs, ja que al final es dupliquen execucions o s'executen Jobs creats per usuaris que ja no s'encarreguen de fer el seguiment d'aquests Jobs.
Altres aspectes
Quan la centralització de dos sistemes SAP implica que la versió SAP del sistema Central es superior al del sistema local, ens podem trobar amb altres reptes que hem de superar. Per exemple, que una funcionalitat estàndard de SAP passi a ser obsoleta perquè SAP ja no li donarà suport, com passa amb una de les tecnologies del SAP Console.
Un altre exemple, si en el nostre sistema origen hem copiat un programa estàndard a un programa Z* (aquesta pràctica de copiar una programa estàndard a un Z* no s'hauria de fer mai, o si més no, només en casos molt excepcionals i amb una raó de negoci amb molt de pes i caldria que fos autoritzada pel responsable de SAP), caldrà fer una reenginyeria del procés. Com a bona pràctica s'hauria d'aprofitar la centralització per corregir aquesta mala pràctica, per tant implicaria esbrinar perquè es va copiar el programa estàndard i quines modificacions es van aplicar sobre l'estàndard. Un cop identificada la funcionalitat addicional, s'hauria de buscar una nova solució però aplicant bones pràctiques, per exemple creant un nou programa Z* amb la nostra funcionalitat pròpia e integrant-lo amb el estàndard SAP utilitzant BAPIs.
Aquests son algunes de les bones pràctiques que he identificat però em deixo d'exposar moltes altres bones pràctiques i problemàtiques com serien: el dimensionament del sistema SAP i la seva disponibilitat 24x7 (ja que donarà servei a 40.000 usuaris ubicats per tot el món), gestió del projecte global de SAP, el manteniment de dades mestres en el sistema SAP Central, la definició dels nous procediments pels nous processos de negoci que es vulguin desenvolupar en el nou sistema SAP Central, el procediment de transports de ordres de Customizing i Workbench, la definició i gestió d'autoritzacions, ....
Un projecte molt interessant que et fa enfocar les problemàtiques amb una visió totalment global i on qualsevol decisió s'ha de fer encabir dintre de la solució global del sistema SAP Central.
