dijous, 16 de setembre de 2010

Bones pràctiques en centralització de sistemes SAP

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.

divendres, 30 de juliol de 2010

Les 10 transaccions més útils de SAP

Les 10 transaccions que considero més útils de SAP i que son les que faig servir amb més assiduïtat, ja sigui perquè haig de resoldre una incidència, realitzar una càrrega massiva de dades en una implantació, realitzar de manera urgent una modificació massiva de dades o realitzar un anàlisis de com resoldre una manca de funcionalitat del sistema SAP mitjançant les eines que proporciona el sistema estàndard.

Les 10 transaccions més útils de SAP:

1. LSMW Legacy System Migration Workbench

Aquesta transacció permet realitzar carregues de dades mestres, fer modificacions en masses i si saps una mica de programació pots fer pràcticament de tot. Transacció imprescindible quan s’ha d’implantar una nova societat en el sistema, fer una fusió d’empreses, realitzar un canvi massiu o realitzar una càrrega massiva de dades mestres.

2. ST22 Anàlisis de dumps ABAP

Transacció que ens permet analitzar si en el sistema s’estan cancel•lant processos transaccionals. En un sistema estable no s’haurien de produir gaires Dumps en el sistema, però es bo consultar aquesta transacció sempre que implantem un nou procés en el sistema.

3. Autorització per Debugar (/h)

Tot i que no es una transacció, considero que tenir autorització per debugar(/h), en el sistema de producció es una ajuda que permet analitzar problemàtiques d’una manera molt més ràpida i àgil. Per temes de seguretat, les empreses que cotitzen en borsa o tenen establerts procediments de control estrictes no donen autorització a aquesta funcionalitat en l’entorn de producció.

4. SMOD Gestió d’ampliacions SAP

Quan hem d’estendre la funcionalitat del sistema estàndard SAP, aquesta transacció es converteix en una font de recursos molt interessant per descobrir d’una maner ràpida totes les user-exits de les que disposa el sistema sense tenir que anar als punts de customizing. La transacció ens permet fer cerques i més d’una vegada he descobert alguna user-exit que no hi hagut manera de trobar en el Customizing (coses del SAP).

5. SNOTE Note Assistent de SAP

La implantació de notes OSS ha passat de ser un suplici a ser un joc de nens (o gairebé perquè en SAP res es tan senzill com sembla ) des de que el sistema incorpora aquesta transacció.

6. WEDI - Menú àmbit dels IDOCs

Es un menú d’àmbit que ens porta a les transaccions dels IDOCs. Aquest menú es una mina de recursos per analitzar el contingut dels IDOCs, reprocessar IDOCs, crear un IDOC des de un fitxer del servidor, ...

Dintre del entorn dels IDOCs les transaccions que més utilitzo son:
  • WE09 - permet cercar un valor per qualsevol segment del IDOC i sense tenir que especifica el nom del segment
  • WE02 – Permet cercar IDOCs filtrant per una Variant de missatges (camp que cal utilitzar quan es vol derivar workflows d’errors o diferenciar entre centres o societats
  • WE16 – Permet crear IDOC a partir d’un fitxer del servidor – transacció necessària quan estem implantant un nou procés d’entrada de dades mitjançant IDOCs des de un sistema extern i hem de realitzar les primeres proves unitàries)
  • BD87 – Transacció molt útil per processar massivament IDOCs que s'han quedat ‘penjats (sense processar) per algun motiu, a vegades el motiu es el desacoblament del event amb el procés d’entrada i per tal de reactivar aquest acoblament hem de fer servir la transacció OYEB
  • PPOME – Per crear l’estructura organitzativa, les funcions i posicions que han de rebre els missatges d’error dels IDOCs.

7. SE18 BadI-Builder: Definicions

Una altre transacció que ens permet estendre les funcionalitats del sistema SAP, en aquest cas amb el concepte de programació orientada a objectes i totes les seves propietats que es poden implementar amb les BADIs.

8. SM12 Visualitzar i eliminar bloquejos


Aquesta transacció es convenient consultar-la quan es fan càrregues massives de dades mestres o variables o processos que fan modificacions massives. Es convenient durant les proves de volum comprovar que el sistema de bloquejos tant estàndard com de les nostres taules Z* e Y* funciona correctament i amb la rapides esperada i necessària.

9. SCOT SAPConnect Gestió

Transacció que cal consultar quan hi ha problemes amb l’enviament de Fax, Emails o SAPOffice. Ens permet veure el detall de tot el que s’ha estat enviant i els seus estatus.

10. SPRO Customizing: Tractament projecte

Finalment la transacció que ens porta al customizing del sistema SAP, on el sistema ens descobreix tota la seva potencialitat i on per més hores que t’hi passis remenant sempre acabes trobant un nou punt de customizing amb una funcionalitat que t’havia passat per alt fins aquell moment.

