The Service Management Experts
Menu

SM

Home / SAP / Archive by category "SM" (Page 17)

Service Management – Adding Multiple repairs on the same repair sales order

Now, if you’ve been doing this for a while, I’m sure you’ve encountered this issue.  The customer sends back multiple repairs for the same order, however, service notifications can only contain a single material/serial number.  Now, I’ve heard rumors that in EHP4 or EHP5 there is something that can be activated to allow for multiple serial numbers, but I haven’t seen this yet, and for most of us, it isn’t an option anyway.  Because of that, we resort to alternate processes 🙂

Adding another repair to the same sales order is pretty easy.  You must need to make sure you fill out 4 key fields.  Material (this is the service material/DIEN), qty, Servicable Material (this is the material you are fixing), Srv Qty (this is the qty of units you are repairing in a single service order).  That’s it.  As long as all your master data is properly setup, you’ll be good to go.

Now a couple of words of warning.  First, your notification will not track to any additional line items you enter on the repair sales order.  By that, I mean that if you do a lot of work/information gathering at the notification level, the document flow may not be reflected accurately.  This is because in SAP, the notification number is at the header level, even though the actual repairs are at a line item level.  Certainly not the end of the world, but it can be confusing, especially if you rely heavily on document flow (like I usually do).  Another point on this is if you are dealing with warranty/service contracts.  Only the material/serial number entered will be checked.  So if there are 5 items, only 1 of them will be checked automatically by the system if you do it all in a single notification.

Second, I always encourage using a quantity of 1 for every repair.  There are exceptions, but often the clients I deal with want their units back as quickly as possible.  If they send you 5, and 1 of them takes 2 weeks extra, they want the 4 that are done.  Well, if you load the qty of 5 in the sales order, that means you only get 1 service order, 1 inbound delivery, etc…  You could get fancy and split things up after the fact, but it will get messy and much harder to trace.  If you were to set up 5 repair line items, you could should them each as they are completed (or you could even do complete delivery).   The important thing is you have the option.  If the group of materials sent back are only useful as the qty 5, then by all means, do a single line.

Those are the quick ins and outs.  We are have an SAP app that does have one approach of connecting multiple notifications to a single repair sales order line item.  The drawback is that the document flow still only works from the notification.  If you are interested in learning more about it, please contact us.

Hope this was useful and as always, if you need additional help, please let us know.

Mike

 

Service Order Document Flow – Configuration

In a recent post, I talked about the document flow functionality.  One of the things I wanted to cover is how to turn on the service order document flow.  In the sales side, all of this information is turned automatically.  In SM, you need to manually turn on the pieces you want.  My recommendation is to turn all of these items.

First of all, this is where you go in configuration

Once inside the transaction, this is what you’ll see.

Now, I encourage you to make sure all the components you use are checked.  that’s all there is to service order document flow.

If you have any SM needs, please press the contact us button at the top of this page,

Thanks for reading,

Mike

Service Order change documents – Make sure this is turned on

One of the important pieces of tracking your metrics (and more importantly your improvement) in SAP hinges on having data.  In the service order, a lot of the change documents are turned off by default.  So I thought I’d put together a quick post to show you how to activate the Service Order change documents.  So, let’s start with where the configuration exists in SPRO

Now, here’s all things you should be aware of in this transaction.  First, find your order type and plant, then start scrolling across and make sure that you’ve checked everything that makes sense for your business:

Indicator: Status change document active for materials  this will track the status changes in a service order for the materials.  if you do metrics reports, you need this checked.

Increment this is the increment of operation numbers in your task list.

Status change document for header order/network this collects all the header level status changes.  Again, if you collect metrics, you need this checked.

Collective Requisition if you want a single purchase req for the whole order, check this box.  Otherwise you’ll receive a different pur req for each item.

Res/PurReq this determines if the purchase req/component is released as soon as it’s entered, or not until the service order has been released.  I’ll usually recommend (2).

PDC Active exactly what it says, plant data collection is active.

Indicator: Workflow for purchase order change you get the idea.

Indicator: creation of change documents active highly encouraged, so you can see all changes.

Ind.: Copy Net Price from Requisition into Purchase Order you get it.

Indicator: Status change document active for operations another change indicator.

