SM

This next installment of SAP SM Blueprinting is a short and sweet one, but be sure not to over look these details.  If you perform in-house repairs or returns, you need to understand what processes need to be accounted for.  Here’s a good starting point.

Do you currently have any special processes or requirements after receiving the material into stock?

Often when you receive materials into your plant, there are special requirements, special areas, or people to notify.  Be sure to check if any of the following might apply:

• Does the inspection or service department need to be notified?
• Does the customer receive any notification when their part has been received?
• Does Customer service need to be notified upon receipt?  This could be to issue a credit, or an email to the customer.
• Do any movements need to occur from the dock to the service department?

Where do the returns get received?

While this is a simple question, it can have a lot of configuration implications.

• Do you need a specific storage location for all repairs and/or returns?
• Will the repairs be processed in an inventory managed or warehouse managed storage location?
• Is a unique shipping point needed for repairs?  This is often very helpful in the storage location determination.
  

The ever present of question of serialization

It seems question never goes away.  Shipping and receiving is often the forgotten when dealing with returns and repairs.  If your shipping and receiving areas are familiar with serial numbers, this should go pretty quickly.  However, if serialization is new to the group, be sure they are prepared for the following

• Repairs may require a serial number, what if the serial number isn’t readily available or visible?
• What if the serial number returned doesn’t match what is expected?
• Will shipping ever be required to create a serial number for a repair?  If so, is the labeling hardware available in an accessible location?

Shipping the Product back to the customer

• Do you need to be concerned with returnable packaging?
• What paperwork needs to be provided to the customer upon return of the product?
• How are special shipping instructions provided to the shipping department?

Hope you found this helpful, and as always, please post anything else I may have missed or if you have any questions.

Thanks,

Mike

Well, I’m back again to continue my blog on blueprinting for SAP Service Management / Customer Service.  This next portion tends to be one of the biggest areas for me in dealing with SAP SM blueprinting.  I’ll do my best to keep it straight forward to give you the best details I can on SAP SM Blueprinting.  Please also refer to my other posts about Master Data and the Call Center blueprinting.

What processes does your business currently utilize?

This one simple question usually has the most impact on the service blueprint, at least in my experience.  You need to understand what processes your customer currently uses.  Once you understand what those processes are, you should be able to map them to SAP relatively easily.  Inevitably, some of the processes won’t be mentioned, so do your best to ask about each of these in detail.

• Repair and Return Processing (in-house)
  • This is the standard SAP repair processing.  This will involve sales orders, deliveries, service orders and often notifications.  There are a lot of variations that can be built into this standard process, and you’ll want to understand if any of them apply.  Some of the variants include:
    • Are Loaned Items offered to customers?  are they offered to all customers or only customers who have purchased a “premium” service of some time.
    • How does scrapping need to handled for customer own equipment?
    • Is it fixed price billing?  or Time and Material billing?
  • How many in a day/week/month?
• Advanced Exchange Processing
  • This process is a variation of the standard repair process.  The exchange is simply sending a new unit to the customer before receiving the customer’s unit.  This is often offered as a premium service to customers.  Some questions that need to be addressed for this process include:
    • How does billing occur?  is the customer billed as soon as the exchange is sent, and credited upon receipt of the customer’s equipment? Or is the customer billed after the unit is received and repaired?
    • Are brand new units sent as an exchange?  or are refurbished units sent as as exchange?
    • What happens to the repaired inventory?  Is it stocked as a new number or different valuation type? is it put back into stock as new?  Does it need to go to a special inventory location?
    • Does the repair of exchange need to be tracked separately?  does it require it’s own service order type? does it need special scheduling, for example all standard repairs must be done first before working on any exchange units?  It is first come, first serviced?
    • Is it fixed price billing or Time and Material billing?
  • How many in a day/week/month?
• On-site/Field Service Processing
  • On-site or Field Service is usually the easier process.  Typically this consists of a service order that gets charged time and expenses.  However, like everything else, there are a lot of processes that can be combined with on-site service.
    • How do you deal with components needed for the On-Site work?  Are the parts sent to customer directly?  do you use “trunk” stock where your technicians carry their own stock?  Do you charge the customers for the shipping of parts?  Do you ever use customer’s parts in the order and if so, do you need to account for those in any of the processes?
    • Do you use sub-contractors or 3rd parties to perform any on-site work?  Do you need to track items like per-deim? hotel? airfare?
    • Do you track or charge for travel time?
    • Do you schedule your technicians?  need a calender of events to know who is where?
    • How are costs currently tracked/entered?  do the technicians enter the information?  is the information sent to someone on-site?
  • How many in a day/week/month?
