This is what I was doing some months ago.
I was working on a proposal related to a SAP technical upgrade and depending of the person I talk to, a different tools are recommended to me. This is just an initial opinion, probably when I gain more visibility it will be different, but by the moment this was a fanny situation.
For the technical upgrade:
Panaya: this is a tool that takes care so much about the look and feel. It provides reports (that can be done during the evolution of the ABAP remediation) showing information about the % of programs, functions… that requires remediation. The people that used it commented that they are happy of doing it: the client see how much effort is needed to test 100% of the application and really understand that we are not over-budgeting the project. For the IT people it does not provide any value.
Smartshift: the same concept than Panaya, but in addition enables you to correct different programs, replace obsolete functions and they guarantee that the 99% of the ABAP remediation can be done in a month.
For the functional remediation:
EMC Intelligent Cloning for SAP: enables you to copy data from an environment to other. This is very useful to perform the functional tests with the right data, you save time and some dollars.
Accenture Clon-Test: it’s mainly the same concept.
Last months I’m detecting an interesting trend from some of the young people of the team, and even from support team of a vendor. The issue is with regards to the approach used for solving support problems.
In a nutshell, they receive a problem, they look in google or other forums for a solution and if there is not a clear solution or a clear direction to the issue, they stay paralysed: they don’t know what else to do!!!
I was involved in deep in a stopping issue and when I was doing questions about the investigations done, I was so surprised about how limited was the approach used to find a solution to the problem.
There were not try error approach, there were not imaginative ideas to try to isolate the error ruling out sources of the error…
When I started to suggest tests to be able to see where was the root cause of the problem, people started to doubt about it, but suddenly the partial conclusions where ruling out causes and they were suggesting more alternatives. At the end of 3 hours meeting we found the root cause (not the solution) but it was a very positive session.
I’m probably getting older, when I worked providing service support we had not google and we the amount of information available was so limited. It made me to think and invent alternatives to isolate problems and look for solutions. It’s a natural approach for me, but for some young people the approach seems to be different
This document is a must read to understand how to work with MOSS 2010.
Interesting points for me:
1.- The complete picture of the ALM process.
2. – Release/upgrade versions process.
To reinforce these processes with the team, we will try some of these SharePoint templates.
Other Paul Auster’s book I have read.
In my oppinion it’s not the best one, but I have enjoyed it.
For the renewal discussions it’s important to review the basic concepts of each application support.
Just 4 main items:
- The nature of the business/application output,
- The real demand done to the application in terms of processes and technology.
- The high/low level of contacts with the customer.
- The changing nature of demand (financial closing periods, end month, application changes…).
There are other challenges (from a different perspective):
I’m reviewing ITIL concepts, and I found this picture I want to remind,
Do you leave your door opened?
Why cars have keys?
There are so many ways to check how secure is your password, for instance this:
Just do it,
I have listened this sentence so much times and each time I do, immediately I think:
1.- Eureka, I found the gap!!
2.- This guy does not know what is in his hands.
Unfortunately 80% of the times, I’m right.