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).
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 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?
Mooi stukje verhaal over een EBS implementatie die niet helemaal normaal verloopt. Gewoon op elke deadline in productie zetten wat je hebt, getest of niet. Wederom een artikel van ZDNet. O ja, Oracle zegt: goed geslaagde implementatie!
Ik hoor het me nog zeggen: “ik wil projecten gaan doen”. Waarschijnlijk iets wat veel mensen zeggen als ze een tijdje aan EBS beheer geproefd hebben. Projecten hebben het. In projecten gebeurt het. Maar wat eigenlijk, heb je daar wel eens over nagedacht? “want ik wil klantprocessen mappen op EBS”, zo heb ik het een keer (ongeveer) omschreven in een sollicitatiegesprek. Het antwoord daarop was: “Dat wil iedereen, maar dat is maar een heel klein stukje van een project”. Dat is me wel bijgebleven. Want wat doe je eigenlijk op een implementatieproject? De klant heeft een proces, een applicatie wellicht en heeft de keuze voor EBS gemaakt. EBS moet geimplementeerd worden volgens zijn specificaties, ‘t liefst net zoals z’n bestaande applicatie en wil zeker geen concessies doen. Los van het feit dat Sales per definitie meer belooft dan je waar kunt maken (in standaard config), is implementeren geen simpel proces. Wat de klant wil, kan bijna nooit 100% in EBS. Maar als je het dan eindelijk hebt afgestemd, wellicht met maatwerk, wellicht met concessies, maar zeker met veel praten en uitzoeken, en dan begint het pas. Implementeren is documenten schrijven. Functionele ontwerpen, testplannen, setupdocumentatie (vanaf scratch he?). Daarnaast setuppen en testen, afstemmen met andere processen en bugfixen.
Wat doet een beheerconsultant dan? Het systeem is er al, en zo nu en dan gaat er iets mis. De discussie waarom er dingen mis gaan, voeren we voor ‘t gemak even niet. Incidenten verhelpen hoort bij beheer. Maar beheer omvat ook het changeproces. De klant wil zijn rapport anders, meer ordertypes of service requests, een aanpassing van de orderflow of een nieuwe autorisatie. Klinkt simpel? Stel nou dat de klant een nieuw product wil gaan voeren. Dit product heeft een hele aparte order flow, heeft grote impact voor de aansturing van bepaalde afdelingen en de financiele rapportage vereist een hele andere aanpak dan ingericht is. Dat is niet simpel setupwerk, dat is een klein project. En ja, daar komt ook documentatie, testen, etc. bij kijken. Soms ook een projectleider. Dan is beheer ineens niet meer zo simpel.
On the side: Ik zit op dit moment gedetacheerd in een beheerorganisatie en alleen maar in het change-stuk daarvan. Mijn werk bestaat uit het ontwerpen van (kleine) stukken functionaliteit die het bestaande proces verbeteren of daaraan toevoegen. Soms een ingrijpende, soms een simpele. Ik word maar heel zelden betrokken bij incidenten, maar het is wel verrekte handig om te weten waar het systeem knelt. Scheiding van incidentenbeheer en change-beheer kan dan ook drempelverhogend werken. Simpelweg door incidentenbeheer laten verifiëren is één, maar samen een ontwerp maken is al beter. Incidentenbeheer zit dichter bij de operatie, dichter bij het klantproces, dichter bij de klant. Dus als er een ontwerp voor nieuwe functionaliteit moet komen, dan wil je toch ook dicht bij de klant zitten, begrijpen waarom de klant dat wil? Maar waarom dan scheiden? Als ik incidenten in bepaalde module mag oplossen, kan ik veel beter met de klant meedenken en veel betere ontwerpen maken. Dus doe ik liever beide.
Terug naar de implementatieconsultant. Die komt binnen met zeer weinig kennis van de klant, maar wel van EBS. Hij krijgt de opdracht EBS in te richten voor die klant en in principe is er één iteratie; nu beginnen over een half jaar live. Met een beetje mazzel is er voldoende branchekennis waardoor de communicatie met de klant een stuk beter gaat. Als implementatieconsultant is mij voornamelijk bijgebleven dat het proces van de klant ver weg is. De implementatieprojecten doe je ‘naast’ het bestaande proces en niet ‘er in’.
Wat ik eigenlijk zeggen wil is dat het werk van de implementatieconsultant en de beheerconsultant niet wezenlijk verschilt. De context is net even anders, qua systeem, qua tijd en qua afstand tot de klantorganisatie. ‘t Is dan waar je de voorkeur aan geeft: veel in-depth kennis van het systeem en proces en daardoor goed kunnen inspelen op de wensen van de klant in een bestaande organisatie, of vanaf scratch een systeem neerzetten waarmee je een organisatie een nieuwe fase in helpt.
‘Beheer’ en ‘Projecten’ verschillen dus ook niet veel. Beheer wordt vaak gelijkgesteld aan incidenten oplossen, maar dat is maar een klein onderdeel. Beheer is niet het beheer van de klantsystemen, maar beheer van de klantsystemen en de klantprocessen!
Als junior ben ik begonnen in beheer. Beheer heeft me zo ontzettend veel geleerd over EBS, wat het kan, waar de nukken van EBS zitten en wat het niet kan. Die kennis heb ik kunnen gebruiken om nieuwe dingen te ontwerpen voor de klant, modules te implementeren en projecten te doen. En hoe langer je met een klant werkt, hoe beter je die klant kan helpen met veranderingen in zijn omgeving. Beheer is meedenken, blijven meedenken, vooruitdenken, optimaliseren, processen herontwerpen. Ik denk dat elke nieuwe EBS’er in beheer moet beginnen (bij de klant of in-house), maar ook goed moet nadenken over wat implementatieconsultant-zijn inhoudt. Als ik moest kiezen tussen nieuwe implementaties of het beheren van bestaande EBS-klanten, weet ik het nog niet…
Gistermiddag skûtsjesilen met OOS (ordina oracle solutions) in Koudum. Prachtig weer, zon, wind, etc. Niks aan ‘t handje. Het eten was ook helemaal in orde. Nog een fles berenburg gewonnen omdat we als eerste aankwamen, ook daarover niks te klagen. ‘s Avonds in Stroobos blijven slapen om vandaag in Groningen aan ‘t werk te gaan. Dat was immers dichtbij? Nou, dat viel dus wel mee. Geheel Friesland en Groningen lijkt wel een wegenbouwput. Gisteravond van Lemmer naar Joure naar Heerenveen gereden, om vervolgens omgeleid te worden naar Wolvega, Oosterwolde en Drachten. A7 was afgesloten, anderhalf uur kost je dat dan. OntZETtend. Niet dat het dan een leuke route is, alleen maar rechte wegen en niks te zien want het is donker. Typisch gevalletje jammer. Maar we hebben het weer overleefd gelukkig 
Vandaag dus Groningen, innoveren zoals dat heet. Toch lastiger dan ik dacht. En toch heb ik het idee dat het in Groningen gebeurt, de sfeer is hier veel hectischer. Er gebeurt hier veel. Mensen lopen af en aan, productieprobleem hier, performanceprobleem daar. Saai is het zeker niet. Mooie plek om ideeën op te doen, want die hebben ze hier legio!
Ja, wat is dat nou? Steven stelt dat er geen vraag is en dat ze er daardoor ook geen effort in de certificering steken. Vandaar dat hij vraagt om even aan te geven welke Linux Desktop je draait, welke EBS-release en welke modules. Rara, wat klopt hier niet?
Ach, ik zie het al: uit deze post (over Vista certification):
‘This has visibility at the highest executive levels in both of our respective organizations, so this certification effort has been prioritized accordingly. Both Oracle and Microsoft are highly motivated to complete this certification as soon as possible.’
Microsoft maakt dus afspraken over de certificering van Vista, maar stelt de voorwaarde dat Oracle niet “de” Linux Desktop mag certificeren. ‘Nee, da’s goed’, zegt Oracle, ‘dat project loopt al twee jaar en we zeggen gewoon dat we te weinig input krijgen van de markt. Geen vraag, geen aanbod, toch?’ Goed uitgespeeld, Microsoft! Jammer, Oracle…
