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.
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.
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.
Afgelopen weekend nog een aantal malen R12 opgestart om mijn probleem met de automagisch gegenereerde taken te fixen, maar dat is niet gelukt. Ten eerste mocht ik op mijn verjaardag niet ‘werken’ (belachelijk!) en ten tweede was het veel te mooi weer om binnen te zitten. Daarnaast heb ik een dag later ook de 11.5.10 omgeving van Ordina er even bijgepakt om daar hetzelfde probleem uit te modelleren. Maar meer dan een uur heb ik daar ook niet aan besteed. Nou goed, even geen R12 dus.
Vanavond ook niet. Ik heb nog wat uit het Wellsprings of Knowledge boek gelezen, een paar ‘o ja natuurlijk’ momenten beleefd en gewerkt aan een business case. Die business case hoop ik binnenkort (wellicht na de vakantie) helemaal uitgewerkt te hebben, maar op dit moment praten we nog over draagvlak-creëer-fase, waarin ik een aantal toezeggingen nodig heb om e.e.a. te kunnen starten. Dus wat die business case gaat inhouden kan ik nu nog niet zeggen. En eigenlijk is het ook niet zo interessant want zodra er geen draagvlak is, gaat ie meteen (af of niet af) in de ijskast. Lekker ingevroren naast al die andere plannetjes en business cases
PS: ja ik ben oud geworden.
Vandaag iSupport weer opgepakt. Volgens de manual moet je wat attributen opzetten, wat lists of values, etc. Geen enkel probleem, netjes doorheen gelopen. Als proef heb ik een Casema situatie opgezet, waarbij externe aannemers gepland werk aanmelden. Da’s een procedure die nu al gehanteerd wordt, maar nog niet lekker is uitgemodelleerd in EBS. Met R12 zou dat goed moeten komen.
Stel een aannemer meldt een dienstonderbrekend stuk onderhoud aan. Zodra het dienstonderbrekend is, moeten er allerlei extra validaties gedaan worden. Een specifieke taak aanmaken leek me wel een goed begin. Alles opgezet, en in iSupport werkt het prima. Maar de taak wordt niet aangemaakt. Aargh! Frustrerend. Manual tot op de letter gevolgd, maar er gebeurt dus niks. Jammer.
Trouwens, specifieke vragenlijsten afdwingen bij bepaalde SR’s wil nog niet echt. Raar, maar zelfs in de standaard Vision vragenlijsten is er niets afgedwongen… dat is toch vreemd? Of zie ik iets over ‘t hoofd?
Gisteravond en vanavond ben ik bezig geweest met onze R12 test instance. Vanuit Casema (mijn huidige klant) heb ik een aantal ideeën over hoe iSupport zou moeten worden ingezet en eigenlijk is het gewoon leuk om te zien welke dingen je kan doen in R12.
Het leukste tot nu is het kunnen definiëren van vragenlijsten. Als voorbeeld in de Vision voorbeelddata kun je de ‘abandoned vehicle’ gebruiken. Dit voorbeeld is een specifiek sjabloon voor… tja, voor verlaten voertuigen. Stel je bent een gemeente en je wilt een standaard proces voor het laten wegslepen van voertuigen die je her en der vindt. Als een voertuig de weg blokkeert wil je met hoge prio een oplossing vinden, als het voertuig een vrachtwagen is, wil je een grote sleepwagen sturen. Klinkt logisch, maar om hierop te kunnen sturen moet je dus wel een aantal gegevens in kunnen vullen die niet zomaar in standaard velden te vervatten zijn. Zo ook voor Casema. Eigenlijk zijn er veel verschillende manieren om Serviceaanvragen aan temaken en de aard van een serviceaanvraag kan veel verschillen van een ander. Een specifieke vragenlijst is daarvoor van essentieel belang.
Verder ziet iSupport er erg goed uit, veel mogelijkheden voor de gebruiker en veel functionele aanpassingsmogelijkheden.
Nou goed, dit waren twee avonden spielerij. Als ik de mogelijkheden van iSupport een beetje in kaart heb, maar eens een echte case opzetten met verschillende gebruikersrollen, verschillende SR- en taaksjablonen, workflows en automatische taaktoewijzingen. Piece of cake.
Ha, mooi man, ik heb even rondgesnuffeld in een R12 omgeving van SolutionBeacon. Mooi spul hoor. Wat dacht je van een inkoopordertje van 150 printers? Ah, Purchasing, ik kan het nog steeds…
