Professional article
Shell Joint Venture IT Framework E. Ruijs
Journal of Chain-computerisation Information Exchange for Chain Co-operation 2013 – Volume 4, Art. #7
Received: 1 March 2013 Accepted: 1 June 2013 Published: 26 June 2013 2013 – Volume 4, Art. #7 URN:NBN:NL:UI:10-1-114605 ISSN: 1879-9523 URL: http://jcc.library.uu.nl/ Publisher: Igitur publishing, in co-operation with the Department of Information and Computing Sciences, Utrecht University Copyright: this work is licensed under a Creative Commons Attribution 3.0 Licence
2
Shell Joint Venture IT Framework Evert Ruijs Shell Upstream International (SIEP bv) Carel van Bylandtlaan 23, 2596 HR Den Haag, The Netherlands E-mail:
[email protected] Opmerking vooraf: Dit artikel is een beschrijving van het IT-framework dat Shell wereldwijd gebruikt en bevat daarom veel Engelse termen. Samenvatting: Shell’s wereldwijde productie van olie en gas gaat voor een groot deel via Joint Ventures. Deze Joint Ventures werken in meer of mindere mate onder het management van Shell, vaak optioneel gebruik makend van Shell’s processen, standaarden, gemeenschappelijke portfolio van applicaties en technologie. Om de vele soorten van applicaties en versies van implementaties beheersbaar te houden in de ‘extended enterprise’ is een goed raamwerk nodig. Dit ‘Joint Venture framework’ maakt gebruik van vele aspecten van enterprise architectuur om de verschillende services te kunnen ordenen en verheldering te bieden aan de ‘klant’; de Joint Venture. Trefwoorden: Enterprise Architectuur, extended enterprise, Joint Ventures, Service Delivery
Abstract: Shell’s global operation of exploration and production of oil and gas is executed for a great deal via Joint Ventures (JVs), which can be seen as part of the ‘extended enterprise’. Many JVs are under management of Shell (Shell as operator), and have the option to use Shell processes, standards and a common portfolio of application and technology. A Joint Venture Framework is being developed to keep the many different implementations of the portfolio manageable, moving from organic grown to an organized way of providing services to the ventures, with the right contracts, controls, cost recovery and value proposition in place. Enterprise Architecture techniques were used to help finding the structure for the framework. Keywords: Enterprise Architecture, extended enterprise, Joint Ventures, Service Delivery
1 Achtergrond: Shell business model Het business model van Shell ‘Upstream’ bestaat voor een groot deel uit het creëren en opereren van ‘extended enterprises’; organisaties die deel uitmaken van de waardeketen van Shell, maar die in meer of mindere mate onafhankelijk zijn. Hierbij staat centraal dat via een overeenkomst met een overheid (en andere joint venture partners) een lokaal bedrijf wordt opgezet, dat zorg draagt voor het vinden van olie en gas, het produceren ervan tot en met het geschikt maken van gas voor export (zoals in de vorm van LNG). Vaak zijn dit op zichzelf al grote bedrijven met soms wel duizenden werknemers. Deze bedrijven zijn in te delen in een aantal archetypen, die op een glijdende schaal zitten van totaal geïntegreerd in Shell (zoals de NAM in Nederland) via bedrijven die volledig ‘self operated’ zijn, maar waar Shell veel van de services levert (zoals Brunei Shell, of Petroleum Development Oman) tot bedrijven waar we
3
slechts aandeelhouder zijn (waar deze bedrijven zelfs concurrenten van ons kunnen zijn, zoals Woodside Petroleum in Australie), maar die wel eventueel kunnen profiteren van bijvoorbeeld goede licentievoorwaarden.
2
IT-Services aan Joint Ventures
In veel van de lokale bedrijven (die we operating units noemen) is er sprake van het volgen van Shell processen en standaarden, wordt Shell technologie gebruikt en worden daarom ook Shell IT services geleverd. Hierbij speelt Shell een unieke rol in de olie- en gaswereld, omdat bijna alle internationale oliebedrijven dit niet op deze schaal doen. Shell ziet het echter als een competitief voordeel om dit te kunnen, maar daarbij moet opgemerkt worden dat dit ook door de operating unit zo gezien moet worden; uiteindelijk moet de IT-service die geleverd wordt waarde toevoegen en niet gezien worden als een manier om extra geld te verdienen. In de afgelopen decennia zijn de IT-services die Shell levert aan operating units (van infrastructuur, applicaties en support tot en met het uitvoeren van data management processen) organisch gegroeid, met daarbij een zeer uiteenlopende implementatie van de verschillende ‘vintages’ van de Enterprise Architectuur van Shell. Daarnaast moet bij het leveren van IT-services meestal binnen allerlei lokale beperkingen worden geopereerd (bijvoorbeeld: Moeten de IT-services lokaal in het land geleverd worden? Mag bepaalde technologie naar het land geëxporteerd worden? Kan bepaald intellectueel eigendom gedeeld worden?). Dit heeft door de jaren heen geleid tot een te grote complexiteit (te veel versies, te veel integratie uitdagingen) en ook is er een groeiende mismatch tussen de realiteit en de transparantie die nodig is om een groot complex bedrijf efficiënt te opereren. Vooral het laatste heeft geleid tot veel discussie met de operating units over bijvoorbeeld de kosten die in rekening gebracht worden voor de services die geleverd worden.
3 Elementen van het Joint Venture IT-Framework Om dit probleem op te lossen (a. de organisch gegroeide structuur, b. de complexiteit en c. de cost recovery issues door een gebrek aan transparantie) is er besloten om een Joint Venture IT-Framework te ontwikkelen. Dit raamwerk bestaat uit: 1. Een catalogus van services die gebaseerd zijn op bouwstenen, afgeleid uit Shell’s enterprise architectuur (de focus van het artikel is op dit onderdeel) 2. Een proces met rollen en verantwoordelijkheden (hoe maak je de overeenkomst met de venture en wie speelt daarbij een rol?) 3. Een cost recovery model (hoe krijgen we betaald voor de services die we leveren? En hoe zorgen we ervoor dat onze centrale investeringen ook worden gedekt?) 4. En templates voor risico management en contracten
4
CO M PO N EN TS O F JV IT FRAM EW O RK PRODUCT AN D SERVICE OFFERIN GS
PROCESS, ROLES AN D PEOPLE
FIN AN CIAL M GM T AN D M GM T IN FO
CON TRACT & RISK M AN AGEM EN T
Centraal staat de catalogus, waarbij het denken in termen van enterprise architectuur geholpen heeft bij het vinden van het juiste abstractieniveau voor de bouwstenen. Idealiter is namelijk een catalogus simpel, en dient het te werken als Lego® blokjes die gestapeld kunnen worden, om daarmee het juiste businessmodel te bouwen, met de juiste ‘enablers’ en infrastructuur als fundament. In de catalogus onderscheiden we daarom drie soorten bundels: • Business services; dit zijn bundels van onderling afhankelijke applicaties, met de bijbehorende business processen en datastandaarden. Het idee hiervan is: als een bedrijf een bepaald business proces uitvoert volgens de Shell standaarden, dan heeft het deze bouwsteen nodig om het proces naar behoren uit te voeren. In de architectuur termen dekt dit de verschillende elementen van de business en de informatie architectuur; • Enabling IT-services; dit is geconfigureerde infrastructuur die nodig is voor een specifiek business proces (zoals ‘field telecoms’ voor productie van olie en gas in het veld, of ‘high performance computing’ voor processing van seismische data en het modellering van reservoirs); • En de Kern Infrastructuur; dit zijn ‘commodity’ services zoals netwerk, hosting en PC’s Samen met de Enabling IT-services vormt de Kern Infrastructuur de technische architectuur.
4 Het Resultaat De invoering van het raamwerk leidt tot verschillende (vooral) positieve effecten: • Een meer strategische discussie: In plaats van een discussie over honderden, misschien wel duizenden applicaties (in vele verschillende versies) verplaatst deze zich naar 1) welke business processen heeft mijn organisatie nodig, 2) wat is het Shell portfolio dat hierbij hoort (en bijbehorende ‘value proposition’), en 3) wat is dan de benodigde infrastructuur en ‘delivery model’. Het resultaat is een grotere eenvoud in het bouwen van het IT-plan en een sterkere positie voor IT in deze discussie, omdat deze zich verplaatst van vraag in de vorm van kleine incrementele stapjes (‘u vraagt, wij draaien’), naar een strategische discussie over wat de business wil bereiken, wat de standaard is die de business daarvoor nodig heeft (proces + data + leveringsmodel) en wat daarbij vanuit Shell voor IT-levering nodig is. Hierbij kan dan ook precies aangegeven worden wat niet mogelijk is (bijvoorbeeld: sommige services kunnen alleen vanuit een global datacenter geleverd worden, of de meeste services mogen niet verder aangepast worden aan specifieke lokale vraag).
5
1. Set strategic direction
•
•
2. Assess required IT enabling
3. Define delivery model
4. Assess risks and define controls
5. Define offer & agree
6. Implementation and monitoring set up
Een meer business gedreven architectuur: Het denken in ‘service bundles’ is ook voor architecten prettig, want het levert een taxonomie op voor de business elementen die beschreven moeten worden (inclusief met welke architectuur regels rekening gehouden moet worden, per bundel). De architectuur wordt hiermee een stuk minder abstract voor de business, want de architect praat over dezelfde bouwstenen als de mensen aan de andere kant van de business interface. Een andere discussie over kosten: De verschillende operating units waar nu het concept getest wordt krijgen bij sommige bundels het idee dat Shell te veel applicaties per bundel aanlevert (‘dit hebben we niet allemaal nodig!’, lees: ‘hiervoor willen we niet betalen’). Het vinden van de juiste balans in deze discussie is nog een voortdurend proces en zal door ervaring gedurende de implementatie van het JV framework uiteindelijk uitkristalliseren. Wat echter helpt is dat dit wel de juiste discussie op gang brengt: Hebben we al deze applicaties in deze bundel nodig? Of kunnen we met minder toe? Zo heeft uiteindelijk het goed kiezen van de juiste applicaties (etc) per bundel ook een effect op de kosten beheersing van de gehele architectuur.
Afrondend, de observatie is dat het een behoorlijke strategische stap is om te denken in termen van architectuur bouwstenen (in de vorm van ‘service bundles’, in plaats van individuele applicaties). Veranderingen zijn er zowel aan de aanbodkant van IT (bijvoorbeeld: Hoe richt je je services in? Hoe doe je portfolio management? Hoe stuur je uiteindelijk de rekening voor de service die je levert?), als aan de vraagkant (bijvoorbeeld: Hoe klantvriendelijk zijn we? M.a.w. in hoeveel smaken kunnen we de bundel leveren?). Dit is een traject van cultuurverandering die jaren duurt om het volledig in te voeren. We denken echter een belangrijke strategische stap gemaakt te hebben door een nauw verband te leggen tussen architectuur en service delivery en zien daarmee een meer beheersbaar model voor het managen van IT in een extended enterprise ontstaan.
Biografie: Evert Ruijs (1967) is IT strategie, planning en architectuur manager van Shell Upstream International. Hij is zijn carrière begonnen als geoloog, maar heeft al snel de overstap gemaakt naar data management, data warehousing en uiteindelijk enterprise architectuur. Sinds 1996 werkt hij voor Shell en heeft onder andere in Assen, Londen, Muscat (Oman) en Den Haag gewerkt.
6
