Management samenvatting

Management samenvatting Functioneel Requirements Document 0.91

Achtergrond De keten van containerbinnenvaart van/naar/binnen de Rotterdamse haven moet worden verbeterd om de huidige inefficiënties te reduceren en om groei te faciliteren en stimuleren. Sinds april 2011 werken ketenpartijen aan gezamenlijke verbeteringen binnen het Nextlogic project (voorheen KoCoBiVa - ketenoptimalisatie containerbinnenvaart). Hierbij wordt primair gekeken naar: • Het verbeteren van de (integrale) planning van terminal en depot slots • Het realiseren van efficiënte bundeling van stromen (call optimalisatie) • Het meten van de performance • Effectieve informatie-uitwisseling

Dit document beschrijft de functionele requirements (FR) zoals deze zijn opgesteld door de Nextlogic subwerkgroep TD-slots. Deze subwerkgroep heeft zich primair bezig gehouden met de allocatie van timeslots voor de afhandeling van binnenvaartcalls bij terminals en depots. Het FR beschrijft het Nextlogic proces voor een centrale, neutrale & integrale planning van de containerbinnenvaart afhandeling in de Rotterdamse haven.

Functionele requirements Functional requirements is een Engelstalig begrip. In het Nederlands betekent dit de documentatie van de vereisten voor een toekomstig systeem in de vorm van een formeel document. Dit document wordt gebruikt als input in het ontwerpstadium van de ontwikkeling en is leidend bij het opstellen van een functioneel ontwerp en een technisch ontwerp, daar het de elementen en functies beschrijft welke in het te realiseren systeem benodigd zullen zijn.

Gevolgd proces Gedurende de periode januari 2012 – augustus 2013 is de subwerkgroep TD-slots met daarin vertegenwoordiging vanuit depots, zeehaventerminals en de verschillende segmenten binnen de binnenvaart (specifiek: Rijnvaart, Rotterdam-Antwerpen vaart, binnenlandse vaart en het Vletwerk) gemiddeld drie wekelijks bij elkaar gekomen: een totaal van 26 keer. In deze sessies, welke doorgaans een dagdeel (soms langer) duurden is gezamenlijk gewerkt aan de definitie van het (nieuwe) Nextlogic proces. De subwerkgroep is hierin begeleid door de Nextlogic programma manager en een analist vanuit de Nextlogic projectgroep. Eerdere versies van dit document zijn besproken in de Nextlogic werkgroep en teruggekoppeld aan de stuurgroep. Voor een volledig overzicht van zij die meegeschreven hebben aan deze requirements wordt verwezen naar de tabel op de tweede pagina van dit document. Alle ontwerpbeslissingen zoals genomen gedurende dit traject zijn gedocumenteerd in een apart werkbestand met de naam “Nextlogic - slidepack swg TD-slots - yyyy_mm_dd.pptx”. Parallel aan het opstellen van deze functionele requirements is de volgende projectfase voorbereid. Leveranciers zijn geselecteerd voor de realisatie van BREIN en PLATFORM, waarvoor deze requirements leidend zijn. BREIN is de beoogde optimalisatiemodule welke de planning van calls binnen de Rotterdamse haven voor haar rekening gaat nemen en mogelijk in de toekomst ook gaat ondersteunen bij het bundelen van containerstromen. Quintiq, een Nederlandse leverancier van advanced planning systems, is hiervoor als leverancier geselecteerd. Deze selectie volgde op een Europees aanbestedingstraject geïnitieerd door Connekt/ IDVV, waarbij een aantal leden vanuit de subwerkgroep TD-slots en de werkgroep intensief betrokken waren. BREIN zal gevoed gaan worden door het PLATFORM; het informatieplatform waarvan besloten is dat dit door Portbase ontwikkeld zal gaan worden. De realisatie van het PLATFORM zal voor een belangrijk deel gestoeld zijn op de requirements die hier voor liggen, in combinatie met de project start architectuur (PSA) zoals deze uitgewerkt wordt door de subwerkgroep Informatie Uitwisseling & Architectuur.


1 1

Dit FR document beschrijft tevens op hoofdlijnen de behoeften zoals geïdentificeerd door de subwerkgroepen Performance Meten en Call Optimalisatie (voorheen bundelen). Deze beschrijvingen dienen op punten nog nader uitgewerkt te worden maar zijn desondanks opgenomen zodat één functionele requirements document ontstaat ter start van de ontwikkelfase. Hieronder een korte samenvatting van de verschillende hoofdstukken in dit document.

