Home / Archive by category "Business" (Page 11)

ROI of Service Notifications

I wanted to continue the series on how service can truly help your business.  Today, let’s talk about the service Notifications ROI, or return on investment.  All too often, I hear business’ complain about the number of transactions within the service management module.  While I agree, for small businesses, there can be a lot of transactions, but what is often overlooked, or perhaps unused, is the beneficial data in all of those transactions.

This first piece is one of the most valuable, and most overlooked benefits of the service notification.  That is the ability to offer the most cost effective warranty to your customer that you can.  Now, all too often, everyone is concerned with if the product is under warranty.  But in your customer’s mind, the best products have the longest warranties.  Well, what if you could offer your customers an additional 3 months of warranty, without it costing you any more?

Well, if you pay attention to your service notifications, you can determine by product, how many issues do you encounter within 3 months?  6 months? 1 year?  Let’s say you offer a 3 month warranty on a particular product.  If you analyze your data, and find that 90% of your issues occur after 4 months, you could suddenly extend your warranty to 4 months, and you won’t experience any more service notifications.  This now gives your customers an additional month of “piece of mind”.  Perhaps, this gives you the edge against your competition that only offers a 3 month warranty.

Best of all, you’ve just gave your customers a nice little bonus and it costs you nothing but updating your literature =)

Thanks for Reading,

UI5 – Connecting Master to Detail

Well, I wish I could say this was an easy thing I finally figured out…  but it was a hard fought victory 🙂  I spent more hours than I care to admit fighting through this.  My issue that I had a list pulled from gateway service.  The problem was that when I would click on an entry in the list, the values were not being populated.  Of course, I tried to extend what I learned, and that got me into trouble.  But like everything, I found my home 🙂

Let’s start at the beginning.  First, I used the following tutorial as my baseline.

This was great, but it was using static data.  I had services built for my iOS apps, so I decided to start by calling one of those.  It was good.  I was able to build the list, but try as I might, I just couldn’t get the data into the detail screen.

Here’s what I finally figured out.


oView.setModel(oModel, “orders”);

this was a switch from the tutorial, where the model didn’t get a name.  I thought this would make no difference.  Boy was I mistaken.  Here’s what I needed to do  to finish this change


page.setBindingContext(context, “orders”);

here, I didn’t realize I could add a 2nd parameter.  I needed to add my model name.


handleListItemPress : function (evt) {
var context = evt.getSource().getBindingContext(“orders”);“Detail”, context);

handleListSelect : function (evt) {
var context = evt.getParameter(“listItem”).getBindingContext(“orders”);“Detail”, context);

the getBindingContext() needed to list the name “orders”.


title=”{orders>DocNum}” >

make sure when you enter the variable, that {orders>DocNum}

special thanks to the following post that gave me the final piece (that app.controller.js)

Thanks for reading,

UI5 – Using a service from a remote server

Wow…  this one really burned through a lot of my time.  After many hours of trial and error and google digging, I finally found the trick that would read my service without errors.

Go to your web.xml file (this applies to eclipse) and scroll down until you find the following section:

<!– ============================================================== –>
<!– UI5 proxy servlet                                              –>
<!– ============================================================== –>

<param-value>http://<your url>:<port></param-value>

make sure your section looks exactly like the above, just change the blue text to be your sap server/port.

Thanks for reading,

The ROI of Service Master Data

One of the big things I’ve been contemplating as we come into a new year, is return on investment.  I’m really trying to focus on how service can not only cut your costs, but become a revenue source in many businesses.   Master data is always a sore spot, because it’s not easy to keep things up to date.  With everyone’s changing priorities, keeping all the data in the system accurate is no easy task.  So, is there any return on investment for maintaining all of this data in your system?  Now, ROI is a very subjective term when it comes to something like data within SAP.  One organization might easily be able to monetize that data, while others struggle.  So, let me give you some ideas to consider when you decide from a financial perspective, what is all that data worth?  I’m going to go through several different scenarios that I’ve seen throughout my career.  Keep in mind, not all of these scenario apply to ever business, but I’m willing bet if you read through these, you might be able to make the leap to your own processes.