Altres transaccions que faig servir per treure el màxim profit del sistema SAP o analitzar com s’està comportant el sistema SAP:
  • SM37 - Resum mitjançant selecció de jobs
  • ST05 - Performance Analysis
  • BAPI - Explorador BAPIs
  • SPAU Visualitzar objectes ED modificats i SPDD Visualitzar objectes Dict. modificats: Les dues transaccions per excel•lència quan es realitza un canvi de versió, podem detectar quins programes estàndard i objectes del diccionari s’han modificat en el sistema. Desconec si amb la versió ECC6 existeix alguna altra transacció que faciliti el canvi de versió.

Aquestes son les transaccions que considero més útils per treure el màxim profit del sistema SAP o que m’ajuden en el meu dia a dia. ¿Quines son les transaccions SAP que considerés més útils?

dilluns, 29 de març de 2010

SAP MM

Interessant presentació introductòria al mòdul de SAP MM realitzada per Ravi Jain.

Explica les principals funcions del components que formen el mòdul MM de SAP: Planificació basada en els consums, Compres, Gestió dels serveis externs, Gestió del inventari, verificació de factures logístiques i gestió de l’avaluació dels proveïdors.

SAP MM Process Flow

Remarca alguns dels beneficis de l’ús de SAP MM:

- Reducció del cost dels materials

- Control dels costos indirectes

- Reducció del risc de pèrdues de inventari

- Millores en la entrega dels productes

Els beneficis que destacaria jo quan es fa un bon ús del mòdul MM de SAP:

- Control dels proveïdors als quals es pot comprar mitjançant els registres infos de SAP. Control imprescindible que s’ha de realitzar per alguns sectors, com el farmacèutic, on els proveïdors han d’estar homologats.

- El MRP pot escollir el proveïdor més idoni segons el termini d’entrega del proveïdor, segons la quantitat de compra o bé segons la quota assignada a cadascun dels proveïdors.

- Millor gestió i control de compres de despeses e inversions, imputant el cost al centre de cost, projecte o comanda de client.

- Gestió compres CrossCompany molt senzilla amb les comandes de trasllat.

- Gestió del stock simple: cada material només permet una ubicació

- La regla de determinació de stock permet aplicar certs criteris per decidir quin estoc s’ha de consumir o servir primer: ¿Primer Stock propi o stock en consigna? ¿Quina prioritat s’ha de donar a cadascun dels magatzems per consumir el stock?

- Control de les factures de proveïdor molt configurable segons les necessitats de la empresa: verificació basada en la entrega de mercaderia, percentatge màxim de desviació en preus, ...

- La planificació basada en els consums permet ajustar les compres basant-se en els consums històrics, i això implica una millora al reduir el stock en el magatzem, reduïm els dies de rotació del stock i ajudem a millorar el flux de caixa.

- Control del stock facilitat al Subcontractista i del stock a facilitar al Subcontractista

No em vull allargar més perquè en cada una de les transaccions que ens ofereix el mòdul MM de SAP se’m ocorren varies raons que ajuden a millor els processos logístics, reduir els temps d’aprovisionament, millorar la gestió i control dels proveïdors, ..

El Mòdul MM de SAP, si està ben parametritzat i s’utilitzen la majoria de les funcionalitats estàndard del sistema ens permet obtenir unes millores molt significatives en els processos i en les diverses àrees que gestiona.

diumenge, 28 de març de 2010

Cicle optimització processos SAP amb MM, WM i RF

El següent gràfic pretén representar molt senzillament l’evolució natural que experimenten les empreses que tenen instal•lat SAP quan volen millorar els seus processos logístics, concretament els processos físics que es produeixen dintre dels magatzems.

Inicialment les empreses comencen instal•lant únicament el mòdul MM, perquè es el més semblant a la gestió que tenien en el seu sistema anterior i perquè els processos dintre de SAP son més senzills, excepte per aquells magatzems amb gran complexitat en els quals ja instal•len de bon principi el mòdul WM.

Posteriorment, s’adonen que estant desaprofitant molt espai físic en el magatzem al no tenir definides ubicacions i que no poden aplicar estratègies d’entrada i sortida en els materials que els permetrien disminuir el recorregut dels materials dintre del magatzem. Es aleshores quan activen el mòdul WM de SAP.

Finalment, s’adonen que el temps emprat per confirmar les ordres de transport de SAP es ferragós pels operaris. Per poder realitzar un control més estricte i eficaç del volum de càrrega dels operaris del magatzem, així com per tenir un control més detallat dels retards en les operacions del magatzem es necessari la utilització de la Radiofreqüència(RF) en el magatzem, i aquí el SAP Console es una aplicació estàndard de SAP que ja incorpora varies transaccions específiques per les pistoles de RF, a més a més permet crear transaccions pròpies utilitzant el llenguatge de programació ABAP IV, per tant podem ampliar la funcionalitat de SAP Console sense la necessitat d’aprendre un nou llenguatge de programació, utilitzant el procés transaccional estàndard de SAP per encadenar processos des de una pistola de RF i sense els maldecaps que suposa la integració amb aplicacions no SAP.

dissabte, 20 de març de 2010

SAP EDI : últimes tendències SAP Information and Interchange (SII)

¿Quines son les últimes tendències en implementacions EDI en el entorn SAP?

Les últimes tendències en les implementacions EDI en el entorn SAP estan aprofitant els avantatges en reducció de costos i simplificació del hardware i software per l’empresa que suposen els Software com a Servei (SaaS) i el núvol.

