Welcome back. This is the last piece in my series on talking about SAP SM blueprinting. This last edition will focus on the Technical aspects of service management. So let’s get right into it.
Forms
This is the biggest piece of the technical aspect of Service Management. When it comes to service there are a lot of documents, but it all depends on what the business plans to use. First off, for every document, be sure to get sample documents for EVERYTHING that the client says is required. During realization, you’ll need to analyze every one of these and determine the mapping of old to new data. Here’s the forms you need to consider:
- Service Quotation: Does this look just like a standard sales quotation? Are you use RRB to determine the detailed cost of the quote?
- RMA/RGA paperwork: Does this come from the notification or repair sales order. I will recommend using the repair sales order, but I’ll leave that for another post :). Does this look like an order confirmation or is completely different?
- Service Order Paperwork: There’s a bunch of options here that come standard in SAP.
- Time Ticket – do you need this print out? should this look like the production order shop floor papers?
- Pick List – is this something that should be printed? who does this work, does the repair group pick their own components, or does the warehouse?
- Shop Floor Papers – do you need this print out? should this look like the production order shop floor papers?
- etc.
- Invoice – Do you need a special invoice for service? Again, I always suggest to avoid this if at all possible.
Technical
This is the piece is the easiest part of blueprinting because you should completely skip it. Don’t start talking user exits, BAPI’s or anything custom at this point. This doesn’t mean to ignore the stuff, but initially, save this until realization. Remember, you don’t need to solve every problem, for now, just collect them all.
Interfaces
Interfaces are anything that needs to link into SAP, but is not part of SAP. The most common example of this is Taxware/Vertex. Now there may also be existing websites that link into the existing system, there may be some external part planning, an outside application to handle scheduling, etc. I personally always dislike this part because it tends to be the biggest headache. Your biggest goal is to figure out everything that needs to come into SAP, and more importantly, determine if SAP can handle this with standard functionality so the interface can be replaced with SAP. Be sure to get as many details as possible, including functionality and what information is exchanged between systems. This is likely to be a time consuming piece of realization to get all the details and possibly design a technical interface to replicate the old behavior.
Alright, this wraps up everything I have for the blueprinting. If you have anything I’ve missed, please let me know. I always hope to learn something as well.
I’ll be back soon,
thanks,
Mike
Mike