Current project has been given an end date. The main reason? Some business rules cannot be implemented in Field Service, which leads to too much manual intervention/optimization, which makes the legacy system just as good, if not better.
Been working for over a year on this project, but all good things come to an end. So if you’re in need of an experienced R12 Field Service consultant (or Purchasing, Order Mgt, etc). Please let me know.
I got an invitation the other day to take a tour around Field Service 12.1.2. Last Tuesday I spent an hour with my contact in India who showed me what was coming up. To say the least: I was impressed. So many things that are lacking nowadays and actually costing the business money are now solved. The Gantt-chart has been revamped (but is still not maximizable, alas) and basically gives the dispatcher much more control and information. There’s no need to open source-documents to adjust any SR or task information, you can do most in the Gantt itself. Just search for a task, locate it on the plan board or Gantt and adjust any values while you’re at it. You can even create (personal) tasks within the Gantt.
The most impressive thing I saw was the new Scheduler Rules UI. This is just genious. You know all these profiles for Scheduler and cost parameters which you enter in some shady form deep within the Field Service responsibility? Well, from now on all (yes all) parameters have been put on one form, Oracle even introduced some new cost factors. What’s even better: They made it “flexible”. You can have cost options / profiles on 6 different levels: site, application, responsibility, user, territory and resource. Consider this for a moment.
For example, you can put all the contractors in one territory, assign rediculously high cost factors, so internal employees will always have the benefit when scheduling. Only when there’s really no other option, external contractors will be used. Another way to do this is to use newly introduced stand-by shifts (comes with a cost factor as well). Just schedule everything to the regular shifts and if you’re understaffed at some point, a stand-by shift (e.g. contractor) is considered as well. The decision to hire contractors has always been a manual one, but now Scheduler can make it for you.
I remember having a live demo at Oracle-NL a few years back. They showed us 12.0.0 Field Service. The customer I was with at the time was using 11.5.9. The whole experience was pretty disappointing then, since there were no real significant improvements (at least for this customer). To me it seems that Oracle has caught up with the demands from the customers and is finally investing in this module. It’s starting to look great.
If you want to read through all changes in the next release, check the release content document (rcd) for 12.1.x on metalink (doc id 561580.1)
Navteq is doing some demos at Oracle Open World this year. As a Field Service consultant (among others) I really like to know about this particular showcase: “Oracle Field Service (Wednesday, Oct. 14, 1:30-3:30pm)”.
Geodata is just data I reckon, so I’m curious too see what this showcase would show us. Have they done some cool stuff to make Scheduler work better? Or is it: we can work with Scheduler as we have for a few years now and it still works. Whatever the case, I’m not at OOW this year, so if anybody is going to attend this demo, please let me know how it was.
Would this be it? I logged enhancement request 6878526 with the idea of Scheduler taking into account the rank of the territory when scheduling. The RCD of 12.1.1 has this in it: “Sort Winning Territory Resources by Absolute Rank”. Meaning my previous post would be solved? I notice it says Casema wanted this feature… 
So yeah, I’m thinking this might be it! I still wonder whether costs are assigned to rank… without higher costs for lower ranks Scheduler might still choose a resource from a lower ranked territory because the travel time is lower. Questions, questions.
Other than that, Oracle also has done some significant optimization on the Scheduler part. When scheduling tasks to resources, Scheduler will firstly sort the tasks to their geographic proximity. This means travel times will be more optimized. I wonder how much better this works when you don’t use plan windows, but we’ll have to test that. I mean, sorting on geographic proximity is quite worthless if you want to optimize the promised time (as opposed to a window), but in that case you find the promised time more important than the reduction in travel time. Which might be very valid for your business case. Nevertheless, this feature could be very useful.
The other major feature in Scheduler is the long awaited cross-engineer-optimizing. Scheduler used to optimize single trips only, but R12.1.1 now optimizes across trips / across engineers. Basically this is what you want. If you have 100 engineers to schedule every day, you can’t verify manually if Oracle really optimized all schedules. Optimizing all individual trips would still not tackle the case in which some of the tasks at engineer 1 would be lower in cost when assigned to engineer 2. This new feature promises to solve this issue. You might want to schedule this Optimization Program (it comes as a concurrent program) a few times a day, so you don’t have engineers doing nothing at the end of the day (because optimization might reschedule the tasks to less engineers).
With two customers I have worked for with Field Service, both of them had the following requirement: “schedule tasks to internal employees first and if there’s no capacity, pick an external technician”. This requirement cannot easily be met. In the most simple way, plan your tasks in two steps
To do this, you need to define two territories, one with all employees, one with all external technicians. Add a match criterium “task status = reject” to the second one. For rejected tasks, Scheduler will choose the second territory to pick all the external technicians and evaluate the skills, capacity and other parameters.
This might work fine if you can afford to batch schedule all of your tasks. If you’re working in a real-time environment, this is harder. If your business has a high volume of appointments per day, appointments that need to be scheduled while the customer is on the phone, the call center agent needs to be able to promise something. Promises are sacred. Scheduler has a window to promise option that will give the call center agent windows to pick from. When Scheduler selects the right resources to turn into windows, it takes only the employees, not the external ones (because of the match criteria). This is logical, because you want to optimize internal resoruces first, before turning to external technicians. The thing is, when you run out of employees, you run out of windows. How are you optimizing now?
One possibility would be to put all internal employees and external technicians into one territory, create a second and a third territory with a match criterium and put all of the employees in the second, and all the external technicians into the third:
The call center agent would be able to get its windows / capacity from all of the resources, i.e. territory one. The Planning Desk or Dispatchers would then reschedule all planned tasks, which have the status from_call_center. This way all internal resources are ‘optimized’. Dispatchers might want to check the result and when it is satisfactory, they’ll schedule all of the tasks which have been rejected by the previous run. All the rejects will now be scheduled to external engineers.
This should work. And yes, you’re still batch scheduling your resources, something you rather don’t.
A common misunderstanding is that the Rank in Territories is considered by the Scheduler, this is not the case! Rank only plays a role in selecting a resource as input for the Scheduler. Scheduler then discards all ranking and evaluates all resources as equals. Would be nice when Rank did play a role, especially for real time scheduling, wouldn’t it? Enhancement Request 6878526, please add your “I want it too” remark.
Is it April allready? Wow. Time flies when you’re having fun. I’ve been pretty busy since my last update. Oracle provided several patches for the bugs we filed, but still hasn’t come up with a satisfactory solution. We did find a work-around for the geocoding problem, still not fixed though. We have the problem under control, we didn’t solve it, but it works: travel times are correctly calculated. The trick? Schedule the “find invalid address” for every 5 minutes. After running it, all tasks that lack a hz_location will now have one. Don’t ask me why, I haven’t had time to dive into the code. Please, please don’t tell me this is how it’s supposed to work.
Also some side projects have taken off. We’re implementing a webservice to create service requests from other applications. Nifty stuff. I had to test it, and review all kinds of documentation. I think we got it up-and-running pretty good now. With this webservice we can also connect a website through which customers can enter their Service Requests. Yeah, I know… sounds a lot like iSupport. But iSupport is not part of the architecture landscape, so we have to find other means. A general webservice does the trick nicely together with the allready existing websites.
Now the technology is working, we need to implement it within the organization. Although that sounds simple, it actually isn’t. SR’s used to be entered manually and any error correction was done at data entry. Now SR’s will be automatically inserted and you have to do some data validation before starting to schedule. This change takes some time to think it through, design the process, find the exceptions in it, fix / work around those, instruct the dispatchers, etc. Might take as long as creating the webservice itself. Maybe by then Oracle has come up with a fix.
I’m not sure how this went, but it’s too much coincidence if it weren’t all related. This is what happened: I’m working on an Oracle Field Service implementation and apparently a lot has changed under the hood in FS and Scheduler. Bit by bit we’re uncovering some bugs and every now and then a feature that’s supposed work but actually has been eliminated entirely. For one of these bugs I raised an SR through Oracle Support. Things weren’t going fast enough so I thought I’d try to find somebody who might expedite things.
Through a contractor, with whom I worked before, I came in contact with someone from Oracle, who does Field Service related stuff. I actually met him at Open World 07 and my contractor friend allready said to contact him if I needed any help with FS. So I explained some of my worries to him and he immediately forwarded my email to a product manager for Field Service in India.
Two days later, the guy working on my SR at Oracle Support contacts me that somebody from product management India wants to speak to me: if it’s okay to send him my contact details. Ofcourse it is! 5 Minutes later I’m explaining the whole business case to a very cooperative product manager. I explained why my bugs were important, how it relates to daily business and how it impacts the roll-out to the rest of the organization. He on the other hand could give me some insight on how far the product development was, which bugs were allready fixed (SR still says: assigned to dev) and what features, which I needed badly, were in what current or future release.
He wants to stay in touch so he can follow up on the implementation, which major issues we face, how well the product is received by the business, etc, etc. I’ve never had such contact with Oracle before, but I like it very much!
Looking back I have to conclude all things are related. Having sent that email got the attention of the right people and connected me to them a short while later. Knowing the right people pays off. Thanks guys.
The week of 9 feb has been full of snow in Hinterglemm, Austria! 2 days of sun and 5 days of snow. I think we got more than 50cm snow during those couple of days. It’s been more ploughing than skiing, but it was definitely fun! Even managed not to break anything!
This week has been as busy as the ones before. My project focus shifted somewhat to other-than-field-service related stuff, which is hard sometimes but always interesting. The bug I found two weeks ago wasn’t solved during my week of snow, even worse, it wasn’t considered a bug at all and therefore an enhancement request (that’s what Oracle Support said on my voicemail). I was really frustrated about that and I didn’t want to accept this, because the workaround for it isn’t workable at all. So when I came back from Austria I explained the problem again and now Oracle considered the behaviour a bug and is fixing it as we speak. Frustration gone, waiting for Oracle to come up with a patch. Let’s call it a miscommunication and leave it at that.
One thing that struck me was that Oracle Support mentioned that another customer was also asking for a resolution of this bug. So another customer is actively working with Field Service R12 and they’re supposedly on 12.0.4. Interesting. If someone knows who they are, I really want to get in touch with them to exchange some experience with R12.
Biggest challenge Field Service related is the geocoding of locations that doesn’t seem to go right. When scheduling a task, the traveling time is set to a default value. This happens a lot, but we can’t reproduce it on a test environment. It seems the postal code geometry is there but the coordinates aren’t copied to the hz_locations. This happens only on production… Challenging 
I’m working on this problem from the sidelines, because my colleagues are tackling this one. I’m thinking a technical issue, because from a functional perspective (we think) we ruled out everything.
I’m neck-deep in a Field Service implementation. I’ve got a sort of love-hate relationship with this module. For companies Oracle Field Service is hardly ever the reason to choose Oracle EBS, but mostly it’s good enough to use. That’s something I have to live with and explain a lot. Usually companies choose Oracle EBS for financials, for CRM or just because everyone in the (vertical) market uses it. Field Service is then usually used because of its integration possibilities. You have to admit: integration is one of the better aspect of this module.
In a previous project I tried to think of as much reasons why Oracle Field Service was NOT the module they should use – some of them were:
In the current project, the business case is totally different. A lot less field employees, a lot of different skills and tight travel schemes. And actually I’m thinking: this project might be a very good fit for Field Service. Yes, there are external resources, but they need to have very specific skills and they have to do some kind of intake before they are allowed to be hired (I guess). But still there are some aspects that Oracle can’t handle. For example: Oracle can’t handle flexible constraints like “max of 10 hours a day of work+travel” or “if there are still internal resources available, use them instead of external resources”. The latter seems possible, but the scheduler first qualifies all the resources based on territory criteria and then checks availability. There’s no cost factor for external resources (enhancement request / bug nr = 6878526) unfortunately.
Talking about enhancements: I’ve logged enhancements for two ‘opposites’: the opposite of skills called inabilities (bug no 8203169) and the opposite of preferred resources, with the very inspiring name ‘unpreferred resources’ (bug no 8203096). Both sound very logical to me, because how else to deal with employees with allergies? Or employees who messed up at a customer, meaning sending that person again would lower customer satisfaction?
Now I’m thinking hard on how to optimize the current implementation, not only in the application but also in the organization. And I’m looking forward to 12.1 which promises more advanced scheduler optimization possibilities (RCD metalink note 561580.1). Yes, Field Service takes up a lot of my time, even while not working billable hours. Guess that’s a good thing, or is it?
