Graversen

I have been going to the Formula One Grandprix for some years. I have always enjoyed staying at the campgrounds. It is a mix with people just wanting to party, have fun and be creative in coming up with campgrounds. I like going there to be reset and see what is possible and get some time to relax. Plus enjoy some loud noises and some racing.

Now this year the German Grand Prix is in Hockenheim, close to SAP HQ in Waldorf. It is on July 23-25 2010. So I thought that some other SAP professionals also are going to the event. It could be a great place to network and met other people who have a passion for SAP and motorsports.

It would be fun to catch up with some other SAP professionals, so if you are going to the Grandprix drop a comment and let’s find a time to get something to drink or something to eat. I do hope to get a lot of responses, and then we might even be able to create some kind of a camp.

Uncategorized

It seems like the company Okuma Group is trying to move into Denmark also. They have some well spoken sale men that are trying to sell their products. They expect the stock of Trina Solar Limited to go from $20 to 40 or 50 in a couple of months.

They have also tried to call German speaking countries like described on Amazingly elaborate fraud scheme: Okuma Group.

What is interesting is that the company name domain is only registered on 12 feb 2010 according to WHOIS. And even better it is register to an anonymous user. It does not sound trust worthy.

They news list is not real trust worthy it only dates back until July 2 2010 and only contains links to other analytics.

They also offered a less tax way thru clearing houses exotic places. Wander if you would ever see the money again.

Uncategorized fraud, investing, okuma group, trl, warning

When I was still working with a larger SAP implementation project, I have always been a part of the integration team. Most of the time I was sitting together with other integration consultants and discussing work stuffs on how to be more productive with the business. It was really great because we have the opportunity to discuss different things regarding better solutions. However, from a service perspective, it can be done better.

On my current project I have moved to the inventory or warehouse team. I consider them as my primary customer whom I need to help with various Warehouse integrations. After I have been a part of the team for some time I have learned a lot on what the processes are. I’m still a part of the integration team, but sitting on a table with a warehouse team instead. It just started with me sitting in there for a day but as time passed I realized I just got stuck with the routine.

Being on the team means it is much easier to learn what is going on and what is going to change. I can track their schedule and what they expect to be working on, so I can focus my attention on that aspect.

A large part of the difference is that communication is way better. I have a better understanding on what the team wants and can quickly adapt the solution to match their needs. The speedy pace of making changes is really crucial in the test or late build phase where the final adjustments should be made.

The thing I’m missing is the ability to learn what’s going on with the other integration solutions. I’m not getting as much information on what everyone else is doing and help them with their tasks. This could mean that our projects might not create as a uniform integration solution across the board.

It would probably make sense to have some meetings in the integration team, where we talked about the different solutions we are making, to make us share the knowledge across all participants.

If you have the option to be a part of any of the process teams, I would surely recommend you do it. You will be able to provide them with better and faster service.

I guess that this also apply to developers in general, if any of the teams provides enough jobs to be able to work on them.

Do you have any experience in being in the process team, and would you like to share some of your thoughts on it.

Uncategorized

I have been talking with Rasmus from http://my4hours.com/. He has the project of implementing Timothy Ferriss 4 hour work week. There is still some time to go but he has started the journey. I hope that I’ll be able to learn from him, and optimize my life.

I’m currently considering hiring someone from the Philippines to help with my work. I will have to see how it works.

Uncategorized

I have just upgraded to wordpress 2.7 and applied a new theme. I like the upgrade procedure, eventhough I deleted to many files and the theme. I would like my products to be just as easy to upgrade.

I like the new design, and hope to use it a little more.

Computer, Uncategorized wordpress

I have finally found out what SAP is. Just look at this bottle from Belgium.

On the side the 100% logo is together with 100% Jus.

Uncategorized

I have not been a fan of the scenarios created in XI and PI. I have mostly used the scenarios to document objects, which already had been implemented. By adopting this process the scenarios was often lacking functionality or missing important objects. The scenarios served mostly as a form of documentation, for PI developers with less knowledge of the interfaces designed.

My main reason for not using the scenarios was the following.

• They could only be used to configure some objects in the auto configuration phase. It was not possible to generate a sender agreement, which then had to be created manually.
• When new scenarios had to be configured, partners and systems should be selected. For configuring just a few objects.
• The scenario cannot configure all necessary objects to be used. It is something like “Exactly Once In Order” sequence and routing rules.

With the above reasons it was I was not very excited about using scenarios in PI projects. Fortunately my colleague Emil Jessen, had a lot of ideas on why to use scenarios. The primary reason was to use them as a dialog tool to communicate integration processes with the business teams. The other reason was to use them for auto configuration of objects.

The scenarios should also make the hand over to the customers own people easier. They should be able configure the test and production environment and thereby have ownership of the solution. They did unfortunately not have the time for the configuration part, so we could not see how it worked.