Waarom, wat en hoe De hoofdstukken 2 t/m 4 van dit requirements document richten zich op het waarom, het wat en het hoe. Hoofdstuk 2 beschrijft de aanleiding en achtergrond van Nextlogic. Wat is de situatie in de containerbinnenvaartsector en welke ambitie leeft er, waarbij de complicaties besproken worden die een gezamenlijke verbeteraanpak noodzakelijk maken. Tevens worden kort de direct en indirect betrokken (en daarmee belanghebbende) partijen aangestipt en wordt inzicht gegeven in het containervolume waar we überhaupt over spreken. In Hoofdstuk 3 worden de functies en doelstellingen van BREIN uit de doeken gedaan. Planning via BREIN moet neutraal en integraal gaan lopen. Neutraal betekent dat alle deelnemende partijen gelijk behandeld worden, en integraal betekent dat er gekeken wordt naar de bargeafhandelingsprocessen in het gehele Rotterdamse haven industrie complex (HIC), dit in tegenstelling tot de huidige bilaterale afstemming tussen partijen. De Nextlogic stuurgroep heeft op 20 december 2012 besloten hierop een drietal uitzonderingen toe te staan; te weten: 1.

Het fixed window barges (FWB) product van APMT blijft toegestaan en wordt gefaciliteerd door en binnen Nextlogic.

2.

Het EGS (European Gateway Services) product van ECT zal buiten Nextlogic blijven.

3.

Prio-barges (waarbij commerciële afspraken tot prioriteitstelling in de bargeafhandeling leiden) gaan in principe niet meer voorkomen. Er zal geëvalueerd worden of dit niet tot problemen leidt. In dit laatste het geval zal Nextlogic ook prio-barges moeten faciliteren.

Het hoofdstuk vervolgt met een beschrijving wat verstaan wordt onder informatie eigenaarschap, tijdigheid en kwaliteit. Vervolgens beschrijft het de functie zoals BREIN deze zal gaan hebben; het toewijzen van timeslots voor calls van binnenvaart aan terminals en depots. In de toekomst zal BREIN mogelijk ook het faciliteren van call optimalisatie initiatieven gaan ondersteunen, maar deze functionaliteit zal niet in de eerste versie opgenomen zijn. Het hoofdstuk vervolgt met de beschrijving van de doelstellingsfunctie van BREIN – het raamwerk op basis waarvan BREIN haar optimalisaties zal gaan maken. Deze laat zich als volgt samenvatten: voor terminals & depots realiseert BREIN een optimale benutting van de beschikbaar gestelde capaciteit (in kaderuimte en beschikbare kranen). Voor de binnenvaart realiseert BREIN een minimale, maar realiseerbare, havenverblijftijd. Het bovenliggende doel voor de sector is het aantrekkelijker maken van de containerbinnenvaartpropositie. Afgesloten wordt met een overzicht van voorziene baten. Hoofdstuk 4 bespreekt het Nextlogic proces en haar toekomstige organisatie. Besproken wordt hoe het (toekomstige) Nextlogic proces, het BREIN en het PLATFORM te plaatsen zijn in de organisationele context van barge operators en terminal/depotoperators, hun mensen, staande organisatie en systemen. Vier cruciale veranderingen in de werkwijze worden er uitgelicht: 1.

BREIN is gedelegeerd verantwoordelijk voor de planning van de calls

2.

BREIN geeft de terminals en depots inzicht in verwachte capaciteitsbehoefte

3.

BREIN optimaliseert op basis van (eerder) beschikbare “rijkere” containerinformatie

4.

Nextlogic geeft inzicht in de performance van zowel de keten als van individuele partijen

Een overzicht van de informatiestromen van zowel de barge operators als de terminal-/depotoperators naar en van Nextlogic (PLATFORM en BREIN) is te zien in Figuur 1.1. In het kort komt het er op neer dat het PLATFORM alle informatie zal verzamelen en BREIN hiermee zal plannen. Management samenvatting Functioneel Requirements Document 0.91

2 2

