SAP

Home / Archive by category "SAP" (Page 18)

Variant Configuration – Using CCUNDO

Well, I recently ran into a case that I needed to pull this old trick out of the archives.  It had been so long, that I needed to go to the CWG and look around to remember what it was.  It’s transaction CCUNDO. A rather handy transaction when you use VC and engineering change management together.  CCUNDO allows you to remove VC items like object dependencies, classes, characteristics, etc. from a change number.  For those of you familiar with ECM, you probably remember that you can just break the link by going into CC02.  CCUNDO allows you to select the items you need to remove from the change number, and magically, the change number link is gone.

Now, there are 2 major scenarios I use this transaction for.  The first and most common is a mistake.  I typed in the wrong change number when I went to change “X”.

The 2nd is also a mistake, but sometimes it’s a mistake from long ago.  In VC world, inevitably an object will be created without ECM, then later, an ECM gets attached to it.  Normally, this isn’t a huge deal, until you need to do something like add a new characteristic to a variant table, or change the value assignment alternatives to a table. These things can only happen when you lock everywhere the table is used.  And if you use ECM, it has to be locked throughout history.  If you created a dependency or constraint without a change number, but then added ECM later.  There will always be a date period from 00/00/0000 until the first change number was applied that you can never again touch.  Making it impossible to update that table.  Before CCUNDO, the only option was to create a brand new table and change everything over.  While this isn’t the end of the world, it sure is easier to just continue using the original table.  In this case, you use CCUNDO to remove ALL change numbers from the object, thus getting it back to a state of never being under ECM.  Then you can either delete the object and create it with ECM, or just reset it back with the latest change number.

Now one of the biggest things to keep in mind is that I do NOT encourage this to be used in production for anything other than scenario 1.  In scenario 2, you are likely to lose ALL your history on these objects.  Again, not the end of hte world, but having this history is the whole reason you use ECM.

Thanks for reading,

Sales Order – Unit Costing

Well, today I’m going to cheat on my blog post, and instead send you over to read a great post a friend of mine recently did on Unit Costing within a Sales Order.  Rama posts some great things on SD and Variant Configuration, so I do encourage you to check out his blog on a regular basis.  so, without further babbling, go check out his link 🙂

Unit Costing

Thanks for reading,

 

Service Management – RA vs. RAS Order Type

It’s funny, I’ve been doing this for a while, and i’ve always avoided using the RA order types.  I recently got to wondering why I had the bias toward the RAS order type.  So I thought I’d go into the details of the differences.  So, here goes. RA vs. RAS Order type.

