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

The 10 Year Plan

Well, the new Traction book I’ve been reading is forcing me to look at my endeavor as a business for the first time.  One of the first steps is to stop and decide what you want out of the business.  This is a time to be a bit realistic and a bit optimistic.  Consider this your goal.  Like every goal, it should be attainable, but don’t settle if you believe you can achieve more.  It’s strange, but something so simple is really more challenging than I expected.  When you force yourself to take an honest assessment of what you have, where your going and where you want to end up…  well, it’s eye opening.

So, how do you go about figuring out your 10 year plan?  Quite simply, just start writing.  You start with your objective.  Do you want to sell this and start again?  do you want to run this forever?   Then, you need a revenue number, it could be a sale price or a yearly .  Can you be $1,000,000 per year?  $10,000,000?  more?  Now’s the time to take a guess.  Now, you need to figure out how you’re going to get there.  What is your business?  How do you plan to evolve over the next 10 years?  Obviously, you can predict everything, but you need a game plan, a direction, a vision.  For example, I know that if I’m going to survive in the world, I need to be involved in the Internet of Things.  In what fashion, I can’t say yet…  but at least I have a vague vision 🙂

Now, fill in as much of your vision as you can.  How many employees do you have?  what is profitability?  Are you expanding into new businesses or industries?  Anything you want to happen, write it down.  Then refine it.  Based on the details are you numbers feasible?  Can you really get enough customers to make the revenue number?  Be honest…

More to come.  Thanks for reading,


Solution Manager – Approving the Download Basket

Well, finally, I learned a trick in solution manager.  I have struggled with downloading support packs and patches.  Up till now, I had to deal with the hassle of entering a support ticket, and waiting for SAP to approve it.  what a pain.  Well, now that I have a working solution manager, I can finally take care of things myself.  So, here’s the trick:

option 1

1.In the left frame switch to Operations.

2.Then, choose the tab Change Management.

3.Choose Maintenance Optimizer.

4.Choose Create New Maintenance Transaction and select the system for which you want to download the patches and confirm at the end


option 2

Login to solution manager system run tcode SE37–>Enter the function Module: /TMWFLOW/MO_UI_BASKET_AUTHORIZ and press F8 ,Leave the default values and execute again now you can see maintenance optimizer screen there you select the files and click on confirm download so that you can start downloading

Pretty easy,

Thanks for reading,

Independence Day…

As it was just the 4th of July, I can’t help thinking about the complete deception we give ourselves.  Please indulge me my occasional world outlook.  🙂  When you looked back at the fight for independence our forefathers fought to provide us.  The idea was to make us free from England.  The funny thing is that there will always be a master.  When we declared ourselves free from set of masters, it simply creates a void that will quickly be filled by the next willing master.  In our case, it was our own government, that our forefathers work so hard to keep simple, unobtrusive, and supposedly designed to protect our liberties.

The sad truth of it all, is that it seems most people long for that control.  While we claim to be the land of the free, we are quickly giving away all of our liberty in exchange for “security”.  or so we tell ourselves.   Good old Ben Franklin said it best “Those Who Sacrifice Liberty For Security Deserve Neither.”  Well, between the random wars, police actions, and conflicts we force our way into, all in the name of security, it should be painfully obvious that  security dwindles as quickly as liberty.

So please, remember that the struggle for liberty is not a republican thing, it’s not a thing…  it’s a personal thing.  So I hope you still want you liberty.  If so…  just pay attention to how easily it keeps being handed over willingly.  Just watch the news with a different perspective.  Put your political beliefs aside for a week.  If you truly look at everything in an unbiased fashion, it will incredibly obvious (and should be painful).  Step one is the realization.

Going back to one of my favorite movies, Red Pill or Blue Pill.

Thanks for reading,

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…


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,

Check out the new Website

I have to say, I’m pretty excited.  this new website is truly light years ahead of my old one.  Tuesday night I officially changed over to a whole new look and feel.  I would really love to hear your feedback.  If you have a few minutes, stop by, read a little, and maybe comment on your thoughts.  Feel free to respond to this post, or email me directly:

thanks a lot, and I can’t wait to hear what you think,

Installations in SAP – Project Systems vs Service Management

I 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,

Sales – Implicit vs. Explicit Needs

I recently listened to an audio book, another addition from Jeff, called SPIN selling.  The idea is Situation-Problem-Implication-Need Payoff is a way of selling.  One of the biggest take aways I got from the book is that selling big things is a lot different than selling little things.  I did a post that talked about closing not being the answer.  Well needs is the step you need to focus on instead of closing.  Here’s the idea.  Every customer has a problem… if they don’t, well, you might as well move on.  But just having a problem isn’t a enough.  Just because someone says “my car doesn’t get very good gas mileage”, doesn’t mean they are going to jump right up and go buy a new car.  Yes, they have a problem, but problems aren’t necessarily needs.  At least not directly.

