SAP SM Blueprinting Questions – Service Processing

Home / Blog / SAP SM Blueprinting Questions – Service Processing

Now, onto more of the nitty gritty, what do you need to find out about the actual processing of the service orders.  In this part of the SAP SM blueprinting series we cover what do you need to find out when it comes actually performing the repairs.  So let’s get into it.

How many service orders do you process in a day/week/month?

It’s old fashioned, and I think everyone knows this, but I’d hate to skip over the obvious.  This question helps you gauge how to structure your processes.  Just having an idea that the service department processes 1 order every 2 weeks, or they process 25 in a day.  You’ll need to start thinking about how the service group will see their open orders, how they will notify other groups when they start or complete the orders, etc.  Simply put, the answer to this question will set the stage of what you need to do for all realization about the actual repair process that occurs.

How many different service order types do you utilize, and what is the purpose of each?

You may need to phrase this question differently depending on your audience.  The gist of the question is determine how different “types” of orders you process.  A type of order is anything that it is either tracked separately for financial or processing issues.  For example, if the accounting department needs to separate the costs of an Field service type order from an in-house order.  Sometimes, it’s purely fro reporting to know which orders need to processed ahead of others (for example, an in-house repair would need to be processed before the exchange orders that will just go back into your “spares” inventory.  Keep in mind, the more order types you create, the more maintenance you will be responsible, so like everything, drive to the minimum number of order types you can.

Do you break a single repair up into multiple smaller pieces?

SAP uses sub-service orders to accomplish the breaking of main service order up in multiple pieces.  This is especially useful when you deal with equipment that is broken into multiple pieces for repair.  This often happens with larger pieces of equipment that get broken down into more management sub-assemblies, each that need their own repair.  Sub service orders in SAP work great for this, because you are not allowed to complete the “main” service order until it’s sub-service orders have been completed.  So you can build an entire structure of orders if your process is complex.  However, remember that using these orders now doubles or triples the amount of master data to maintain for each order.  So if your shop is small, be aware they will have to do a lot more system work.  Short story, only implement if needed, and make sure that the people that will be dealing with day to day

Do you perform subcontracting for any service repair (in-house or external)?

Another thing to determine is if you have to worry about any subcontract or 3rd party to do work on a part.  There are several different ways that you subcontracting impacts the service order.

  • The first way is that you need a component that is purchased.  In SAP, if you don’t have the material in stock, it will generate a purchase requisition for the component.  It may also be for a part that is not maintained as a material master in your system  (this could be something like ordering hammers for the field service tool belts).
  • The next way is that you may send the part being repaired (or a portion of it) to an outside vendor to perform a specialized service or process that you do not offer.  It could be special diagnostics or tooling on the part.  This again requires a purchase requisition.
    • do you need to see that the inventory has left your facility?  In SAP, you can implement the A&D solution to actually perform the material movements and SAP deliveries to show that the part has left/come back into the facility.  This is very nice functionality, but keep in mind that it has limitations, and it adds multiple additional steps to the process.  Find out how necessary the requirement is perform you promise it.  It requires certain enhancement packs to be installed and activated, so if you go down this path, you’ll need to work with the basis/development team to accomplish this.
  • The next thing to consider is, do you use a 3rd party service center to do the entire repair.  In this event, please check out my post on Warranty Claims:  SAP Warranty Claims: A Guide for Beginners

How should the costs be broken up?

The cost breakdown is simply the broad categories that display on the service order as you do planning or actual hours & components.  Some of the common breakdowns include:

  • Labor
  • Travel Costs
  • Components
  • External Components
  • etc…

Remember, these categories have no impact on anything financially.  It is simple “buckets” that the particular cost elements are grouped into to.

Do you perform repetitive service tasks for certain products?

This question is related more to master data than service processing, however it fits much better into this portion of the blueprint.  It’s important to find out if your client does repetitive steps for a particular repair.  This could by service material (service process) or by serviceable material (material that is being repaired).  If the same steps are performed every time, you need to set up General Task Lists, and teach the business how to use General Task Lists.  If you are not familiar with these tasks list, it’s simple a routing and component list that can be automatically copied into the service order upon creation.

How do you need to track your time entries to the service order?

This question helps you drive to the answer of if you need to pursue CATS (computer aided time sheets).  CATS is a useful tool if you use SAP to handle your payroll and your service orders.  Keep in mind that the standard time entry tools for service orders (IW41, IW42 for example) can handle entering in personnel numbers, multiple confirmations, etc.  CATS certainly provides better reporting, and looks more like a time sheet for your employees entering their time.  CATS will certainly require a lot more configuration, including setting up an organization structure (often a difficult and controversial topic for any organization).  As a general guideline, I will steer clients away from CATS unless they have solid reasons for using it (often if the client does Project Systems and Service, both will want to use CATS, then it makes sense to use CATS).

If you perform service at the customer’s location, who enters in the time and material for the job?

This question is typically more business process related, but it is certainly information you need to know.  The reason it’s important is because you need to know if field personnel will be entering in their own time and materials, or will they be emailing, faxing or mailing in their time sheets to someone in an office who will enter it for them.  If they intend to enter it in the field, you need to know if they have internet connection in the area.  In our day and age, most places have internet coverage, however there are still locations on our globe that do not have easy connectivity or have very weak or slow connections.  In that event, you need to be very sensitive to making someone log into SAP, if they are using just a 3g network.  You may need to look into a web interface that provides a small amount of bandwidth to get the confirmations entered.

If you perform service at the customer’s location, do you ever send components for a service job?

This is one of the famous loaded questions you ask.  It’s pretty rare to do service and never send components.  The reason for this is to determine HOW you need to handle the components.  There are several common ways to handle this.

  • The service technician is located at the office or a plant with parts and takes parts with them to the customer.  In this event, the technician simply issues the parts to the order and removes them from stock.  Packs them up, and takes them to the client.  If there are extra parts, they are returned to the warehouse after the completion of the job.
  • The service technician maintains “trunk” stock.  This simply means they have a list of stocked components with them at all times.  These “trunk” locations are typically a storage location in SAP.  Then the stock is issued from their SLOC to the order.
  • The parts are shipped ahead of the tech by way of a sales order/delivery process.  They are shipped directly to the customer, perhaps as a no charge order, but this again needs to be determined by the business.

If you perform service at the customer’s location, do you perform scheduling of your technicians?

Now this question will often get a quick “Yes” from the customer.  However, you need to dig into the how.  Many clients simply track their techs on MS Outlook, Excel, or the big calender hung in the boss’ office.  Now some clients have a far more sophisticated method to track their people, and when they are available, but you need to know what level of complexity you need to implement.  In addition, you need to find out if they track the travel time, how are the tech’s schedule maintained?  Is there an automated connection to the call center?  Do they schedule “real-time” with the customer? Who has access to view this?  Do they track skills of each tech to determine who can do what?  Keep in mind, to implement this in SAP is usually a very custom solution requiring quite a bit of development.  SAP does offer a solution, but it is an add-on, and last I looked into it, it is only for CRM.

Do you perform any service parts planning?

Service parts planning can often mean a lot of different things depending on the client.  Some of the things you need to determine are:

  • Are the parts being planned independent of the production demands?
  • If it is a shared stock, who wins?  By that it’s important to understand in the event of limited stock, does a sales order get the stock, does service get the stock or does production get the stock?
  • How do you forecast service demands?  How much history is currently used to determine the service forecasting?

Alright, here’s the stuff I can think of related to service processing.  As always, I welcome your comments on anything I missed, or even anything else you would like me to cover…  Next time we’ll talk about a few of the remaining “oddball” items, such as forms, technical stuff, and financial stuff.

Thanks for reading,

Mike

As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,
Mike

Leave a Reply

Your email address will not be published. Required fields are marked *