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

dimecres, 10 de març de 2010

¿Que volen els usuaris de SAP de SAP? Reduir costos

¿Que volen els usuaris de SAP de SAP? Reduir costos

Les principals necessitats dels usuaris de SAP son:
  • Reduir el cost de propietat i la complexitat
  • Adreçar la integració de SAP amb les inversions existents
  • Completar el pla de ruta original i promès del producte
  • Reduir el cost de manteniment o mostrar valor
  • Renovar el focus en la innovació (exemple: Web 2.0, SaaS)
  • Millorar la usabilitat
  • Millorar la integració amb Microsoft (Sharepoint, Office)
  • Menys intimidació i més aliances
  • Fer NetWeaver més senzill d’utilitzar
  • Proporcionar un ajut eficaç de costos per R/3 4.X
Degut a aquestes necessitats del usuaris SAP, els proveïdors de SAP que proporcionen optimitzacions i extensions de solucions estan experimentant ràpids creixements. Les aplicacions que creen valor per la empresa es poden classificar en 7 àrees:
  1. Extensió de l’aplicació i facilitat d’ús
  2. Aplicació de gestió del cicle de vida
  3. Arxivat, emmagatzematge i gestió de dades
  4. Gestió de llicències i la optimització
  5. Integració amb Microsoft Office
  6. Manteniment de tercers
  7. Virtualització
Si voleu conèixer el detall de cada una de les àrees que creen valor podeu consultar l’article: The SAP Optimization List – Key Ecosystem Vendors You Should Know

Altres articles interessants sobre les aplicacions SAP que creen valor per les empreses:
  1. 2010 Apps Strategies Should Start With Business Value
  2. Event Report: 2009 SAP Influencer Summit

divendres, 5 de març de 2010

Estratègia carrera professional SAP en SapNetweaver

Tony de Thomasis ha realitzat una presentació molt interessant per reflexionar com definir i executar la nostra carrera professional SAP en SapNetweaver.

Més articles interessant sobre les carreres professional en el entorn SAP per l’any 2010:
SAP Career Outlook 2010: The Intersection of Talent and Community
SAP Career Outlook 2010 - Lessons Learned (plus videos)

divendres, 19 de febrer de 2010

Web Dynpro ABAP: Exemple ‘Hello World’

Holger Stumm ha realiztar un vídeo de com realitzar una aplicació amb Web Dynpro ABAP (WD ABAP), ha creat l’aplicació ‘Hello World’ que ens ensenya tots els passos que cal fer per crear la nostra primera aplicació Web Dynpro ABAP.

La Web Dynpro Abap es pot realitzar des de la transacció SE80 i es programa tot amb ABAP IV. Es el sistema SAP el que s’encarrega de convertir el codi ABAP en format HTML per ser executada des de qualsevol explorador web.

Un cop realitzada l’aplicació podrà ser executada des de qualsevol portal empresarial o des de el navegador de internet.

dissabte, 13 de febrer de 2010

Informe Salaris SAP 2010

Gràcies al article SAP Salary Outlook in 2010: Panaya SAP Salary Survey Analysis del bloc de Jon Reed al SDN de SAP, descobreixo que l’empresa Panaya ha realitzat un informe sobre els Salaris dels professionals SAP 2010.

Del informe destaco dues gràfiques molt representatives:

Salaris per tipus de treball: Programador ABAP IV, Consultor SAP, Director IT, ...

Salaris SAP 2010 per funcions

Salaris per localització de la seu de la empresa EE.UU, Europa i resta; i per tipus d’empresa: Consultora de SAP o Client final

Salaris SAP 2010 consultores vs clients

L'informe complert el podeu consultar a One in Two SAP Professionals Expect Salary Increase in 2010, realment val la pena llegir-lo (cal donar el email per baixar-te l'informe en format PDF)

divendres, 12 de febrer de 2010

Reduir el TCO en canvis de versió de SAP i en implementacions de Support Package de SAP

En aquesta presentació de Panaya ens presenten la eina que han desenvolupat per reduir el TCO (Total cost of ownership) automatitzant els canvis de versió, els manteniments, i la integració d'aplicacions encapsulades utilitzant simulacions en súper ordinadors basades en Cloud ( el núvol).

