Process Documents for BW Team Members

Does this sound familiar: I’ve just arrived at a new job and will be working with a BW landscape that is new to me. I’m comfortable with what I need to do but I know every system has a different way of doing it. [Yes, Really].

The software from a vendor (like SAP AG) is standard but it usually gets implemented with a twist, on a quirk wrapped in a lack of documentation. Some of the twists are a real eyebrow raiser leaving you with only the simple thought:

“why was this made so complicated?”

In most cases there will be at least two team members who have already run this gauntlet and are happy to share their time giving small pointers in the right direction. This is usually delivered in a quick one or two sentences that point out the right direction. A few steps forward and then bam, more questions.

This will continue until I am almost comfortable to say ‘Yes, I’m ready to do the work!’. Since we all see the world with different priorities; the activities and their sequence will vary greatly:

For some people this process is very short and the time needed to be fully prepared is actually spread out over the next 3 weeks; as the different activities appear for the first time.

The timing of when these activities occur can also be influenced by:

Making a good impression in the first week is harder by the time you get to ‘just one more little question’ number 46 and counting. The doubt sets in. Am I looking incompetent?. At the very least it can make me feel like an inconvenience; especially when I know I’m here to relieve the pressure on the team by delivering results.

Fundamentally we all know that there is an overhead to all new starters. This is an accepted burden before results are seen. There are too many different factors that go into this to clearly state ‘by when’ the first results should be appearing. Clear communication in regular catch-ups is the really the only effective tool to keep expectations and results closely aligned.

There is a way the little questions can be reduced, expectations clearly communicated and a reduction in the startup overhead. There is a way that time and money can be saved.

“build a Process Library for
BW Support and BW Developers”

It is a large collection of small documents targeted at questions and activities for the BW Support team and BW Developer team members, only. Not the business reporting user, not the basis team, not the enterprise service centre and not even SAP AG’s OSS support team. Especially not the ‘how to’ documents for using standard features of SAP Netweaver Business Warehouse, as they should be in an ‘Application Library’.

Hey, what, urgh, huummm … a Process Document versus an Application Document. What is the difference?

Once clear distinction is that the process library documents are very specific to the enterprise and will need significant modification to be used elsewhere. They contain very specific information that cannot be used in other corporate enterprises. The very best attempt to recycle the process library documents would be to use them as an empty skeleton, a template, highlighting all the information that needs to be filled in.

The application library documents are more generic to the software itself and can be used in many different enterprises with so little modification that you sometimes forget to re-brand them with a new logo. [Opps].

The Process Documents are the real time savers. You can prove this consistently with each new starter in the team by having them log their time for the first 4 weeks. Broken up into 15 minute intervals, what was the time spent doing? This post-mortem analysis of the time spent makes it very clear just how much time was spent preparing, setting up, configuring, installing and understanding versus doing the actual work you were hired to do.

The two benefits from doing this time analysis arise when you realise your expectations were not even close to what really happens and that each new starter has more than a 60% overlap in the topics they tackle. It is these overlapping topics that are unique to this enterprises business processes that should be given a higher priority to be documented:

By now you can see that a significant amount of the detail required for these topics is very specific to each enterprise. Each enterprise will also prioritise these topics in a slightly different way.

For Example: An enterprise with elevated network security awareness will not have VPN access, developer keys are rarely handed out and don’t even bother asking for transaction SE16 in the ECC production system.

For Example: An enterprise driven by tight service level agreements with steep penalties will value flexible co-ordination to ensure results; more than meetings, data models meeting philosophical alignment or programs running 2% faster.

As I settle into my new role within the BI Team; what process documentation can I create for the next new starter?