This is where the needs conversation begins.  First, your customer must have a NEED for solution.  If they have a need, you have a chance.  This comes to the concept of implicit needs vs. explicit needs.  I’m still working all of this through my head (but as you may have noticed, I tend to think better after writing some stuff down), but the idea is that an implicit need is more like a problem statement while an explicit need tips over to the want or desire category.

Let me illustrate.  If we go back to the “bad gas mileage” example.  Simply stating that the car gets bad mileage is an implicit need.  Now, as soon as someone says, I need a car with better gas mileage, you have now jumped over to an explicit need.  It’s very subtle, but just admitting that you want or need something, buts you into a buying position.  Being a man and being an engineer, I often miss this subtle difference, especially when I listen to my wife talk about all the things that would be “nice to have”, like a new deck, a mansion on the water etc.  I need to manually flip the switch in my brain to not panic…  it’s just an implicit need.  Now, as soon as my wife starts talking about buying a boat, I know without a doubt it’s an “explicit need” at least in her mind.

Now, this applies in normal life as much as sales.  Pay attention to difference the next time you talk to friends or family.  See if you notice the difference.  it’s pretty cool when you can start to notice the difference.

Thanks for reading,

Warranty Claims: A Guide for Beginners

Warranty Claims General Information

For any of you that have ever configured the warranty claims for the first time, you’ll probably notice that same thing that I did.  There isn’t a whole lot of help out there on the internet.  That’s why I’m writing this article.  I haven’t implemented everything about warranty claims, but I’ve done several working models and wanted to make it easier for someone out there who might be doing it for the first time.  The Warranty Claims module I’ll be talking about is in SAP ERP 6.0.  I believe warranty claims may go back as far as 4.6 or 4.7, but I”ll be honest, I’ve only worked on tem in ERP 6.0.  Regardless, most everything I discuss in this blog will apply no matter what version of SAP you’re implementing in.

First, the basics about warranty claims.  Let’s start simple, what are they, and why would you need to use them.  Warranty claims are the SAP provided method of handling any claims from a customer or third party.  You will typically use warranty claims in any event where the reimburser (whomever is actually paying for the repair) does not do the warranty/repair work, but rather outsources the work to another party (the claimant) and pays them for the time and materials.  Keep in mind that the party that does the work can be a subsidiary of your own company, or even a regional office.  The main concept behind the claims model is that you will be paying someone else to perform the repair.

SAP has built in the option to use IDOC’s to load in many of the steps of the claim, or you can process  it all manually.  The scope of this article will only cover the manual steps, mostly because if you can do it manually, the IDOC method just is a quicker way to load the information.


As you may have noticed, SAP has its own terminology around the claims.  You’ll notice a couple of key terms that I want to define to make your life easier.

  • Customer – this is the end user that is having the warranty/repair work done.
  • Claimant – this is the repair shop, 3rd party service center or regional office that does the repair.
  • Reimburser – this is whomever is paying the bills.

Steps of the Claim

Depending on how your claims business works, there are four general steps or segments to the warranty claim.

  • Step 1: From Claimant
  • Step 2: To Reimburser
  • Step 3: From Reimburser
  • Step 4: To Claimant

I’ll go into more details on each of these steps and what sort of information gets passed a little later.  Also, you may not need all of these steps, and SAP does a nice job of letting you control the flow of the claim however you need it to work for you business.

Claim Categories

The next big thing to understand is the general types of claims that you can configure.  Like I mentioned earlier, SAP does a great job here of letting you configure what you need, but there are 3 main claim categories.

  • Pre-Crediting – the warranty credit memo is created for the claimant before waiting for a reply from the reimburser
  • Post Crediting – the warranty credit memo for the claimant is not created until an answer has been issued by the reimburser.
  • Recalls – this isn’t so much a claim type, as it a way to group and collect claims.  A recall works like a claim “campaign” in that it allows you start one recall with the basic information and then all of the subsequent claims are connected to the recall.  A recall will not go through all four steps of the claims.

SAP provides several other out of the box claim types, but these 3 are really main ones you’ll ever need to start with.  You will generally pick one of the 3 above and copy it to get started when you do your configuration.

Getting Started

The Customer Warranty Partner Type – AS