It’s actually curious just how similar they are.  The whole concept comes from the “leading material”.  I only recently heard this term and had it stick in my brain.  I was talking to someone from SAP working on an OSS message I had open, and they asked if I was using the leading service material or leading serviceable material.  When I first read this, I sat there with the blank look on my face, wondering exactly what they were asking me.  It finally hit me, depending on what scenario you run, you might “lead” with a DIEN or service material, or you might lead with a “serviceable” material (the think you are fixing.  So, step one is understanding the distinction.

Ok…  so, now we get to the real deal.  Exactly why would I choose leading “service” vs. “Servicable”.  In my opinion, the answer is actually pretty simple.  It all comes down to the processes you have available for any particular material.  Let’s just say you have a material 100.  It’s produced by you and come back for repair.  Now, if the only option is that the customer returns the materials to you, you fix it and send it back, then you either method works great.  BUT, as soon as you introduce some variability, like the service Exchange process, that throws  monkey wrench into the whole deal.  Why?  because of item category determination.  In the back end of SAP, when you use the RA order type, the item category determination works off of the “Serviceable” material.  So it’s all dependent on what you are fixing.  If a particular material is ALWAY fixed the same way, then using the RA is better approach.

Now, as soon as you enter multiple repair procedures into the mix that can be applied to a material, this is when you must go to the leading “Service” material. (RAS order type).  The RAS order type gives you additional flexibility, and also decreased maintenance (in txn OISD) compared to the RA order type.  Now, the RA gives you a more straightforward approach, but in my opinion, it tends to limit your options.  If everything you do is field service, then this becomes less of an issue, but if you ever have the need for multiple repair procedures (or even field service vs. in-house repair), the RAS is truly the way to go.

Thanks for reading,

Service Supervisor – The latest offering

Now, it’s been a while since something got me really excited.  But a few weeks ago, I sat down with my WM guru friend, Jeff, we walked through what would need to happen in order to be able to do “staging” on service orders.  I did a post a couple weeks ago going into all the details of exactly what service staging is, so I won’t bore you again.  I’ve had an idea on my “to-do” list for a couple years now to integrate SM with WM.  Little did I know at the time that this would springboard me into a new idea, that I’m pretty excited about.  It’s the service supervisor transaction.  Now, if you’ve followed my stuff for any length of time, you might remember me talking about a Production transaction I built called Proximity.  The idea is to provide a single location to handle all the SAP work for a shop floor manager or technician.  We built one for the supervisor & and for execution.  Well, frankly, I never gave it much more thought.  This was my partner’s thing, he knows production, so I built it.  Then fast forward a couple years.  I’m talking with Jeff, and it FINALLY hits me.  Why don’t I make a set of transactions for the service shop.  After all, that’s my expertise, why shouldn’t they have a transaction to help in their day to day life.  And before you know it, Service Execution was born.  But something like staging, or releasing service orders is not typically something the service technician does, there’s usually a supervisor.  And next you know, Service Supervisor was born.

I literally just finished this last week, and I’m so excited, that I just had toot my own horn a little bit.  Now I’ve developed lots of things, had lots of ideas…  but this one became special on multiple levels.  First, it provided me with a vested interest in one of our products.  Proximity, up until now was just Mike’s thing, not mine.  Now that there is a rather large service component, I suddenly have a much bigger stake in the game.  Next, I had always had these “tool sets” for service orders.  They were kind of a side project because who wants to buy some little gadgets, even if they are helpful.  Now, I have a vehicle to package them and make them useful within a transaction.  So my service order availability tool that’s been sitting out there forever, is now a button on Service Supervisor.  I’ll still provide the transaction so you could run it nightly, or in background, but now, the supervisor can just run it whenever they want, and for as many orders as they want.

Now, coming full circle, is the advent of Service Component Staging.  After years of wondering what user exits I’d have to program, wondering how could I deliver this as a product, I finally solved all of that.  It’s now my favorite button within service supervisor.  Mostly because I think it’s so cool :).  I’ve included many of the same configuration options you see in WM for production orders, and give you additional options geared toward service.  Including the option to print a picklist to a designated printer every time you stage components.  You can decide what material movement should be used.  I even provide the functionality to do WM to WM transfers, an option you can’t get out of the box for service orders.  There’s more to it, and if you’re curious, let me know because I’d love to explain it to you 🙂

The best thing is that as I come up with more ideas to help the service shop, I can just add them to these transactions and give them to anyone using Proximity.  Then to sweeten the deal, if you buy Proximity, you get service and production, all in one.  Sorry if I sound like an infomercial.  I kinda feel a little like one right now, because this really is cool.

Thanks for reading, and if you’d like to learn more about Proximity for Service, please comment or email me:

mpiehl@javellinsolutions.

Proximity for Service

 

Service Order ROI – Proper Scheduling

I like to jump back to this topic, because I feel it’s very valuable to recognize just how you can get additional return on investment using service orders within SAP.  Now often the points I’m making may not be new information, and even better, it could be things your organization is already doing.  In that case, be sure to remind your executives of the things your group is doing right 🙂  However, if you are like many organizations, take these as possible ideas to make your service organization even better.  Today I want to talk about proper scheduling of your service orders.

Now if you want a great way to realize a return on service management, it is scheduling your service orders in the most effective and efficient way.  Again, this concept sounds so obvious, but in general, I see many organizations overlook this concept and just “wing it” when it comes to deciding what to work on next.  There are a few key things that you can easily do to help increase your ROI on the service order.  But before we cover those simple ideas, let’s focus on exactly what you will gain by implementing these.

The first and most important is a more satisfied customer.  How can it get any better than that.  If your customer sends you back their broken widget, you look at your schedule and give them an accurate date of when they can expect their widget back.  Now, customers will always want things back faster, but in general, if you can live up to your promise date, they will respect and trust you.

