I wanted to elaborate a little on the topic of BASIS administrators for Installations, last time I wrote on the topic of BASIS I received a number of responses, some encouraging, some with chastisements and of course the usual comments that I can only categorize as, ‘you just had to ‘say’ something didn’t you?’
At any rate, as I have said before, these are my observations and my thoughts, they reflect years of experience with all kinds of skill sets and resources and while not exhaustive, I thought I would share them because only through sharing can we all learn together.
Last time, I said, that installations includes a need for understanding things about sizing your SAP system; understanding tools like the quicksizer and what vendors do, and don’t do for you in terms of sizing. Sizing has been by far and large the most problematic installation aspect that I have seen in projects and is probably one of the most critical yet weakest areas in project BASIS.
In the oldest of days, the selling of hardware was where the money was to be made and by and large that trait has been replaced by professional services and implementation costs in new projects. The hardware is still important it is just that it is considered as something that can always be upgraded. Bad implementation is more difficult to upgrade unless you scrap all work to date and start over.
Back on my first SAP project I recall we used a supposedly comprehensive project estimator but quickly resorted to a cobbled together set of metrics to determine what our SAP project was going to cost. Very quickly the project was split into four core aspects. The cost of the hardware, the cost of the consultants, the cost of infrastructure renewal and the cost of redirecting internal resources to work on the project.
Generally if you’re engaged in a new project, all four of these cost elements will play into the budgeting exercise however for renewal projects you may get away with just consulting and internal resources, this all assumes you budget for infrastructure and hardware as part of your standard operations activity.
I don’t recall that we explicitly ever considered a ‘technical’ consulting resource other than functional leads and consultants but when we were presented with the manpower proposal for the project there was this line item for BASIS resource. THe individual concerned proved to be invaluable not only in assisting us in getting the project off the ground but also in terms of triaging unexpected issues and in retrospect had we taken any kind of hardline against this resource being a part of the project team, we most certainly would have suffered greatly, or failed.
BASIS resources seem to be among the most expensive of the manpower resources in the project, more expensive than project managers and functional leads in some instances. When BASIS resources are engaged as technical architects their rate per hour becomes stratospheric and so the inclination is often to shed these resources as quickly into the project as possible. Be prepared for this cost and don’t assume that just because they are expensive they can and should be rolled off as early as possible.
On a variety of projects I have been involved in, we would redirect existing system administrators to learn how to ‘become’ BASIS admins or we might hire in resources. Don’t assume that your existing infrastructure architects have enough knowledge to supplant the BASIS architect unless they have prior experience with SAP.
If this was a green fields implementation you would always have a contract BASIS resource in addition to internal staff (SAP trained or not), because they would normally bring prior expertise with them and part of their role would be care and feeding of the project, training internal staff and providing thought leadership around the project and implementation strategy from a BASIS perspective. Sometimes IT system architecting comes as you build, who better to do this, than your BASIS resources on the ground.
My experience though, is that you need to ensure that this resource has a strong personality, not necessarily abrasive, but they do need to know their stuff, they need to have good analytical skills and know where to get stuff when they have a problem. A new resource like a contractor will have a tough enough time navigating the quirks of your organization and if they are paper-qualified but relatively inexperienced they will quickly get out of their depth if the clamoring resources internal to the project cannot get their questions answered and problem solved.
While it is admittedly suboptimal, initially at least, the BASIS resource invariably becomes a quasi subject matter expert on security, hardware and basic application functionality – the go to guy (or gal) for pretty much everything that is needed or doesn’t seem to work. Accordingly, a full in depth understanding of the complete technology stack is key to their success.
As you will see from some of the comments in my last blog on this topic, quick installers are all very well when they work, but sometimes they don’t; your BASIS resource is going to need to work out why, perhaps edit some scripts, change some database or operating system parameters or any number of other things. Typically they have seen some of these issues before but if, for example you are an SAP rampup customer or you are working on new area of the SAP product stack, any number of new variables are now introduced into the mix, that make it difficult for a relatively green BASIS resource to be successful.
The other thing that I have picked up about installation BASIS resources is that they, like anyone else, will happily delegate work to any number of minions in your organization if you decide that is what you want to do. This is potentially extremely dangerous because essentially you’re allowing them, no matter how professional they are, to somewhat absolve themselves of some of the responsibility for what is deployed. Of course professional people will do their utmost to resolve any issues that come up, but you do really want to consider a situation where they are the doers and your own inexperienced people are the observers and helping hands. Documentation is key here, and getting examples of documentation previously undertaken can help you in understanding how meticulous this individual is. Rock stars vary in their quality of documentation though and so, under some circumstances your supporting staff being in assistive roles, help in ensuring that you end up with good documentation.
Documentation to my mind, is like configuration rationale. How did we arrive at the decision to implement x number of application servers? What influenced or made our decision to buy x hardware vs y hardware. Why is this parameter set to such and such.
I’d also say that some installation BASIS resources are great educators, they have a great ability to communicate concepts and are willing sharers of information, coaching their peers and your employees as part of the installation project. Getting a prospect to communicate a concept to you like their IDES setup methodology will help you to understand whether they are grounded in the concepts and able to mentor your staff.
When your integration partner(s) bring BASIS resources to the table, get the functional leads and project manager to make suggestions about the relative strength of the resources you have been supplied, for a new project I wouldn’t consider a BASIS resource who doesn’t have at least five green fields verifiable implementations under their belt, preferably with similar hardware, the same module components and similar project sizes. These days they also must have solution manager experience and a good way to test that, is to get them to describe the role of solman in the project and how they have seen it used. Getting your BASIS resources right at the outset is a key success determinant in your project, too little expertise and weak experience will ultimately manifest itself when you start your load and performance testing by which time you will have made system configuration decisions that may be hard or challenging to undo.
As a concluding thought on this topic, I also would like to say that like any consulting resource that you use, your BASIS resource needs to be managed, you need to communicate clear expectations and if you aren’t sure, get the consulting resources to make suggestions for timelines, deliverables and measurements. They will be expected to leverage best practices, demonstrate experience and understanding of the RunSAP and ASAP methodologies and be quite familiar with Notes, service market place and customer support messages. BASIS resources for installations are mini project managers who function as individual contributors in addition to being planners and firefighters. When your project is just starting out, they are often the resources who work late into the evenings and on weekends to get the environments up and running for your sandboxes and POCs and they’re also the resources that will invariably test the resiliency of your change management, incident management and backup mechanisms.
http://scn.sap.com/people/clinton.jones2/blog/2011/05/10/the-basis-administrator-you-get-what-you-pay-for-part-ii
