I wrote the DO’s part of my DO’s and DON’Ts SAP Cloud Integration blog last week. This week’s blog part II is about the DON’Ts and partly going against the good old, traditional ways of working in the (legacy) IT world.
So, kids, DON’T do this with the cloudy things:
- Start by writing an über-extensive documentation and waiting for having it approved by all possible stakeholders! This ties into the DO’s #3 and also #1: the integration itself is actually an extension of the standard SAP SaaS Solution and you primarily pick the features you want to activate. SAP provides literally hundreds of pages of guides and documentation, so forget about reverse-engineering SAP’s mapping logic into mapping excels, etc. but write and update as you go a high-level design document of how you are applying the SAP standard components instead. There can be – and we also implemented some – gaps to be filled by custom development, sure, so then you document those bits in the way the customer requires, business as usual.
- Keep the ITSM department in the shadow and bypass them when going live! Trust me, you do not want to keep the Landscape Manager (or equivalent) out in the cold about the fact that a Cloud Solution is not a traditional 3 (or 4) tier landscape! There is usually on one Cloud tenant, sometimes two before making cutovers, but in general only one. This tenant is then to be integrated into the 3 (or 4) tier on premise backend system (ECC or CRM) landscape and this can be against the general ITSM or customer’s practicalities, so be prepared for some confused looks and try to get some cover via DO #1. Also, do not avoid getting your hands dirty by skipping all the small and mandatory details such as setting up jobs for distributing master data well in time before the go live.
- Set up a traditional ERP project team with high emphasis for Project Management! There is nothing wrong with solid project management, but a successful approach in these cloudy integration projects is very lean. We had a project manager, yes, but this role was more of team captain than someone keeping detailed track of tasks and arranging status meetings – I believe we had none. A good SAP SaaS cloud integration project team works like a good jazz orchestra: someone is always covering for someone on the fly, the pace and rhythm of the work can and will vary and the roles can switch so that the freshest (I am avoiding the term ‘junior’ because our scale is well above the industry’s) member of the team is taking command and requesting things from the most senior team members. Getting back to lean, we were able to avoid a lot of waste in this project.
There! Three times do, three times do not. There is a lot more than this list when it comes to integrating SAP SaaS solutions successfully, so feel free to contact me for further info. You will find me on LinkedIn and in Twitter (@JanneVihervuori). I am looking forward reading your cloudy comment!
Happy May Day! Hyvää vappua!