Next, you get an efficient service shop.  What do I mean by that?  I mean that you don’t have technicians jumping from one order to the next every 30 minutes, because your missing components, the machine you need is in use, or the technician doesn’t have the required skills.  By letting your supervisor schedule things appropriately, you’ll minimize the jumping around, which leads to getting things done faster.  If you’ve ever tried to do 5 tasks at the same time you know that the more jumping you do, the longer it takes to finish.

The first is using the priority field on the service orders.  Now, I’m not going to pretend that this will solve all your issues, but this is the fastest and easiest way to perform what I consider “rough-cut” planning.  The default priority profile for service orders comes with the standard 4 options, Very High, high, medium, low.  Now for most organization, this is fine.  However, you can easily configure these priorities to be whatever you need.  In addition, the priority fields even give you the option to set start and end dates that the priority needs to use.  The dates are great, but in my opinion, just setting a priority on every service order will quickly give your service technicians what needs to be worked on first.  Just drilling in the concept that all #1 priorities must be completed (or at least taken as far as possible) before looking at any priority #2.  In my opinion, the easier you make the rules, more likely your entire team is to follow them 🙂

The next thing I believe is assigning every order (or operation) to a person on your team.  Now this could be overkill if you have a very small team, but even then, unless you assign everything to the same person, you will get benefit out of this concept.  When you assign a responsible person to each order, you take that next machete slash in scheduling.  This way, if you have someone with a specialty skill, say welding, you can assign all the welding operations to that person so it’s very obvious what that person’s workload really is.  It also gives your supervisor viability on the upcoming bottlenecks for a particular resource.

Next up is the basic start and end dates.  If you set these, and if you have your supervisor monitoring these, now you know instantly what needs to happen first.  Now, if you pair these dates with the priority and responsible person, you have essential built a simple capacity plan for your service shop.  When you have each person looking at what they need to do, combined with the date it needs to start/end, and in the event of a conflict, the highest priority wins, and more importantly your customer wins.

Now, if you are really looking to take your scheduling to the next level, you can start moving toward actual capacity management.  Now, I can’t speak as an expert on this topic, but I certainly know that your service work centers can use capacity planning just like any production order work center.  Now, in the service world, things will always be more “fluid” than in the production world simply because you never know when something will break.  That doesn’t mean you can’t still plan to the best of your ability.

I hope this gives you some ideas to increase your service order ROI.  Thanks for reading,

Service Execution – Our newest offering

Now, I’m pretty excited about this.  This is the execution of my latest brainchild.  Now, this idea really should’ve been obvious to me quite a while ago, but it’s amazing how difficult it can be to see the forest through the trees.  As you may know, we’ve had a product called Proximity, and one of the pieces was production execution.  What I finally realized is that I could take the same concept and apply the idea to the service management realm.  Now the elegance of this solution is the simplicity I can provide to the service/repair shop.

By creating a single transaction that allows any service technician to quickly see the service orders that apply to them.  They can see every operation they need to work on, quickly see the priority, and even any notes that have been entered onto the order.  Then, they can even drill into a specific service operation, they can run availability, they can do a confirmation, if the shop uses PRT’s you can even view those all right in the same screen.

If this sounds like something your service department could use,  please check out our web page that includes a demo on the functionality for Service Execution.

I’d love to hear your feedback and thanks for reading,

Service Order ROI – Parts Planning

Well, it’s been a while since I started covering this topic, so I thought I’d get back to my series on the Return on investment for SAP Service Management.  if you missed some of the previous posts, be sure to check them out:

Notifications – Service Contracts 2

Notifications – Service Contracts 1

Notifications – Maintenance Plans

Notifications – Improve your products

Notifications – Measure Productivity

Notifications – Accurate Warranty Dates

Service Master Data – Is there an ROI?

I might get back to the notifications again soon, but today I wanted to talk about the service order.  I recently did a post talking about the concepts and practice of service parts staging.  Well, that got me thinking about the importance of parts planning within the service order.  Now everyone knows how important it is accurate forecast your inventory levels for production.  And while it’s still a bit of voodoo to figure out what you will really sell over a coming period, you at least have some idea of what to do.  And more importantly, you know exactly what components it takes to make one unit.