De informatie die verzameld wordt valt te splitsen in inzicht in vraag & aanbod, het verzamelen van informatie over containers en vervolgens het bijhouden van (real-time) status informatie en events van zowel de binnenvaart als van de terminals & depots. Het Nextlogic proces zal alleen maar kunnen gaan werken als partijen ook daadwerkelijk deze informatie gaan leveren. De gedelegeerde verantwoordelijkheid en de rol van “menselijke planners” wordt nog nader besproken, om af te sluiten met een set high-level userstories. Een userstory beschrijft in enkele zinnen in een business verwoording de functionele wens zoals deze bestaat: wat wil je, hoe wil je dat, en waarom wil je dat. Userstories zullen in latere hoofdstukken gebruikt worden voor detail-beschrijvingen van functionele wensen van barge operators, terminal-/depotoperators en BREIN. Barge Operator(s)

Nextlogic

Terminal & Depot Operator(s)

verzamelen vraag & aanbod

calls

rotaties

beschikbare capaciteit

verzamelen container informatie

container info

los/laadlijst

container informatie

locatie updates barge (AIS/GPS)

status voortgang operaties

meldingen business events

meldingen business events

bijhouden real-time status

plannen operatie

ingeplande calls real-time inzicht

verschaffen inzicht periodieke rapportage

Figuur 1.1 - Nextlogic informatiestromen (gelijk Figuur 4.2)

Nieuw proces in detail De hoofdstukken 5,6 en 7 beschrijven de ontwerpuitgangspunten voor de te faciliteren processen voor barge operators, terminal-/depotoperators en het te realiseren BREIN optimalisatiesysteem. Hoofdstuk 5 bespreekt een set voorziene usecases voor barge operators binnen het Nextlogic proces en werkt deze uit. Usecases zijn een gebruikelijke techniek binnen de informatica om systemen te beschrijven vanuit het gebruikersperspectief. Het beschrijft de actor, de initiator van de interactie en het systeem zelf als een opeenvolging van eenvoudige stappen. Met andere woorden, de usecase beschrijft "wie" met het betreffende systeem "wat" kan doen, en splitst dat op. Usecases zijn daarmee meer schematisch van aard en specifieker gestructureerd als toekomstige systeem-bouwblokken dan dat userstories dat zijn. De twee modelleringstechnieken vullen elkaar goed aan. Barge operators zullen met Nextlogic een aantal zaken anders moeten gaan doen. In plaats van bilateraal (1-op-1) afgestemde calls met terminals en depots gaan rotatieverzoeken en (in geval van vletwerk) sets calls aangekondigd worden inclusief bijbehorende instructies. BREIN gebruikt deze input, rekening houdend met restricties en prioriteitstelling, om een rotatie samen te stellen en calls te schedulen bij terminals en/of depots. Daarnaast wordt in een vroegtijdig stadium informatie over te vervoeren containers gedeeld als ook voortgangsinformatie over de bewegingen van het binnenvaartschip. In het hoofdstuk worden naast deze uitgewerkte usecases ook een aantal “andere aspecten” besproken. Deze zijn: de karakteristieken van de verschillende containerbinnenvaart sectoren, zelfvarende (duw)bakken, slowsteaming, de inzet van twee kranen voor het afhandelen van een call, de wens om productieschema's op te kunnen nemen, invulling van het prio-barge principe, en de omgang met structurele en incidentele rusttijden. Daarnaast worden een tweetal platform gerelateerde aspecten besproken: het beheer van referentie data en de behoefte qua te ontsluiten informatie voor barge operators vanuit het PLATFORM.


3 3