Indicator: Status change document active for PRTs last change indicator

If you’re not sure you have this stuff set, I encourage you to go check.  If you don’t need it now, I’m sure you’ll need it in the future.

As always, if you need any SM assistance, please contact us,

Thanks,

Mike

Service Management – Understanding the Repair Procedure

One of the key pieces of the in-house repair scenario is the repair procedure.  The repair procedure simply put is the roadmap of actions that need to happen when you perform a service process.  I’m going to talk about how you can set this up and use it to fit your business process.

First thing is show you where in configuration you define the repair procedure.  The following screen shot shows you where to go in SPRO to configure the repair procedure.

Initially, select the Maintain Repair Actions.  This screen will give you the translation of what each action means.  The actions are the key in the actual repair procedure, so I wanted to show you what they look like.  Normally, this screen doesn’t need to change unless you want to add better text to the action (this will show up in the repair screen).  Some of the important terminology in this screen:

  • Send/Pickup Replacement refers to loaned equipment.   Simply put, you send the customer a unit to use while the repair happens, then they send it back after they receive their repaired unit.
  • Replacement Part – this is an exchange.  It means the customer will keep this unit (and typically return the unit they currently have to you.  then you can repair it and add it to your refurbished/spares inventory).

Alright, now on to the real work.  Next we will pull up the repair procedures.  I’m going to walk through the example of an in-house repair that allows loaners.  the next screen will show you how to get into the repair procedure.

Select the procedure you want to view (or copy in the event of creating a new one).

Now, you’re looking at the SAP logic of the repair procedure.  What you’ll notice is that everything is broken up by stages.    Remember, for each stage you can only define a single Default.  The stages are as follows:

  • 101         Accept repair: this is the actual receiving of the item
  • 102         Start repair: this is the repair of the item, or the processing
  • 103         Confirm repair: this is what happens after the service order is confirmed.

Now, if you look at the first stage(101) in the procedure below, you’ll see the following steps.  These are the steps you are allowed to do as soon as you enter in the material to repair.

  • 101         Returns                – this is flagged at Default, so that means this will automatically be placed into the sales order as soon as the repair procedure is selected.
  • 104         Send Replacement – this allows you to send a loaned piece of equipment to the customer
  • 106         Replacement Part – allows you to send an exchange to the customer.

Looking at stage 102, you’ll see the addition of Manual and Conf. populated.  Before I move on, the options for confirmation (conf.):

  • 01           Repair: fix me
  • 02           Do not repair/can be delivered: don’t fix me, but send me back
  • 03           Can be scrapped: scrap me
  • 04           Repaired/for delivery: I’m repaired, send me back to the customer.

Also note, if something is set as manual, even if 01 -> 04 above are selected, the item will not be automatically added to the sales order.  It will have to be manually entered.

Now looking at the actual data for stage 2 you’ll see that the numbers make a little more sense:

  • 102         Repairs                                 01                           : since this is 01, it means repair me, thus generate a service order.
  • 103         Outbound Delivery         02           Manual: this is the scenario  where the item cannot be repaired, so just send it back to the customer.  This is a manual step.
  • 107         Scrapping                            03           Manual:  Similar to 103, but this time we won’t even send the item back to the customer.
  • 108         Credit memo                                                     :  Create a Credit Memo Request for the customer, with reference this line item.
  • 109         Debit memo                                                       : Create a Debit Memo Request for the customer, with reference this line item.

I hope this makes sense of how to structure your repair procedure.  If you’d like more detail, please comment below.  Now for the next piece, how do I attach this repair procedure.

In the item category configuration, scroll to the bottom of the item category, and enter the Repair Procedure.  I’m not going into the details of how to select this item category (I’ll save that for another post).

I look forward to your comments,

If you need more in depth assistance on this, please contact us for additional consulting help,

Thanks,

Mike

Service Order – Using the Document Flow

Now in my opinion, one of the greatest things that SAP has added into the system is document flow.  this is especially true for SM.  If you’re new to SM or SD, you might not be all that familair with using document flow.  If you’ve ever visited an SD or SM document, you’ve most certainly seen this weird little icon:  .  If you plan to do anything in either of these areas of SAP, you’ll quickly realize it is your best friend.

