Skip to Content
Author's profile photo Daniel Graversen

Integration expert in the process teams

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Susan Keohan
      Susan Keohan
      Hi Daniel,
      A boss of mine once had every new programmer go spend a week or two in the AP/AR/whatever group they were going to work for.  The idea was, sit in their chairs, do their jobs for a while, and you will have a much better understanding. I think you've updated that idea - working with the process folks is extremely educational.
      Author's profile photo Daniel Graversen
      Daniel Graversen
      Hi Susan,
      It sounds like a really god practice. It would also make sense to have some time to learn what the busienss is about before pushing down our (as consultants) idea on the solution.
      It it to expensive to spend time to learn the business?

      I got a trip around the distribution center where i learned some of the different terms phyciscal it was useful for understanding of the terms. But I had not been a part of the team I and not seen this.

      Author's profile photo Former Member
      Former Member
      Hi Daniel,
      This is similar to technical people being involved in requirements workshop which I think is invaluable.  For example, at one utility, I spent half a day in a the call center which handles Cable Television calls, then the other half going out following the sparky doing Cable installations to understand the business in order to work out the optimal solution.  Although they were the experts in their processes and others were the experts in modules such as SD/PM/MM to handle these types of functionalities; this knowledge was invaluable.
      From an integration perspective; the best standards/interface agreements in the world will still not work if you let two separate technical teams work together on their separate parts without someone almost functional sitting over the solution.  Although the interfaces may communicate perfectly with each other; if the business process isn't aligned; you can be in big trouble.
      Another perspective that always gets to me is when you get developers who develop a solution, but do not know how to create the data to test their solution in unit testing and blame the functional team for this.  This ultimately always results in un-tested solutions failing in integration testing.
      In short, I was forced into a process role early in my career during a large custom build that I also owned the development of; and although I'm still very technical, ever since this, I've never looked back as this is the way to go.