Algunes dades interessants que dona en la presentació:
  1. Una mitjana de 5.642 programes a mida per sistema
  2. Quan es fa el canvi de versió a ERP 6.0 el % de programes estàndard que es modifiquen son: 64% per la versió 4.6C, 40% per versió 4.7 i el 31% per la versió ERP 5.0:
  3. SAP ECC 6.0 programes afectats en canvis versions
  4. Cost mig d’un canvi de versió: 1 Milió de Dòlars ( X 100K R/3 Systems = $100B!!!)
  5. Cost mig d’implantar un Support Package: 36K Dòlars ( X 100K R/3 Systems = $3,6B)


Desconec el Software de Panaya però les dades que presenta com a mínim et fan reflexionar que cada actualització del software te un cost enorme per les empreses i totes aquelles eines que es desenvolupin per reduir el cost d’actualització del software seran benvingudes per les empreses.

Exportar dades de SAP a Excel amb ABAP OLE

Otto Gold ens explica al seu bloc del SDN de SAP com exportar dades de SAP a EXCEL utilitzant ABAP OLE. Ja sigui utilitzant una plantilla creada prèviament a SAP o be creant-la des de zero i utilitzant XSL i XSLT per donar format a la fulla Excel. Tal i com ens exposa Otto, inclús podríem generar gràfics, aplicar formules, etc.. amb les dades exportades des de SAP.

La potencia de la tècnica ABAP OLE es que ens permet agafar les dades de la base de dades de SAP i exportar-la a una fulla Excel, sempre molt més amigable pels usuaris i útils quan l’usuari vol manipular les dades lliurement per realitzar anàlisis particulars; un cop exportades les dades a la fulla Excel, es pot executar des de SAP totes les funcions, gràfics, etc.. que tingui la fulla Excel. Es a dir, des de SAP podem controlar la fulla Excel que hem obert per tal que es generin gràfics o s’apliquin funcions, etc..

La limitació d’aquesta tècnica ABAP OLE es que el programa no es pot executar en fons, només es pot executar Online perquè s’instancia els objectes del PC del usuari.

Si volem exportar dades a una fulla Excel i el procés s’ha d’executar en fons, s’haurà d’utilitzar la funció XXL_FULL_API que genera un SAP Office a la oficina d’entrada de l’usuari; quan l’usuari obre el document de SAP Office s’instancia l’Excel i es presenten les dades en la fulla Excel.

Els dos articles de Otto Gold per aprofundir sobre l’exportació de dades des de SAP a EXCEL son:


Documentació per millorar la tècnica de determinació de missatges

The Smith Consulting Group ha creat una documentació força interessant per millorar la tècnica de determinació de missatges estàndard de SAP.

Les persones que no hagin aprofundit gaire en la potencialitat que ens ofereix el sistema SAP per millorar les tècniques de determinació, ja sigui de missatges, preus, etc.. trobaran força interessant aquest document perque ens explica tant la part de parametrització que cal realitzar, les estructures de comunicació a ampliar, com omplir els camps afegits a les estructures de comunicació i les rutines condicionals que es poden crear per realitzar condicions de determinació del missatge.

Si entenem la metodologia i els objectes que cal modificar i crear per millorar la tècnica de determinació de missatges, ens serà molt útil ja que els mateixos conceptes s’apliquen a la tècnica de determinació de preus en les comandes de SD, en les comandes de compres, etc..

Enhancing Output Determination

dimarts, 2 de febrer de 2010

SAP 12Sprints: col•laboració orientada a prendre decisions

SAP 12Sprints: col•laboració orientada a prendre decisions
SAP 12Sprints es el projecte de col•laboració orientada a prendre decisions de SAP.

¿Que es una col•laboració orientada a prendre decisions?

Portar ordre al caos i transformar el treball en equip en resultats d’una manera ràpida. La col•laboració orientada a prendre decisions inclou:

  • Persones – Portar a tothom a la mateixa pàgina


  • Informació – Compartir els documents i les dades d’una manera plana


  • Mètodes - Proveir una estructura amb eines de negoci per intercanviar idees, estratègies i prendre decisions.