Document flow in SAP is simply the connection to all of the preceding/follow-on documents.  In the in house service scenario, a type document flow may look something like this:

You’ll notice that in this picture I was able to see notification, the repair sales order, the inbound delivery, the outbound delivery, the invoice, and any other SD related documents.  What you also may have noticed is the distinct lack of the service order, but there is a service documents button.

Unfortunately, in the design of document flow and the table structure for capturing this, the service documents were neglected in the initial design, so the Service Documents button I believe was an afterthought.  It’s still better than nothing, and I’ll give you some tips for making the best of it.

The first big thing you need to know is, if you’re starting at an SD document (delivery, sales order etc. ) be sure to click once on the sales order (make sure it’s highlighted, and you’re good).  then press the service documents button.  This will bring up a new screen showing the service order and any of it’s related documentation.

One of the other issues I’ve encountered with document flow is the inability to see sub-service orders in the documentation.  The only way to see if there are sub service orders is to drill into the service order, and look for the structure button

You will then need to click this button to see the sub service orders.  You can then drill into the order and see it’s individual document flow.  As a follow-on to this topic, if you have a complicated doc flow, for example…

Notification

Service Order (for quoting) – Repair Sales Order
     Service order
          Sub Service Order
          Sub Service Order
Inbound Delivery
Outbound Delivery

 

Now with a structure like this, you again, won’t be able to see everything depending on where in the structure you are at.  For example, if start at the service order (for quoting), you won’t be able to see the actual service order used for repair.  Instead, you’ll have to navigate to the notification, and then you’ll be able to see the structure below the notification, including the repair sales order.  The way the documents are laid out above, shows kind of how SAP structures them.  Since it is a pseudo parallel path, you have to work your way up to a common document before you can see the next path.  In this example, the notification is that common document.

There is a another big thing to remember when dealing with service.  You have to turn on the document flow for many of the items.  For example, purchase reqs, material transfer, etc. must be turned on before they will generate items in the document flow.  I HIGHLY encourage you to make sure these are turned on.  Not seeing the purchase reqs, or materials issued to a service order makes your job as a troubleshooter FAR more challenging.

Now that’s the basics of document flow, and if you’re not already using it, get familiar.  For me, it’s personally one of the best tools offered in the SD/SM module.

Thanks for reading,

Mike

Service Management – Using the Notification Status to your advantage

Now in my many consulting engagements, one thing I’ve seen consistently overlooked is the notification status.  When I ask why don’t you close your notification when you’re done with them?  I always get the same answer, we don’t have the time.  Now I understand that everyone is busy, and extra steps take extra time, but today I’d like to point out why using the notification status can help your service organization.

Now, the first thing to notice is that by default, service notifications do not have a lot of status options.  For the most part, it’s open, closed (there are more if you use the tasks, but that’s for another day).  So it’s pretty easy.  There is also the ability to add the user status (another thing I highly encourage, more on this later).  So we’ve established that there are simple choices in the service notification…  but they are often not used.

Now, the whole point of this post is to tell you why you’re missing out if you don’t use these.  Just like everything in SAP, you can collect data, metrics, and lots of useful information if you just enter it into the system.  I did a post the other day talking about how companies miss the boat by either not entering, or not using the info that SAP offers.  Well, this is directly related to that.

Entering the status of the notification allows you to use standard SAP transactions (IW58 for example) as a work list of notifications that require attention.  More importantly, it can give you the metrics to see how well your call center is performing.  Since SAP collects all the data for you, you just need to tell it when you’re done, you can have instant statistics on how many notifications were created, how long were they open, how many were closed, and even who closed them.  If you run a call center, this information could be vital to determine if you have enough representatives in the call center, are they able to close the majority of calls without follow-up, how many were questions vs. an actual return or RMA request?  All of these metrics can be extracted from SAP (if you want to see this in action, check out the demo for Broadsword, and it will show you a program that shows you all of these metrics.  All of which extract standard data from SAP.

The whole key to this is…  someone needs to perform the tasks of setting the status (user status, or just closing it).  Like everything, the data is no good if no one is looking at it, but if you are a proactive organization,  you are probably looking for ways to cut costs.  Knowing how your call center is performing can give you some key insight into now only your employees and their skill sets, but also into your products and how well they meet the needs of your customers.  (you can tell this by the number of returns, the reason for returns, and the number of repairs).

Well, I hope this was useful… as always, thanks for reading and I’d love to hear from you,

Mike

Installations in SAP – Project Systems vs Service Management

I recently got a request from a consultant friend of mine.  He was wondering about the best way to capture costs of installations.  In my experience, there are 2 very different ways of handling this, and much of it is related to the size/complexity of the installations and the amount of data you are willing to maintain in order to accomplish this.  Let me talk a little about the 2 methods.  In the end, both are great, but you should be able to look at the situation and decide which one fits your needs best.  Now, my quick disclaimer.  I am by no means a PS expert.  There quite probably many things I’m leaving out of the discussion, and I encourage you to talk to a PS expert if you think you need to go down that path :).