Well, service completely defies this logic.  In most places I’ve worked at, there is a “small” percentage of known maintenance coming.  This is often related to service contracts or maintenance plans.  It’s predictable and you know what’s going to happen.  If you want the generic example, oil changes for your car.  You sell a “plan” for discounted oil changes for 1 year, with up to 4 oil changes.  You know that you need to plan for the oil, filter and technician time.  No problem.  You still don’t really know exactly when it will happen, but you at least can guess.  But the real bulk of most service is unplanned and unpredictable.  You hope you’re product is designed to last at least a certain time period without a failure.  But things happen.  The point is, since you have no idea what could go wrong, how do you plan for this???

This is where your service order (and to some extent you service notification) become invaluable for helping you develop your own crystal ball of potential repairs.  Your service order should always contain the material that is being repaired (that’s a given).  But if you are using it correctly, you are also loading up all the time and materials you used for the repair.  This is normally driven from a cost perspective.  But what many people don’t realize is this is building your history, if you just remember to look at it.

I’m hoping the light bulb is starting to go off out there, but if not, let me lead you a little further down the path.  If you start looking at the components used for a particular repair for a material, it’s likely a pattern will emerge.  So let’s say you have you widget, and there are components 1 – 20 used to build it.  Now, if I were to pull every service order for the past year for that widget, and analyze the components (and qty) issued to those jobs, in most instances you should see the pattern of common parts usage.  Typically there will always be the common wear components (in your car this is the oil filter, air filter, brake pads, etc…)  Things you know will wear out and need to be replaced.  But now if I take this one step further, I can start looking at the average time before these components needs to be replaced.  Now, this analysis is a lot harder, because now you need to take into account the date the components was added to the widget (this could be the production date, or it could be the last service date).  However, the information is all in SAP.

Now, let’s just step back for a second.  Knowing exactly how long a component will last is great to know…  but for our purposes, this might be more info than we need.  If we can simply look at the component usage for service over a time span, we can now “forecast” what we really need to keep in stock in order to turn around those customer issues as quickly as possible, while still maintaining minimum stock levels.  Now if you’re already doing this, my hat is off to you.  In general, I don’t see this happen in the service order very often.  For the rest of you, if you’re looking for a tool to help you get this information, check out the Renovation Service Management Dashboard.  We are currently adding several new sets of metrics/reports to this dashboard, including service component usage.  If you could use this information, we’d love to help.

Thanks for reading,

Service Management – Service Parts Staging

It’s interesting, because as long as I’ve been doing service, I’ve always tended to be hands off on this portion of the process.  I left it to the MM or WM person to set this up.  I won’t pretend to be an expert or go deep into the configuration, but the overall process is something i wanted share.  Let’s start at the beginning.  What am I talking about when I say service parts staging?  I’m talking about the process of getting components that will be used in a repair to the service storage location so they can be easily issued to the order upon completion.  It also serves to “secure” the inventor for service.

Now, several of the things I just said, require a little more explanation, and I’ll get to them to shortly.  First, I need to digress a little and explain the 3 most common scenarios for service inventory.

1.  Service uses it’s own IM managed storage location.  Any additional inventory is acquired from an IM managed warehouse.  This scenario is the most common and the most straight forward.  Inventory can be completely managed using material movements.

2.  Service uses it’ own IM managed storage location.  Any additional inventory is acquired from a WM managed warehouse.  This is somewhat common, but still happens in the minority of facilities.  In general, WM tends to be used only for large warehouse with a large number of components.  This scenario becomes much for complicated because any time you deal with a “mixed” environment, you have to deal with material movements, transfer requirements and transfer orders.

3.  Service exists in the same WM warehouse as the inventory it may need.  While this sounds like an easy environment, it’s still a bit of a challenge because service management has no integration with warehouse management.  Now production orders can integrate with WM cleanly (at least in this scenario).

Now, the heart of the issue come from getting the parts to the service order when it’s needed.  This inevitably means that service will need stock from somewhere else.  It really doesn’t matter which of the 3 scenarios you are talking about, each presents it’s own set of challenges.  At the end of the day, we just need components in a location that the service department can access them.