The main focus was on creating a way to communicate, how we pictured each process and the messages flow in the process. The swimlane diagram is easy to understand since it deals with interaction between systems. It also described how the flow was when using BPM’s.

The use of models is going to get much more used in PI 7.1. I have tried to use the functionality as described in this blog. In PI 7.1 the models can get more complex and be used to describe how the business works. I’m looking forward to see if the models in PI 7.1 can give a better understanding of what is going on or they are too complex for the application consultants.

To streamline our use of scenarios the following guidelines was created.

• The scenario should describe a process and the scenarios should be named after the process.
• Scenarios was created in the beginning of the realization phase and populated with dummy actions until it had been defined each action.
• Actions should be marked as with start and end action(s).
• Actions used in a scenario should contain a description. This description should contain information on what the action is doing. It could be send message, provide lookup service, consume lookup service and send message. And then a more detailed description on what the interface did.
• In descriptions for actions and scenarios the technical specification number was added, it was therefore a lot easier to find a scenario by using the search functionality.
• Actions can have multiply interfaces, which could be used in different scenarios and in different ways. As long as the different message does the same it could be an IDOC and an BAPI, which both creates an invoice.
• Communication channels temples should be places on all communication channels, which needed a sender agreement.
• All configurations of scenarios should be done by using the scenarios, except where the limitations are as described below. This mean that it is easy to reconfigure all interfaces in a PI system, simply delete all configuration objects, except communication channels and then auto configure everything.

A scenario could look like the following. Emil had also taken the time to translate the actions to English.

It is easy to get the auto configuration for work for sender agreement, but was not documented where I looked. The solution is simple. Just place a Communication Channel Template on the sender side in the Connection between actions like showed below. It is then possible to select a communication channel in the configuration. Venkat Donela had a blog where he describes how to use the communication channel temple, I was just pointed to this blog recently.

We still need a way on how do document, which changes there need to be implemented after the configuration has been performed. This could be creating Routing determinations and the sequence for interface with EOIO. We have currently documented them in our cut-over plan, so we know what to do when we go live. Have anybody solved this problem.

I got a comment about the diagrams from one of the application consultants. He thought the diagrams were a nice way to represent what did happen in the interface. For them it looked like the solution maps, which they where use to see. It was nice to know that the diagrams could be used by the business experts to show what we were doing and we are on the right track in with the development.

Uncategorized, modeling, pi

I have this week certified as a Scrum master, after a two day course. And I will therefore like to share, some thoughts on, how I think Scrum can be implemented in SAP projects. I have no experience in project management except for at team level and being a participant in SAP projects.

Scrum is a framework designed for Agile projects. The article “Scrum in 5 minutes”, gives a pretty good understanding of the concepts. The basic idea is to make prototypes, add business value continues during the project and remove impediments.

The opposite of scrum is the waterfall method with separate phases for each task like specification, analysis, design, implementation, test and deployment. The waterfall model has some challenges.

• The business or customers does not have a complete idea of what they need before the see how a model works. This result in change requests along the way, which is more expensive the later in the process they are found.
• Features is requested that is never used a study published in xp2002 showed that 45% of features in software is never used.
• It become more difficult to change or correct something, in the later stages of the project
• During the test face everything has to work and then fixed and retested.
• Hand over between the different faces requires a lot of documentation, which can be difficult for other persons to understand or requires a lot of time on creating.
• The method assumes that we do not live in a complex environment, where changes does not occur.
• Often has overrun in time, price or bad quality.

I would say that ASAP is a clear waterfall method, with a analysis, implantation, test and go live face. ASAP contains some accelerators and templates to assists in the implantation. ASAP therefore contains most of the challenges stated above.

Scrum acknowledge that it is not possible to plan everything into the future and is therefore using 2-4 weeks iterations, which each have to result in a “workable” product. A large part of the framework is dealing with how to prioritize the most imports features from a business value perspective. The target is to create hyper productive teams, which produce more business value per resource.

A study done in Systematic , a CMMI5 company (so they must know what they are doing), showed that it was possible to halve the project cost and provide better quality than a waterfall implementation with Scrum.

Scrum can probably not save the world of projects. Like all other frameworks Scrum has some challenges, which can cause problems with the implementation.

• First of all organizations have to acknowledge they cannot plan feature the want in advance.
• Many organizations leave parts of the framework out; this will not result in a ScrumBUT with a lower productivity.
• The organization has to believe in the scrum approach and leave the groups alone in the sprints. If not it can result in lower production and a product which does not provide the correct business value.
• Other revenue models have to be created for consultancies, to adopt Scrum instead of a high paying waterfall approach.

I’m currently trying to figure out which parts of Scrum, we can use as an Integration Team in an implementation project. It will result in a ScrumBUT, but it will hopefully provide some experiences on how projects can be managed, from a micro level.

Do you have any experience in running Scrum in SAP implantations, and would like to share some experiences about it?

Uncategorized