Afgesloten wordt met een korte tekst ter introductie op de userstories voor de barge operator welke in Bijlage A te vinden zijn. Het volgende hoofdstuk (6) schetst het terminal en depot perspectief aan de hand van de voorziene usecases binnen het Nextlogic proces. Ook voor terminal-/depotoperators zal de invoering van Nextlogic procesveranderingen met zich meebrengen. In plaats van bilateraal afgestemde calls met barge operators gaan terminals en depots de voor bargeafhandeling beschikbare capaciteit met BREIN delen. BREIN geeft daarbij de terminals en depots inzicht in verwachte capaciteitsbehoefte. BREIN gebruikt de beschikbare capaciteit om voor barges rotaties samen te stellen en calls te schedulen. Daarnaast gaan ook terminals en depots eerder informatie over import en export containers delen (onder andere met betrekking tot stackposities) en zal voortgangsinformatie over de voortgang van operaties gedeeld worden. Het hoofdstuk bespreekt daarnaast een aantal andere aspecten, waaronder: • De informatie vergaring vanuit het platform • Der verantwoordelijkheid referentie data up-to-date te houden • De inzet van overloopcapaciteit terminals • Het zogenaamde hoppen • Het niet meer opschonen van los/laadlijsten • De inpassing van het Fixed Windows (FW) product • Regels rond de openingstijden depots Afsluitend worden de userstories voor de terminal-/depotoperator geïntroduceerd welke in Bijlage B te vinden zijn. BREIN zal het optimalisatietool zijn dat het nieuwe Nextlogic proces mogelijk gaat maken. Hoofdstuk 7 detailleert een viertal usecases voor BREIN in haar planningsrol binnen het Nextlogic proces. Daarnaast worden diverse ontwerpuitgangspunten voor BREIN uitgelicht en besproken. Meer specifiek: de eisen zoals ze er liggen qua iteratieve planning en bijsturing, het blackbox karakter van het systeem, het respecteren van tijdsafhankelijkheden en het efficiënt plannen van kademeters en kranen. Daarna wordt een belangrijk regelmechanisme besproken om onderscheid tussen rotaties te kunnen maken: het zogenaamde slackopslag percentage. Het slackopslag mechanisme wijst slack toe aan rotaties op basis van een mechanisme waarbij rotaties welke complexer of meer restrictief zijn relatief meer slack krijgen toegekend. Het hoofdstuk vervolgd met een drietal secties rond prestatie meting en verrekening, waarbij is besloten om een door een accountant vast te stellen kostenverdeling te hanteren in planbeslissingen van BREIN. BREIN gebruikt deze verdeling in afwegingen en prioritering. Afgesloten wordt met de behoefte aan simulatiefaciliteiten en ook in dit hoofdstuk een korte tekst ter introductie op de userstories zoals deze voor BREIN opgesteld zijn (zie Bijlage C).

Te realiseren ondersteunende systemen Met de realisatie van alleen het BREIN zijn we er niet. BREIN kan alleen functioneren als ook het PLATFORM op een juiste wijze wordt ingericht zodat de juiste informatie op het juiste moment tussen partijen gedeeld kan worden. Een andere essentiële component is een juist functionerende KPI (key performance indicators) / BI (business intelligence) omgeving waarmee voorgedefinieerde KPI’s gemeten kunnen worden voor zowel de gehele keten als voor individuele actoren en tevens ad-hoc analyses gedaan kunnen worden op het juist functioneren van het nieuwe proces. Dit wordt in respectievelijk Hoofdstuk 8 en 9 besproken. Hoofdstuk 8 beschrijft het PLATFORM: het informatieuitwisselplatform dat het nieuwe Nextlogic proces mogelijk gaat maken. Een serie ontwerpuitgangspunteisen voor het PLATFORM wordt besproken. De architectuur wordt kort geschetst, het belang van een nieuw onafhankelijk platform naast het aanwezige Portbase PCS (het port community system) wordt besproken, en gekeken wordt naar de technische invulling middels een drietal operationele datastores en een datastore met Management samenvatting Functioneel Requirements Document 0.91

4 4

referentiedata. We spreken hier expliciet over datastores en niet over databases omdat een database een implementatie keuze impliceert; deze is echter nog nader te maken. De operationale datastores betreffen: • CALL • TDO_CAPACITEIT • CONTAINER Alle betrokken partijen zullen aan het PLATFORM koppelen om deze datastores van informatie te voorzien – zowel verwachte informatie als ook real-time status updates – en om er informatie op te halen. Het hoofdstuk bespreekt vervolgens verschillende gebruikseisen, zoals daar zijn: de nadrukkelijke wens het PLATFORM nieuw te ontwerpen en niet slechts als een extensie bovenop het huidige BargePlanning 3.0 product, ondersteuning bieden voor nietdeelnemen scenario's (wordt nader uitgewerkt in Hoofdstuk 11), en het immer bieden van up-to-date inzicht, de manieren van koppelen die daarbij horen, het herbruik principe van bestaande functionaliteit en de generieke apps zoals Nextlogic die wil gaat bieden. Afsluitend worden twee additionele functionaliteiten voor het PLATFORM expliciet besproken: informatie validatie en performancemeting en -rapportage. Deze laatste functionaliteit is een opmaat naar Hoofdstuk 9, waarin kort het belang van performance measurement uitgewerkt wordt, de tooling welke daarvoor nodig is en de manier waarop Nextlogic dit gerealiseerd wil zien. Belangrijke uitgangspunten zijn dat alle mutaties op de invoerdata gelogd zullen worden en dat een prestatiemeter in plaats van een schandpaal gehanteerd zal worden. Performance measurement van vooraf gedefinieerde KPI’s zal zowel achteraf (ex-post) als tijdens het proces (ex-ante) ingezet worden. Daarnaast dient de omgeving geschikt te zijn voor ad-hoc analyses door een Nextlogic analist.