En aquest vídeo s’expliquen algunes de les bases de SAP 12Sprints:


Si voleu veure més vídeos de documentació de 12sprints els podeu consultar al canal de 12Sprints de YouTube.

Timo Elliot en el seu bloc ens ensenya alguns exemples de com fer servir 12Sprints.com: Some examples of How to Use 12Sprints.com

Perquè i com l'empresa ha d’aprofitar el poder de Google Wave 2010

En aquesta presentació de Dagfinn Parnas, arquitecte de solucions i SAP mentor, ens exposa perquè i com les empreses haurien d’aprofitar el poder de Google Wave 2010.



¿Estem parlant de SAP 2.0?

dijous, 7 de gener de 2010

Picking a SAP mitjançant l’ajuda de la realitat augmentada

En aquest vídeo de SAPTV podem veure com SAP ha desenvolupat tot un equipament per poder realitzar el Picking amb l’ajuda de la realitat augmentada.

SAP Realitat augmentada ubicacions

Amb l’ajuda de la realitat augmentada els errors de Picking gairebé s’eliminen perquè al agafar el material de la ubicació el emmagatzemador veu per la pantalla si la ubicació de on està agafant el material es d’una de les ubicacions correctes.

Anàlisi computacional en temps real-real

En aquest vídeo de SAPTV ens introdueixen en el nou concepte d’anàlisi computacional de dades en temps real-real. L’objectiu del nou concepte d’anàlisi computacional en temps real-real es poder analitzar totes les dades necessàries, per exemple per aplicar-li un descompte al client, al instant mentre el client encara està dintre de la botiga.

La idea es basa en el concepte de enlloc de moure milions de dades del disc dur al processador per ser analitzades, emmagatzemar els milions de dades comprimides en memòries físiques on poden ser consultades en segons.


dimecres, 6 de gener de 2010

Metodologia ASAP de SAP

Una de les mancances que la Generalitat de Catalunya ha detectat en els seus proveïdors TIC, en empreses catalanes, es la manca d'una metodologia d’implementació de les solucions i una manca de metodologia per l'oficina de gestió dels canvis.

Dintre dels projectes SAP, un dels riscos més alts que poden provocar el fracàs de la implementació es una dolenta oficina de gestió del canvi i una manca de metodologia d’implementació.

Per aquests motius, avui, m’agradaria introduir, a aquells que la desconeixen, la metodologia ASAP (Accelerated SAP) de SAP AG per la realització de projectes. Tot i ser una metodologia de SAP, com podreu veure, pot ser aplicable per qualsevol projecte de qualsevol tecnologia.

Fases metodologia ASAP

Fase I: Preparació inicial del projecte

En aquesta fase es defineixen els objectius i l’abast del projecte. L’equip de projecte es familiaritzarà amb els fonaments del SAP ERP i el mapa de procediments ASAP. Es revisa l'esquema de hardware necessari.

El projecte s’inicia oficialment amb una reunió de llançament en la qual hi participen tant l'equip de projecte, els consultors implementadors com totes aquelles persones de l'empresa que son claus per l’èxit del projecte.

Fase II: Mapa de processos de negoci (Business Blueprint)

El propòsit d’aquesta fase, coneguda habitualment per Business Blueprint, es entendre els objectius de negoci del client i determinar els processos de negoci necessaris que han de permetre assolir els objectius marcats.

En les reunions executives es defineix l’estructura organitzativa i els processos de negoci a alt nivell.

En les reunions de treball de cada un dels processos de negoci, es defineixen els requeriments més detalladament amb els usuaris clau de cada un dels processos.

Les reunions executives i de treball son liderades pels consultors implementadors.

Per tal d’assegurar que els requeriments han sigut entesos correctament pels consultors, es presentarà als executius un ”Pla” del estat futur de l'estructura organitzativa i dels processos de negoci, en format escrit i en diagrama. Aquest “Pla” haurà de ser aprovat pels executius.

Fase III: Realització

