Business Process Modeling (BPM) is proven to be a challenge when it concerns SAP Transportation Management 7.0. The flexibility of the system is wonderful from a business point of view, but it doesn't make the life easier for a business process modeler. How should an consultant act when he starts a BPM-process with a customer that is inexperienced with working with SAP TM. Written from field experience.
For a consultant it is quite hard to get an hang of all the new terminology regarding TM. Shipment request, Freight request, Shipment Order, Freight Order, Booking order, Shipment, etc, etc. When it is difficult for an consultant to get familiar to all those concepts, imagine how this is for a customer. Keep this in mind when you start with a customer on BPM. Therefore it is required to make something like a dictionary of all the important terminology that is being used when working with TM. When giving presentations about TM use a lot of slides when explaining these concepts and make it as clear as possible what the differences are. Repeat, repeat, repeat. That is what is most necessary. After a while the customer will get familiar with the terminology and will see the distinctions.
When working with TM you will start to notice that several processes can happen in a different timeframe. And the process can have different outcomes dependent on choices that have been made. For example when we take a look at planning. It is possible to start planning from the Freight Request, the Shipment Request, the Freight Unit and from Selection Profiles. A part of planning can be the transportation proposal. When a transportation proposal is generated it can be saved as transportation constraints which will be taken in consideration when detailed planning takes place, or it can be saved as planned transportation activities. For these "can's" and "if's" it is hard to capture reality in a business process model. Therefore one should not concentrate on being complete in making the model. BPM became an import field of expertise, because it generates an abstract view of reality. Because it is abstract it will always fail to capture the complete reality. It is merely a tool to make reality understandable and to discuss about what reality is and how it should be. Realizing that a consultant shouldn't always pursue to be complete from a SAP TM point of view, but should try to capture the requirements and whishes of the customer. In this case content is much more important than form. Because the system has so many options on how one can work with it, it is important to start from the business perspective. Especially with TM the question should not only be ‘how should the company work with the system', but ‘how should the system work for the company'.
When working with a customer on the BPM-model at first the focus will be on the customers' processes and requirements. At some point the customer will need to know how the system works. When this knowledge is only transferred by written text, stories and powerpoint slides this need will not be fully satisfied. There for it is wise to give demonstrations on a working system. This system won't have to be configured to the customer requirements. Only a basically working system with standard processes are very helpful for the customer to get a touch and feel with the system. Also during the project it is helpful to configure a working system that at first only supports basic processes. Give the customer access to that system as soon as possible. He can start building up knowledge and experience on his own and will start to explore the system to get more understanding of the objects behind the terminology that is being used. Giving training to the customer and giving an hands-on experience at a very early stage is something that will valued by the customer and that will speed up the whole process of designing the system in detail.