Het ontwikkeltraject De laatste vier hoofdstukken (10,11,12 en 13) geven “extra materiaal” ter invulling van het toekomstige ontwikkeltraject. Hoofdstuk 10 geeft een overzicht van (uitzonderings-) scenario’s welke voorzien zijn en waarop BREIN en PLATFORM voorbereid dienen te worden: de zogenaamde unhappy flows. Deze lijst zal als startpunt dienen in de ontwikkeling. De lijst is echter nog niet compleet en aanvulling is benodigd. De scenario’s zijn verdeeld in: weersomstandigheden, technisch falen, externe factoren, afhandeltijd op terminal/depot en significante wijzigingen in vraag & aanbod binnen laatste uren Nextlogic planning. Het hoofdstuk over niet-deelnemers (Hoofdstuk 11) beschrijft twee scenario’s voor niet-deelname binnen Nextlogic; waarbij ofwel de barge operator ofwel de terminal-/depotoperator niet-Nextlogic deelnemer is. Belangrijk uitgangspunt is dat Nextlogic deelnemers zo min mogelijk hinder zullen hebben van niet-deelnemers en niet twee losse processen vorm hebben te geven. Voor barge operators die te maken hebben met niet-deelnemende terminals of depots zullen door BREIN geadviseerd worden over af te spreken timeslots bij de niet deelnemende terminal-/depotoperators. Hoofdstuk 12 bespreekt de verschillende aspecten waarmee rekening te houden in het te starten ontwikkeltraject van BREIN en PLATFORM. Een definitie van zowel schaduwdraaien als de grootschalige praktijkproef worden gegeven, de tijdslijn voor ontwikkeling wordt geschetst en de uitgangspunten qua omgang met leveranciers en de (belangrijke) gezamenlijke ontwikkeling van het PLATFORM. Voorts wordt ingegaan hoe de Nextlogic projectorganisatie voornemens is om te gaan met testen, communicatie, opleiding, documentatie en het betrekken van keyusers vanuit de marktpartijen. Ten slotte worden systeem acceptatie criteria benoemd. Het laatste hoofdstuk (Hoofdstuk 13) schetst een longlist van mogelijke toekomstige functionaliteit voor Nextlogic’s BREIN en PLATFORM. Hier wordt nog geen uitspraak gedaan over termijn waarop deze specifieke functionaliteiten ontwikkeld


5 5

dienen te worden, anders dan dat dit staat te gebeuren na in productie name van de systemen na een succesvol verlopen grootschalige praktijkproef.

Bijlagen Het FR bevat voorts een serie bijlagen. De eerste drie bijlagen detailleren de userstories voor de barge operators (Bijlage A), de terminals & depots (Bijlage B), en het te realiseren BREIN (Bijlage C). In Bijlage D is een sequence diagram opgenomen dat de toekomstige berichtenstroom visualiseert, in Bijlage E staat een aantal cases voor optimalisatie zoals aan de potentiële leveranciers is voorgelegd in de BREIN leveranciersselectie, en Bijlage F geeft een voorzet qua benodigde berichten voor de informatie-uitwisseling. Bijlage G geeft een beknopte beschrijving van de havenzijdige bundel initiatieven (Hup & Hop) zoals deze worden uitgewerkt door de subwerkgroep call optimalisatie. Bijlage H ten slotte bevat een drietal tabellen die inzicht geven in gebruikte referenties, afkortingen en definities.


6 6

Management samenvatting

Recommend Documents