1. Project Systems.  This method is typically reserved for large installation (in my opinion).  The nature of project systems is that there is a lot of functionality, but there is also a lot of data to maintain in order to use it.  In PS, you can have multiple different cost collectors, full project tracking, production orders, service orders, purchase orders, etc.  all of these things traceable inside of a network/WBS.  I recommend this approach for anything that is large and may require any sort of planning functionality (for example, planning multiple service technicians, material reciepts, contractors, etc…).  Most importantly, if you need to track it like a project, it should be a project.  As far as costs/price go, usually resource related billing is used to track this since it is often a time and materials type activity.

2.  Service Management.  this is method is gonna be  the down and dirty method.  It’s a single service order (with the ability to make some sub service orders if you so desire).  It will still allow you to plan components and operations, but from a simple order structure.  You use this approach typically for anything small that doesn’t require a full project plan to coordinate (or if you want to do the project planning in MS Project and that’s good enough for your purposes).   The installation service order can be spawned directly from a sales order.  You can still use resource related billing for the cost/price determination in the sales order.

In my experience, the biggest thing you lose between SM and PS is the reporting and scheduling functionality.  PS is far superior in this respect, but if it’s overkill for your needs, you can get by with a much more simple approach in using the service order.

I hope this sheds some light on the differences.

Thanks for reading,
Mike

Serial Numbers – Number Scheme

Since I got a request for more posts about Service management, I thought I’d dig into my bag of tricks.  One of the things I’ve run into a lot of issues is serialization.  For some reason, serial numbers seems to hold a special place of confusion for many customer.  Today I want to talk about the serial number number scheme.  I’ve picked this as my starting point for serialization because many of my recent projects have had a lot of trouble coming to decisions on this topic.
Serial numbers have a great starting point when it comes to numbering.  As of ERP 5.0 or 6.0 (not sure exactly when), SAP added a field called SerializLevel.

This field allows you to make the serial number number scheme unique at a global level or unique at a material level.  This subtle difference has huge implications on the number scheme.  If SerializLevel is blank, then serial number is only unique at a material master level.  To put things simply, the combination of serial number and material number is unique, but the same serial number can show up for any material number.  If SerializLevel is set to 1, then the serial number is unique across the SAP instance.  This means that no serial number will ever show up  for any other material.  SAP accomplishes this by linking the serial number to the equipment record number.  I’ll have a future post that goes into the details of serial numbers vs. equipment records.  Since every business is different, and you can often become locked into a particular numbering scheme.  The number one decision to make is if the serial number is unique across the organization, or if it can be reused for materials.

There are some things to beware of when using this functionality.  The SerializLevel field is plant dependent.  This means that you do have the ability to set this value differently across different plants.  I discourage setting this differently for the same material.  If you were to set the value to be unique across the origanization in one plant, but unique by material in another, you’ll see some very inconsistent results in the history.  I’ll go into the serial number history in a future post, but when it comes to serialization, consistency is key.