1.  Product Registration.  Now, this is something that I often see overlooked in organizations.  Collecting product registrations.  Now, if you buy an appliance, or piece of electronics, you will often see a little card you can fill out to register your product.  Often it is used to start your warranty, or maybe just to give you special offers, or updates as new software becomes available.  From the business side, this information has huge potential upside.

  • it allows you to connect to your end user.  If you use distributors, without registration, you’ll never be able to find out who is really buying your stuff.
  • It allows you to start and end standard warranties on your products.  This is especially valuable, if you offer your user a one year warranty.  Well, most business don’t start that warranty from the time it’s produced, rather when it is purchased.  If you customer buys it 3 days or 3 months after production, you’re still on the hook for 1 year worth of warranty.  If you run into any percentage of returns or product defects, being able to cut off your free service has a definite financial advantage.
  • When you know your end user, you can go to the up sell.  By that I mean, you can offer discounts to buy extended warranty, upgrades, etc.  This allows you to extend the life of your products, while keeping your customer happy.  If you keep providing the latest upgrades or enhancements to your customers, they will remember.  Or more the point, if you don’t provide this, they will remember.

2.  Keeping track of what your customer owns.  This is valuable for any industry, especially if you offer systems of products that might work together.  When you maintain this data, you will quickly be able to know what your customer has at a particular site, or even be able to drill down to a particular area within a site.  This is often contingent on doing the installation yourself, however, it still buys you a lot of valuable ROI with your customers.

  • If you provide on-site service, the more you know about what a customer has installed and where, the faster your technician can get your customer up and running again.  You can minimize the down time by having the correct parts with them.  You can do initial troubleshooting, just by knowing that product X & Y are both installed, and sometimes can have side effects if used in certain ways.  Knowing that in advance better equips your technicians to  fix the problem the first time.  That saves you money, and gives you a lot of goodwill from your customers.
  • If you install serialized components installed into other serialized components, you don’t have to ask your customer to disassemble half the unit, just to tell you the serial number.  Instead, you can quickly look into your installed base, and see what is installed within each unit, often drilling down several levels.  While this might not generate a lot of money, it will generate goodwill with your customers by making it easy to do business with you.
  • If you ever need to do a recall (like I keep seeing for my vehicle), knowing where every serial number is located will quickly let you be proactive with your customers, to let them know what needs to be fixed/upgraded/replaced.  You can generate campaigns to notify your customers before they start having problems.  This will save you definite dollars by avoiding last minute, emergency service trips, and instead garnering more goodwill with your customers by letting them schedule when things can be serviced.

3.  Maintaining as accurate warranty dates.  This one seems pretty obvious, but I’ve been surprised how many organizations  are willing to “wing it” for this information.

  • Not only can you cut costs buy knowing when a product is no longer under warranty.  You have the ability to generate revenue when it does break down and your customer wants it fixed.
  • You encourage registration (see above) by allowing that date to be the starting registration date, rather than the original ship date.
  • You can quickly run reports on items coming off of warranty in the next month to send an offer to extend their warranty for a reduced cost.  This keeps customers coming back to you, and not your competitors.

There’s more I can say, but I’ll save it for another time.  The thing to take away from all of this is that if any of this stuff applies your business, and you aren’t collecting this data, you are losing out on all of the benefits that come with it.  I can even show you simple ways to start collecting that data…  just ask me.

thanks for reading,

UI5 – Early Challenges

Well, like always, I need to keep myself entertained by learning a new skill.  Well, this is pretty much all brand new, but I needed to understand UI5, and how I can start to use it on my own apps.  Because I’m already familiar with creating services, I thought this would be easy 🙂  Well, nothing is ever easy.

First, the cool parts.  UI5 gives me that responsive functionality that I really need.  Web Dynpro just can’t give it to you, and even designing an iOS application still requires you to design everything for different device sizes.  With UI5, not only can you have an app that adjusts to the particular device, but you can even add functionality based on certain devices (a common example would be to turn a button off unless it was a smart phone).

Now, my first major hurdle.  I’ve probably wasted around 8 hours on this…  still haven’t solved it.  I needed to vent, to so rest assured, when I figure it out, there will be another post 🙂  I was able to go through some tutorials, build an app with local data.  Cool, so I decided to replicate my current iOS application.  I got a lot of the framework done (still have a lot to learn, but it gave me the basics).  So I was ready to connect it to my service.  Looked easy enough… read some other blog posts, saw what to do…  nothing…  so far, I have found that at least part of my challenge revolves around CROS, which is a service that protects you from other systems calling your data unless you allow it.  Great…  but I WANT these 2 systems to talk.  I’ve tried lots of things…  I found something that at least got me to a new error 🙂

in Chrome, if I installed a plug-in “Allow-Control-Allow-Origins”, I got past the cross talk error.  But now I’ve moved onto a new error HTTP 405.  I have a headache, so I have to leave it alone for a while…  Talk about a strange way to spend vacation 🙂

thanks for reading,

Merry Christmas