• Returns for Credit
  • The easiest of the service processes, the simple return for credit.  No repairs, no replacements, just a credit.  Some additional pieces to consider include:
    • How does the stock need to handled when it is returned?  does it need to be sent to quality, repairs or production before issuing the credit?
    • How is the process handled if the material is damaged upon return?  is credit still issued?  is it partially credited?  Is it repaired, and if so, where does the cost go?
    • When is it returned to stock?  can it go back to unrestricted inventory as is, or does it need to be a different valuation type or a different material?
  • How many in a day/week/month?
• Returns for replacement
  • This is a gray area as far as I’m concerned in the service world.  This could actually fall under the repair process and be executed like a service exchange, or it could just be a return order, with another sales order (free or paid) order to follow up.
  • The biggest think that drives this one way or the other is finance.  If it should count for or against your service revenue, this by all means, add it to the service process.  However, if it’s just a cost of sales, you’ll want to be careful trying to make it fit into service.  Someone’s budget might take a hit that they weren’t expecting.  In general, try to steer this away from repair orders.
  • How many in a day/week/month?

Do you perform quoting of repairs? 

Such a simple question… right?  nothing ever is in SAP.  When you talk about quoting in the service order, there are always little considerations you have to take into account.  So make sure you know what you need in advance.

• Do you quote in house repairs?  if so, do you quote them before or after the product arrives in-house?
  • If you quote them after, please check out my blog post: SAP SM: Quoting In-House Repairs.  It will explain how to quote using the repair sales order you received the repair on.
• Do you quote time and materials?  or do you quote as a fixed price?
• Do you need to begin processing before the quote is approved?  for example, do you need to make or buy materials that have a long lead time?
• How do you track your quote approval/rejections?

How do you price/bill your repairs?

The pricing and billing of the repair order is actually a much easier question (at least initially).

• Do you offer fixed price repairs?
• Do you offer time and material billing?  If so, what do you bill for?
  • Labor?
    • do you break it out by straight time, over-time, travel time?  If so, do you have pricing and costing rates for each of them?
  • Materials
    • do you break it out by material types?  Finished goods? raw materials? etc?
    • Do you display each material used?  or just lump them all together into a single total?
  • Subcontract
    • do you need to break this into labor and materials as well?
  • On-Site expenses?  do you incur these?  If so, how do these need to be broken down to the customer?

Do you deal with warranty of products?

Warranty tends to be one of the most challenging pieces to deal with when it comes to the repair process.  There are a lot of variables, and it seems that everyone handles it differently.  So make sure you collect a lot of information.  I’ll do my best to arm with as many questions as I can think of.

• How do you Track warranty?  is it through serialization? equipment records? time of shipment?
• When does the warranty start?  shipment? registration? receipt? time of creation?
  • if it’s registration, how do you track that?  is there an interface?
• How your warranty measured?  straight time? operating hours? mileage? or a combination of multiple things?
  • If it isn’t straight time, how do you track the other metrics?  is there any automation to capture the numbers or is it a manual process?
• What is covered by the warranty?  Time? Materials? customer service? on-site service? everything?
• When do you know that something is warranty?  do you know at the time of the customer contact?  or not until you actually evaluate the material and see if it falls under warranty (this is a big one in determining how to handle warranty).
• Do you accrue for warranty costs?  if so, how?  is money taking out of each sale of particular parts to go into an accrued warranty account?  is there no accrual?  What accounts should be credited/debited when doing a warranty service of any time?
• Are there special considerations for profitability or COPA?  (I’m no expert here, so if you’re like me, make sure you have your FICO person available to translate. ha ha)
• what happens if someone doesn’t state it’s warranty?  what is the process going to be? (this one is always more for me, because without fail, setting something as warranty is often forgotten and need to be corrected after the fact.  Have a plan for this)
• Do you perform your own service work for the warranty, or do you allow 3rd parties to repair the product and then bill you? (if so, see my post SAP Warranty Claims: A Guide for Beginners).

Do you use service contracts/extended warranty/etc?

Since we’re talking about warranty, the conversation wouldn’t be complete without talking about contracts.  Unless you offer a lifetime warranty, often you will give your customers an option to purchase an extended warranty or perhaps some sort of maintenance plan.  Like warranty, contracts require a lot of information to set the process up correctly.

• What do you sell under a service contract?  is a yearly maintenance visit? X hours of support?  full repair/replacement?  Exchange processing for quick turn around?  extended warranty, for some or all facets of your product?
• Do you use deferred revenue for the contract?
• Do you use a billing plan?  or do you bill everything up front?
• What accounts need to be credit/debit for the contract revenue?
• How is service recognized? what accounts needs to be credited/debited when something is under contract?
• Will you track specific serial numbers under the contract?  or any products the customer owns? (serial number tracking is encouraged)
• DO you have a cancellation policy?  do you have a method for extending the contract?
• Do you track the costs vs. revenue associated with the contract?