The final issue to cover when it comes to serial numbers is what I’ve heard called “intelligent” serial numbers.  When I say intelligent serial numbers, I use the term loosely.  This can be anything from adding a prefix by product to each number, adding in a manufacture date, or it could be a combination of alphanumeric characteristic that have a decoder ring to explain them.  In my humble opinion, this is a very slippery slope and should be avoided at all costs.  When you move down the path of “intelligent” number schemes, you must introduce ABAP code to accomplish this.  I believe the user exit is IEQM0003 (don’t remember for sure if this is the correct exit).  Regardless, if you start creating an “intelligent” number scheme, you must have multiple number ranges available, you need code to possibly shift from one range to the next.  For anyone that’s been doing SAP for a while, you know that every time you introduce code, you introduce risk, and you introduce additional time to implement.

The most important question to ask is “Why do you need an “intelligent” serial number?”  A serial number should be nothing more than a tracking mechanism for a product.  Requiring the serial number to mean something is a not something that add value to a product, but it does increase the cost.  Anyway, I’ll get off my soap box now.  You get the idea that I think intelligent number schemes are costly, risky and unnecessary.

I hope you found this useful.  I hope to hear your comments, thoughts, or let me know things I missed.

Thanks for reading,

Mike

Service Availability

It’s been a while since I talked service, so I thought I’d start posting some simple tips and tricks again.  In case you forgot, and if you read my blog often you might have, I’m actually a functional consultant, not a basis guy =)  Service and VC are favorite areas to work in.  I think they provide an interesting set of challenges and are often areas where it is hard to find good people (which is awesome for me).  Anyway, I’m working on a 5 – 10 part course talking about the basics of service management.  I haven’t decided how long it will end up being, so stay tuned.  I have so much in the hopper, but I want to actually show you guys I do know something about SM, service availability.

Today, I want to talk about Service Availability.  I’ve seen it used sporadically in places, but never very well.  So I want to talk about the how and why.  Now, before I get into the meat of the topic, let me explain why this part is important.  Just as in sales, knowing if all of the components are available is extremely important to managing your workload.  SAP provides the same availability functionality in the service order as it does in the production (except of course, running it in mass…  but for that, check Armory by JaveLLin Solutions. couldn’t help the shameless plug).  Transaction IWBK is actually a good transaction to show you all of the availability associated with a service order, and it even gives you fancy traffic lights to let you know at a glimpse if everything is available.  In addition, the status of the service order itself lets you know if all components are available.

Now, you may be asking, why do I care?  Often you have a decent workload of service orders and you require components in order to begin work on them.  Wouldn’t it be nice to see at a glance if all the components are available to know if you should start working on the order?  Perhaps you released the order to get some MRP requirements out there for parts.  Well, if you don’t know when the parts are available, how do you know when you can start working on the order?  Meanwhile, the clock is ticking for getting this part back to the customer.  Your metrics look worse and worse, all because you don’t know if you have parts to start working on a repair.

Alright, you understand the problem, so what can you do about it?  First thing you need to do is make sure the availability check is configured the way you need it.  Just like the availability for sales and production orders, you can have a unique one for service (or more often you’ll use the same one that production uses).  The screen shot below shows you were to find the configuration to see what in the system.

If you look at the Define Checking Rules, you’ll see the following.  Please note, SM is the default.

Next go the Define Scope of Check…  this is where the real work is done.

Remember, that the scope of check can be different depending on the material availability check.

This example shows 02 – SM

Every one of these options determines things that either availability includes or excludes.  Every organization is different, so I can’t tell you there are default settings to use.  I can tell you that you should experiment with whatever you do select.  Have a service order with some components and make sure your settings do what you expect.  ATP is touchy…  powerful, but touchy…  in my e-class, I’ll go into more details about the exact settings.

finally, you need to assign the availability check to the plant/order.  And you also can change the check for creation vs. release.

Here’s the settings you can control:

Alright, now that you’ve seen where to configure the availability check, you should understand how to run it…

Well, it’s pretty simple.  SAP only offers one place to execute availability.  IW32.

Press this button to availability.  There are several important system status that relate to availability:

MANC – Availability not checked
MSPT – Missing parts
MACM – All parts Available

If you use IW38/IW39 or Iw72/Iw73 and you look at system status, this will give you the quick look to determine if you have components available or not.  Please note, this doesn’t do a hard allocation of the components.  it simply says, based on the availability check (see above) that it is in stock.

I hope this little overview gives you an understanding why availability could be an important piece of service that you’ve overlooked.

Thanks for reading,

Mike

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