A finals de l’any 2008 SAP va adquirir l’empresa Crossgate, un dels serveis que poden marcar un punt d’inflexió en com enteníem les comunicacions EDI i B2B es el SAP II (SAP Information and Interchange).

SII es una plataforma EDI i B2B centralitzada que poden utilitzar tots els usuaris SAP per intercanviar fitxers EDI i qualsevol document de negoci electrònic. La plataforma esta basada en la tecnologia SAP NetWeaver PI.

SAP Information Interchange

Les empreses es poden subscriure al servei de SII i un cop subscrits poden convidar als seus partners (clients, proveïdors, ...) a connectar-se mitjançant el servei SII per intercanviar qualsevol fitxer EDI o qualsevol fitxer electrònic. Igual que creem el nostre perfil a LinkedIn i després podem convidar a qualsevol conegut nostre a apuntar-se, i que qualsevol persona ens trobi en LinkedIn, el SII funciona igual. Un cop l’empresa s’ha apuntat al servei SII s’emmagatzema en un “repository” central global, es publicat i es posa a disposició de tota la comunitat SAP que es troba en el SII. Així qualsevol partner que es trobi en la comunitat ens pot veure i pot proposar-nos intercanviar qualsevol document electrònic o fitxer EDI.

Tenint en compte que prop de 89.000 organitzacions utilitzen SAP en els seus processos de negoci i que més del 70% de l’economia mundial esta formada per organitzacions que utilitzen aplicacions SAP, molts dels nostres partners importants segurament utilitzen SAP en els seus processos de negoci i ens pot permetre aportar valor en la nostra relació amb ells utilitzant tecnologia EDI estàndard SAP.

La idea central de SII es que les empreses enviïn un únic fitxer EDI estàndard de SAP al “repository” global, per cada procés de negoci que intercanviïn amb el seus partners, i d’aquesta manera qualsevol partner que estigui subscrit al servei pot rebre els fitxer per EDI.

Amb aquesta plataforma s’haurien d’acabar els fitxers EDI customitzats per cada client o per cada proveïdor. Però malgrat les bones intencions, es una utopia perquè en algun moment s’haurà de fer algun tipus de conversió de dades entre els nostres sistemes i els sistemes dels clients o proveïdors, per exemple la codificació de les nostres condicions d’expedició que hem configurat en el nostre sistema SAP segurament no coincidirà amb la dels nostres clients i en algun punt, o bé en el nostre sistema o bé en el SII o bé en el sistema del nostre client s’haurà de fer una taula de correspondència entre les nostres condicions d’expedicions i les del client.

El servei SII ajuda a reduir el cost d’implantació, aprenentatge i manteniment d’un sistema EDI i d’un equip EDI. A més a més al ser un servei ofert per una empresa de SAP, ajuda a reduir les aplicacions no SAP (una tendència creixent en les empreses) i per tant a estandaritzar el procés amb tecnologia SAP.

SII es el servei EDI i B2B ofert per SAP, però hi ha altres empreses que ofereixen el servei de subsistema EDI com a SaaS, i a més a més estan certificades per SAP, com podria ser EDICOM.

La reflexió més important que han de fer totes les empreses que tenen SAP i que no tenen activats els EDIs, es que estan perdent el tren de la millora en la seva productivitat i que estan deixant d’oferir un servei de més valor afegit al seus clients i també estan deixant de rebre un servei de més valor afegit per part dels seus proveïdors. El ROI d’implementar un o varis fluxos EDI es fàcilment mesurable i ens sorprendrà veure que en menys temps del que ens pensem el nostre ROI es positiu, a més a més estem oferint un servei de més valor afegit als nostres clients i oferint una imatge d’empresa tecnològicament avançada.

Articles SAP EDI i SAP Information Interchange:

SAP EDI, Cloud Computing and Business Networks
SAP® Information Interchange - SAP's New EDI Solution
Existing EDI Users and the SAP Information Interchange

Externalitzar els serveis EDI i les operacions B2B

Crossgate es una empresa que ofereix el servei d’externalitzar els serveis EDI i les operacions B2B a les empreses. SAP AG es accionista de Crossgate. En aquest vídeo ens expliquen quins serveis ofereixen i com les empreses poden reduir els seus costos en els departaments EDI.

dimarts, 16 de març de 2010

SAP XI – SAP PI

SAP XI SAP PI
En aquest Power Point exposen d’una manera força senzilla i clara que es el SAP XI, la última versió es el SAP PI.

SAP XI – SAP PI està construït sobre els estandards oberts SOA, XML i Java.

EL SAP XI – SAP PI s’està utilitzant actualment, entre altres, en les aplicacions:

  1. MDM – SAP Master Data Management
  2. SRM – SAP Supplier Relationship Management
  3. ICH – SAP Inventory Collaboration Hub within SAP SCM
  4. BI – SAP Business Intelligence, for Global reporting Spending
  5. R/3 Enterprise – for industry Standard Support
  6. CRM – SAP Customer Relationship Management, for Extended Order Management
  7. SBO – SAP Business One