En aquesta fase l'equip de projecte de l'empresa s’entrenarà en SAP per tal de familiaritzar-se en les eines, les ajudes, la interfase d’usuari i els processos de negoci de SAP.

L’equip de consultors implementadors configuren els processos de negoci en SAP definits en el “Pla” aprovat. El sistema configurat haurà de representar l’estructura organitzativa de l'empresa, el catàleg de dades mestres i haurà de suportar un flux totalment integrat dels processos del sistema. Una revisió dels processos de negoci de l'empresa amb l’equip de projecte i els usuaris clau de cada un dels processos permetrà confirmar el “Pla” aprovat i fer les correccions pertinents.

Paral•lelament, en aquesta fase es desenvolupen i proven els programes de interfase i conversió per migrar les dades del antic sistema a SAP. També es desenvolupen i proven els llistats i programes específics que necessiti l'empresa i que no existeixen a SAP.

Al finalitzar la fase, els usuaris clau de cada un dels processos de negoci haurien d’haver validat tots els escenaris de prova dels processos que son responsables.

Fase IV: Preparació Final

El propòsit d’aquesta fase es acabar les proves finals del sistema, entrenar als usuaris finals, i preparar el sistema i les dades del entorn de producció.

Les proves finals del sistema consisteixen en: provar els procediments i programes de conversió, provar els programes de interfase als sistemes actuals, realitzar proves de volum i estrés i les proves d’acceptació del usuari final.

Els usuaris finals son formats pels usuaris claus dels processos. Aquest mètode facilita que els usuaris finals acceptin millor la nova solució i també construeix la base de coneixement pel suport propi i millores futures del sistema.

En aquesta fase també es crea un estratègia per la Arrancada.

L’últim pas de la fase es aprovar el sistema i verificar que tota la organització esta preparada per començar anar a treballar en l’entorn de producció de SAP ERP.

Fase V: Arrancada productiu i suport

Immediatament després de la Arrancada, el sistema haurà de ser revisat i ajustat per assegurar que l’entorn de negoci esta completament suportat. Es realitzaran entrevistes informals als usuaris per verificar que les seves necessitats han estat satisfetes.

Conclusions

La metodologia ASAP accelera les implementacions de SAP, es molt completa i precisa pel que fa als documents entregables de cada fase i de les aprovacions dels processos i el “Pla”. Tot i que la metodologia sembli enfocada a la implementació del sistema SAP ERP, es aplicable a qualsevol tipus de projecte. Cal que en funció de les dimensions del projecte i del client ajustem la metodologia ASAP per tal que aquesta ens sigui útil com a metodologia de treball però que no ens faci augmentar en excés el temps i el pressupost del projecte.

Si considereu que la metodologia ASAP no s’ajusta al vostre tipus de tecnologia, al vostre tipus de client o de projectes, cal que busqueu una metodologia de treball que s’ajusti a les vostres necessitats. Potser en funció del tipus de projecte heu d’emprar una metodologia (ASAP), una altre (AGILE) o qualsevol altre. La qualitat del vostre treball es veurà notablement augmentada si seguiu una metodologia.

Fonts: SAP, Barcas Consultores

dissabte, 2 de gener de 2010

Implementar SAP amb èxit, el núvol, Iphone, certificació SAP i projectes fallits

Dels 10 articles més populars del 2009 de SAP a de SAP Watch Blog, destaco els següents pel seu alt grau d’interès pels Consultors SAP, caps de projectes SAP, responsables d’àrea SAP i Directors de sistemes d’informació:

1. Consells per implementar SAP amb èxit: Tips for successful SAP implementations

2. Moure SAP, hardware i tot, a el núvol: Moving SAP, hardware and all, into the cloud

3. ¿Qui vol SAP en el IPhone? : Who wants SAP on the iPhone?

4. ¿Es la certificació l’entrada a una implementació SAP amb més èxit?: Is certification the ticket to a more successful SAP implementation?

5. ¿Quina es la tendència real en projectes SAP fallits? : What’s the real trend in failed SAP projects?

La llista completa d’articles la podeu consultar a : 10 articles més populars del 2009 de SAP

¡Bon any 2010!