Now before you get started really doing your claim, there are a couple of things that need to be in place first.  The biggest thing is the partner type AS needs to be configured and assigned to your sold party as a possible option.  This partner type is a hard requirement to using warranty claims if you intend to include the “customer” in your claims.  The AS partner type simply says that the sold-to party (and it must be a sold-to party to work in the claim) is eligible to be used in a warranty claim.  Now depending on your scenario you have a couple of options of how to set this up on your sold-to party’s partner determination.

  • When you define the partner type of AS, it is recommended to make it a required partner of your sold-to parties if you could be receiving a warranty claim from any customer.  If you only receive claims from a limited number of customers or if you don’t know or don’t care who the end user is, then this step isn’t needed.
  • If you do set the required flag on the partner, it is recommended to update all existing sold-to parties in order to automatically add the AS partner type.  Gui Script is a great way to handle this if you don’t have the IT resources to do a more formal load.  You really just need to visit each customer once your partner determination is set and press save.  The new partner will be automatically added.

To give you some ideas, one of my previous clients processed the warranty claim as a sort of intercompany claim.  The regional office fixes the part for the customer, the head office then reimburses some percentage of the cost to the regional office, and then the regional office credits the customer, or simply performs the work.  In this event, we wanted to capture the customer because the warranty claim was used to move dollars from the head office to the regional office and from the regional office to the customer.  Since any customer could have a warranty claim, we set the AS partner type as required and added it to every sold-to party.

Vendors – Claimants

Now for every claimant that you have in your system, it must also be linked to a customer.  It seems a little odd, but the way the warranty claim functionality works, you need a customer for every vendor that will be a claimant (service job) and you need to make sure they linked to each other.  Also remember, that the customer must have an AS partner type assigned to it, even though it is a vendor.


Processing the Claim

Overview of the Claim Flow

Now that you know about the preliminary pieces you need to have in place, let’s talk a little about the flow of the claim.   Below is a sample flow of how a warranty claim can look.  Keep in mind, you don’t need all of these steps, but they are available if your process requires it.

Warranty Claim Process Flow

You’ll notice this flow shows all 4 versions of the claim. Next, we’ll talk about each of the different claim versions and their purpose.  After reviewing each of the steps, you should have a good idea of what versions you need in your process, and what information you wish to collect at each step.

Version Information

The purpose of so many versions in the claim process to capture what each party is asking for, as well as what is agreed to.  For example, the service shop may be requesting $500 of labor and $250 of parts, however your agreement only covers parts.  In that event, version 2 would show $500 of labor and $250 of parts.  Version 3 would show only $250 of parts.

Now the claim can hold a large amount of information in each version, and I’m going to cover some of the high points, but please be aware, there are a lot of fields to capture as much information as you need.  You also have the ability to configure the layout and what fields are visible in each tab of the claim.

Header Information includes all the partner information, including the end customer or vendor depending on which version of the claim you are looking at.  It also includes the equipment record (or serial number, etc), it will contain a multitude of dates (much like everything in SAP) to say when the failure occurred, when the claim was sent in, etc…  It also contains several different text and long text fields.

One of the most useful features of the claim is that you can capture all the parts, labor, subcontracting and break it down in a complete list, so you can see everything that was used in the repair by your service shop.  Each item is broken down by category, qty, price requested, etc.  You also get complete pricing functionality inside of the claim including a special pricing procedure specifically for the claim type.

You can even create a service or quality notification directly from the claim (and it will be shown in the claim document flow).  One of the drawbacks, is that the notification does NOT show the claim as part of the document flow, but nothing is perfect.

Processing the Claim

The biggest thing all the version have in common is the action button.  This is how you process the claim and move it from status to status, and can create a new version depending on the action selected.  The action button is what you press at each of the claim.  When you’ve reviewed it, when you’re ready to send it to the reimburser, when you want to post a credit to the vendor’s account, etc.  Using this action button and paying attention to the status of the claim is how you will know what still needs to be done, or who should be processing it next.  This is also one of the main pieces of configuration for the warranty claim.  You can go anywhere from any status, as long as you configure it as an option.  It’ll be important as you begin your configuration to pay attention to your options, and keep in mind what you think you want your claim to look like at each step of the process.

Version 1 – From Claimant

This version is all of the information from the customer, to your service provider.  If your process starts at the end user, and you want to track it all the way through, you’ll start at Version 1.  You will typically use this claim step if your company is both the service shop and the reimburser.  One example of this is the intercompany scenario.

I recommend creating the service notification from this version if you will be performing any sort of repair.  This will allow the document flow to capture the notification, repair sales order, etc. so that all of the information can be kept together.

For this version of the claim be sure to set the partner equal to the customer.  You must use a Sold-To Party with an AS partner type.

