Skip to Content

Intro

This is not meant to be a rant, but an observation based on many projects over the last 17 years, and a feeling that basis is often forgotton or is an afterthought. Basis does IMHO provide alot of value add which is often forgotten.

Have we ever seen a properly staffed technical project team?

How many times has a project been started with a single architect, who is expected to know everything in the most minute detail and couple of generic basis consultants with no product specialization.

I’d guess most projects start that way.

Unfortunately the powers that be, i.e. the guys who put the project plan and team involved, generally sit in the old world of SAP when it comes to technology. All we do is install and monitor????

“SAP Basis” has moved on.

The days of just having an R/3 system and maybe a bit of BW have long gone.
System landscapes have become vast, with a high number of SAP components. The SAP components themselves have not stood still and require specialized basis skills. Your generic “Netweaver” administrator will no longer do.

An example: Due to tight deadlines and multiple go-lives you may well have a 7 system Landscape. Development, Quality Assurance, Pre-Production, Production and parallel development and QA systems. Maybe even a sandpit system thrown in somewhere.
Now each environment consists of, ECC, BW, BO, CRM, SRM,PI,EP with associated java and abap stacks, so you are easily in the realm of 12 individual applications per environment. So from the start you have 84 different installations to worry about. Then of course you have Solution Manager to look after the whole thing.

Solution Manager 7.1

In the past Solution Manager was generally seen as a necessary evil, that SAP insisted on, but was generally ignored, but with the release of 7.1 it has become a bit of a game changer. Unfortunately Solman is seen as being a “Basis” only system. It is much more than that.
It has a dual personality, Functional: i.e. documentation, configuration management and change management and technical: Alerting, monitoring and transport/correction.

Solution Manager has become an application in itself, therefore it requires the same disciplines and any other functional component, i.e. it requires a scope to work towards, a blueprint phase with business/project involvement and a realization phase.

Note that above I have seperated change management from transport & correction. Transport and correction is the technical basis on which Charm is based, but the Charm functionality is governed by the business and IT change management policies.

Techno-functional

When you look at an initial scope document, you generally only see application components in the landscape, with no reference to add-ons, Enhancement packs, etc.
Your average basis bod, has no idea that SRM self service may require the SRM-SUS component. The Basis technical architect will be concentrating on HA/DR/backup strategies. Making sure that the hardware is on the ground/VMware is configured, SANs are properly setup, etc, etc, etc.
In an ideal world the functional leads/Solution architect will know exactly which components are required and will pass these to Basis as a requirement. Alas that does not happen, you only generally find out something is missing once the functional consultants start configuration, which may well be too late. So there is a requirement for somebody to sit between technical and functional. A technofunctional architect.

Ideal team

So when thinking about the above what would the ideal team look like.

  • A technical Project Manager
  • A technical architect (full time)
  • A techno functional architect (during blueprint and start of realization)
  • Basis team consisiting of
    • WebAS (Abap & Java) administrators, 1 per 7 systems, so in the above example 12
    • WebAS+PI basis bod, i.e. has some in depth knowledge on how PI works
    • WebAS+BO/BI bod (still a young product in the SAP suite so requires specialised basis knowledge)
    • A Solution Manager (technical) expert
    • A Solution Manager (functional) expert

The specialized functions can be part of the 12 strong basis team.

Summary

So a question: How different does that look to the current make up your your Basis team on your project?

Yes the above will cost alot of money, but it is something that we have to push towards. Training budgets are non existent these days, so we are expected to pick up additional skill outside of business hours, however given the small teams and vast landscapes we have to manage, we have no spare time outside of business hours.
Basis may do the impossible sometimes, we may have brains the size of the universe, but we do need some sleep and a drink or two to keep us sane.

So when your Technical teams look like crap, and are crying out for more resource or specialized resource, please take into consideration that we don’t know everything, we do need to to learn stuff and we need to deliver to an impossible plan. Consider everything we do and staff the project properly.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply