Graversen

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