Well, it’s that time of year, so I won’t be posting much for the next 10 days or so.  In the meantime, don’t waste your time poking around linked-in or reading work blogs.  Please take the next week or so to enjoy your family as much as possible.  If you are like me, the holidays are a chance to see friends and family that you don’t see that often.  So make the most of it…  even if your family can be a bit crazy (let’s face it, it’s what family is all about).

So Merry Christmas and Happy new year.

Service Management – Using Document Flow for Service Orders

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 familiar 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…


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,

Service – 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 check out my book,

Thanks for reading,

Big Data – What good is it if you don’t use it?

Why is it that with Big Data every where, GB of information, and limitless data at our fingertips,  many businesses still seem to be so poorly run.  I mean, if you listen to the hype, everything is Big Data, Big Data, Big Data.  So, what’s the deal?  how is it in an age of ERP systems that capture everything you do, we still see so many organizations struggling, or worse yet, barely hanging?  Well, we came up with a couple of things that I believe explain a lot (and I hope you can learn from it).  Most of this will be from my experience of SAP data.

1.  If you don’t know what the data means, how can you interpret it properly.  This sounds so simple, but when you stop to think about it, in a giant system like SAP, there is so much data.  If you don’t know what the data means, how can you possibly use it?  In addition, the bigger the system, the harder it is to mix and match the data into something that makes sense to your team.

2.  If you don’t know where to find the data, it’s gonna be tough to use.  Again, similar to the first point, knowing the data is in there, doesn’t help you find what you NEED to know.  In an ERP system, often there is so much data, that getting the stuff you really need can be challenging.  SAP for example has so many different dates, that knowing which data you really need to be using can be a challenge.  Figuring out the correct date, and then pulling it together to give you the information you need often takes someone with a lot of knowledge about the system.

3. Analysis of the data is key to pinpointing the true issue.  Once you have all the information, and you’ve put it into a readable format, now someone needs to look at it and interpret what it means.  Take my area for example, Service management.  If you have an issue with repairs in-house not happening quickly enough.  There are many areas to review to figure out where the bottleneck really is.  The issue could be the receiving group not processing the delivery soon enough, it could be that the service order doesn’t get released in a timely manner due to missing parts or lack of capacity.  It could even be that the service department doesn’t enter in the data when they need to.  If you don’t know what data to look it, you could be solving the wrong problem.

4.  If you don’t use the information, things can’t get any better.  Now, this is the most difficult of all things to overcome.  When an organization doesn’t act on the data they have extracted, things will not improve.  As a consultant, this is the most frustrating place to be.  Seeing upper management receiving all the data to pinpoint where things are “broken”, but then not taking any actions to improve the the organization.  A couple years back, I was a on a project where inventory was in a terrible predicament.  Things were in the wrong place, employees were not properly transacting things in the system, and every day it got worse.  The entire team kept telling them to perform a full physical inventory, yet the business refused.  Instead, they spent days and weeks counting certain areas they believed were causing the issues.  All this managed to do was shift the problem around and never solve the issue.

As you can see, there are a lot of things preventing businesses from running at their best.  The good news is that of the issues listed above can be solved if you can get someone that knows the data and how to analyze it.  The 4th issue… well that’s beyond anything I can offer any help for =)

Anyway, I’m sure I left a bunch of stuff out…  but I hope you enjoyed it.

Service Reporting – Repair Sales Orders

If you’re familiar with SAP service management, you realize the challenge of seeing the full picture of the in-house repair process.  If you don’t know what I’m talking about, you’ve never tried to see the end to end service process in a single place.  Because SAP Service Management is a combination of plant maintenance and sales and distribution, this means that you have to try to get your reporting from multiple different places.  If you want to see the time it took from creating the repair sales orders to the time the customer sent you their item for repair, how do you do that?  Worse yet, how do you find out how long it takes between receiving the customer’s item and the time your service order is released?  Because you are often crossing modules, there is nothing out of the box to give you this information.

Now you may have a great SM person, who has spent countless hours working with your BW person to create this cube, so you can get some of these metrics.  In many of the places I’ve been, that never happens.  Often service is the forgotten department, always at the bottom of the development queue.  What if you could get all the information you could ever want or need on your repair sales orders?


What if you could all of this out of the box?  Well, you’re looking at it.  Our Service Management dashboard pulls together all of the information on repairs orders, including associated documents, status’ and when they were set, built in metrics to quickly see at a glance how many orders are open, received, in repair, and so much more.  If you use Service Management, your organization needs this kind of information.

If you’d like to learn more, check out demo of the Service Management Dashboard.

Thanks for reading,