Now, let’s take scenario 1 & 2 together.  let’s say we have a storage location called SERV. This will be the SLOC that service uses.  Now, the inventory that service and production both use will be in a SLOC called INVN. Now for your service parts, at the end of the day, it doesn’t matter if INVN is IM or WM.  To get the parts, you need to execute a material movement, like 311, and then send the pick list over to the warehouse to pick the parts and deliver them.  If INVN is Warehouse managed, just doing the 311 movement will generate a negative that can be converted to a TR/TO to actually move the parts from the bins of your choosing using LB12 or some other variation to create the .  Now, the major challenge is creating the material list to transfer, and then of course performing the actual move.  Now, the good news is that the components are “reserved” because in SAP they have moved to SERV, however the physical move still needs to happen, so it’s important to make sure the pick list gets sent to the warehouse to complete the loop when using the 311 method in advance.

Scenario 3 is actually quite a bit easier.  Since it is completely within WM, SAP provides a transaction called LP10, that allows you enter in the order and then select what bins to pull the material from, and then deliver it to appropriate service order.

As you can see, getting components to the service order isn’t as easy as it looks.  There is significant work, and this should play an important part in your blueprinting for service.  Determining if you want to deal with WM or IM in your service area is an important consideration.

Thanks for reading,

Variant Configuration – Unit Testing the model

Well, it recently came to my attention that when it comes to testing a model, it might not be obvious to everyone some of the cool tools available within in CU50.  While the seasoned veteran may find this obvious, as you learn VC there are always tricks that can make your life easier.  Today’s post is no exception.  Today we’re going to talk about the configured objects button with in CU50.  I’ll confess, this was a button that I knew little about for some time.  But of late, this has become one of the most useful testing tools when sales orders/production orders are generated.

blog02-01

Now, if you don’t recognize the name of the button, this screenshot should refresh your memory, even if you never knew what the button did :).

blog02-02

Now, this little feature is outstanding.  You can enter in a sales order or production order (material is for material variants, but you don’t need to enter this screen to see those.).  By entering this information into this screen, CU50 will bring in the complete configuration from the document, in this instance the sales order.

blog02-03

As soon as you hit enter, the standard CU50 screen will return, but you now get an extra Copy from: section to show you exactly what you’re copying from.

blog02-04

Once you enter the configuration screen, you can see all the characteristic values populated.  Now, this is especially valuable when dealing with sales relevant and production relevant items in the same BOM.  You also have the ability to see the configured routing.

While you can see bits and pieces by looking at the sales order, you often must see both a sales order and production order to see the entire picture.  CU50 gives you everything, and now you don’t even need to copy each and every value.

Hope you find this valuable and thanks for reading,

 

ABAP Web Dynpro – File Download SNAFU

Well, I just spent the better part of 20 hours hacking out my latest issue.  In my Rapier web application, one of the cool features I provide is the ability to download an output document from SAP.  Say for example, a quotation or order confirmation.  Well, I was using some fancy trick that converts the spool to PDF, then using the UI Element File Download.  Everything was great in testing.  No problems.  Then a couple weeks ago, I started updating all my documentation.  I came to do a screen shot of this and it it came out in jiberish.  It happened that I was using Firefox.  I tried it, and it worked fine on Internet Explorer, but all the other browsers displayed the text, instead of the pdf…  WTF!!!

So I did my due diligence, and hunted Google long and hard, hoping for a clue.  Nothing jumped out at me.  So, I then applied the latest support packs to my system.  No change.  Then I thought, maybe the kernel needs an update…  no change…  crap.  That burned through a lot of hours in SGEN time, downloading files, system down time, etc…  all for nothing (well, not nothing, but not the result I wanted).

Finally, last night, I decided to look at the UI Element itself, and what I was mapping to it.  I turned out, I was mapping a blank value to MIME_TYPE.  Interestingly, IE was smart enough to recognize the PDF, but none of the other browsers were.  Since all my dev work was on IE, and much of my testing as well, I missed this little fact.  As soon as I added application/pdf to that field…  magically, it began working on all my browsers again.  Woohoo!!!

Now, I hope you can learn from me again… first off, test your WDP on multiple browsers, unless you know you’re only going to support one browser.  This can’t be done in a customer facing application.  Second, MIME_TYPE makes all the difference.  It explicitly tells the system how to render the file.  Don’t take it for granted.

Thanks for reading,