This was a big topic, so inevitably, I missed something.  Please add things I have overlooked to help all of us get better at blueprinting,

Thanks,

Mike

My last post started talking about the questions to ask when you blueprinting the SAP Service Management / Customer Service modules. This next installment is the SAP SM Blueprinting questions I ask regarding the call center.  If you want more details, check out my post about Blueprinting Questions – Master Data.

Are you currently using call center tickets/notifications?

This question is how you can initially determine exactly what your client needs to run the call center.  Some clients don’t currently use notifications or any sort of help desk tickets, and other clients can’t live without them.  If they are currently using notifications, you follow up with some of these additional questions.

• Do you use multiple notification types?
  • Some clients want the distinction between return merchandise authorizations, simple call center calls.
  • It’s important to understand what is different between each type of notification.  It might be possible to consolidate notification types, and report in different method.

How many calls are you tracking in the course of a day/week/month?  How many people are taking these calls?

This question will help you to gauge exactly how much time a call center representative can devote to entering a help desk ticket.  If you receive a 10,000 calls in a month, and it’s spread between 4 people, the call center won’t have the time to capture every detail of every call in a ticket.  However, if it’s a well manned call center, it might be feasible to turn every call into a notification that may be closed when the call is ended, or may required follow on actions.

 

What information do you capture during a call?

This is the biggest piece of your work for the call center.  Based on this information, you can design your first pass of the notification.  Including what screens and what fields should be on the first tab, and at the top of the page.  Remember, you can capture as much information in the notification as you want, but there is a trade off between time to enter the data and how you use that data.  Be sure to stress that you should only capture what you will use, or your just throwing away hours on data entry.

Do you use tasks/objects/etc. in your notifications?

This is question that determines just how functionality you will incorporate into the notification.  Implementing tasks/objects/activities etc. gives you the option to incorporate workflow, and assign tasks to individuals.  You want to be careful with this, since this functionality can add a lot of overhead to maintaining your notifications.

Do you generate repair sales orders directly from the notification?

If you do repair processing, or even straight returns, you need to generate repair sales orders or return sales orders.  This is standard functionality in SAP, but remember to be aware that only limited data from the notification is passed to the sales order (unless you enhance SAP).  For example, there isn’t an out of the box action button to generate a return order.

What follow on activities are needed from the call center?

Notifications in SAP can spawn other activities that need to happen, or simple things that need to be logged, like a phone call to the customer, or add an entry to the solution database.  It’s important to understand what your customer really needs.  Most customer initially think they want a lot of these things.  Remember, to keep expectations in check.  While all of this and more come standard in SAP, it’s important not to overload your call center team just because something sounds cool.

• Log Phone Calls
• Create Internal Note
• Quality Notifications
• Send Confirmation of Receipt
• Solution Database
• Send Final Notice
• Other Actions?

Do you generate service orders directly from the notification?

Remember, when you start this discussion that there is a difference between the repair process and simply generating a service order directly from the notification.  Typically, when a service order is generated directly from the notification it is either for quoting or perhaps for on-site/field service.  For in house repairs, best practice is to use the repair sales order/process, which is often generated from the notification by the action box.  Often this question is either a part of or leads to a process discussion.  How do you want to generate your work orders that are not in-house repairs.  This will vary from client to client, but I’ll always recommend that you keep your processes similar whenever possible (so make your field service orders work similar to your in-house repairs).

Do you have any workflow or customer programs designed around the notification?

This question often ties into the use of tasks/objects etc.  This question covers you in case you need to worry about interfaces that create/change notifications in the system, or any emails/workflow that are required during the processing of the notifications.

Do you currently track any metrics around the notifications?

This is always a tough question to tackle during blueprinting, but it’s better to gather the requirements now.  In short, what are the company metrics your call center is measured on.  Sometimes these are corporation wide, other times they vary from division to division.  Either way, you’ll want to find out how the call center is measured, and be sure to include a method in your notification to capture that data.  Most likely, you will need a custom report to deliver this information, but nevertheless, find out early.  Here’s some common metrics I’ve encountered.

• number completed
• Amount of time open
• Number of open tasks
• Etc

Do you have any on-line/web based notification entry systems for your customers or suppliers?

Finally, does your customer have any web interfaces or tools that allow your customers to by-pass the call center by registering their own products or creating their own RMA’s.  This is a great cost savings, but requires significant programming to accomplish.

Alright, that’s what I have for this round.  I’ll be back soon to continue this blueprinting discussion.  Again, please chime in with anything else in this area that I may have missed.

Thanks,

Mike

www.paperstreetenterprises.com