Now, if you are processing the claim manually, be sure to uncheck the Manual Processing box.  This was a point I struggled with for a while.  If you don’t uncheck this box, you can’t process the claim to get it to version 2.  Never did find any documentation that explains this, but it sure gave me headaches for a few days while I played with random pieces of configuration and pushed lots of button before I tried that one.

Version 2 – To Reimburser

This version contains all of the information from the claimant to the reimburser.  This version will be used regardless of your scenario.  The information  is everything from the service center.

For this version of the claim be sure to set the partner equal to the vendor.  You must use a Vendor that is connected to Sold-To Party with an AS partner type.

Version 3 – From Reimburser

This version contains all of the information from the reimburser to the claimant.  This version will be used regardless of your scenario.  The information  is everything approved by the reimburser.  In short, this version is what the reimburser will pay the service center.

For this version of the claim be sure to set the partner equal to the vendor.  You must use a Vendor that is connected to Sold-To Party with an AS partner type.

Version 4 – To Claimant

This version is all of the information to the customer from service provider.  This version will include everything that is approved to be sent to the end customer.  That may be a credit to their account, it could be spare parts or could simply repairing the part under warranty and sending it back.

For this version of the claim be sure to set the partner equal to the customer.  You must use a Sold-To Party with an AS partner type.

Next Steps

Now that you understand the warranty claim process a little better, you should be in position to decide how you want to configure the actual claim.  What I recommend doing is play with the SAP standard Pre-crediting or Post-Crediting scenario, whichever is closer to what you think you will need.  Run through at least 1 complete claim and pay special attention to all of the statuses and all of the options you get with each status.  This should give you some really clean direction of what you need your claim to accomplish, including some of the steps to undo a mistake.

Re-evaluating the Business – Making a plan

My new buddy Jeff turned me onto a new book (well, it’s new to me) called Traction.  The idea behind this book is to get a grip on your business.  Well, this is right up my alley.  Lately, Perry Marshall has been talking a lot about working “on” your business, not “in” your business.  Well, I am VERY guilty of spending all my time working “IN” my business that I often forgot about the business itself.  I’m so focused on writing blog posts, adding new features, and contacting prospects, that I quickly realized that I only have a “high” level plan at best for my business.

Now over my career, I’ve often gone back and forth about my goals for JaveLLin Solutions.  Sometimes I look at it as a self sustaining business that I can move me out of the consulting world, so I can pursue my dream full time.  Other times, I get more ambitious, thinking that in 5 to 10 years, I want someone to buy me out for millions of dollars, and finally I have the idea of building a business that I could leave to my kids (this one is a bit more far fetched, since who knows if my kids would be interested… after all, my oldest boy isn’t even 5 yet.  ha ha ).

My point is that my “plan” has been vague at best.  This new book is forcing me to sit down and decide what is my plan.  As the old saying goes, if you don’t where you’re going, how do you plan to ever get there?  or maybe you’re already there.  And I know that personally, I’m not there yet.  So I need to start focusing on what I want to grow this business into.  The book is interesting, and I’m sure I’ll be posting more about some of the ideas I’m getting soon.

But you need to walk away with this thought.  What is your plan?  are you waiting on social security?  a pension?  a lottery ticket?  or do you know what your goal is and at least have a direction for getting there?  if not…  do yourself a favor and spend some time thinking about it.

Thanks for reading,

Maintaining the Website

I recently started to revamp my website (thanks Jeff).  Until just recently, I didn’t realize just how out of date it was.  That doesn’t even account for all of the things that just were not set up well enough.  But it brings up a great point.  If you have a website, how often do you update it?

Now, until recently, I know that I have barely touched mine in about 12~16 months.  I’ve gone through and added new comments on some of my products, and even added a new page for something I recently did.  But now that I look at it, it’s not nearly often enough.  More importantly, if you don’t renew your content, why would anyone come visit?  you make get the occasional new reader, or someone directed there from a link, but if you want to establish yourself as a brand, you need to make sure people want to visit.

Now, this site has had the added bonus of my blog.  That doesn’t change the fact that this site could use a significant overhaul as well, but one thing at a time.  My site doesn’t have a blog, it only has my products.  And since I can’t develop fast enough to have new content on a weekly or even a monthly basis, it tells me that I need to revisit my site more often.  Even if it’s just changing some images on the home page, talking about the latest event I attended, or whatever.

Now, I’m not crazy enough to believe that people will be following my site religiously.  I’m feeling pretty lucky that I have some of you as steady readers.  But, the way I look at it, if I change things up at least quarterly, it might encourage people to at least scan the home page.  And that would be a victory to me.

My question to you guys…  how often do you update your site?  It doesn’t have to be a complete overhaul or new theme, but at least go back and revisit every page and verify the content, maybe change some text, or add a new picture.

Thanks for reading,