Time-Based Cost Allocation in the Oil and Gas Industry

Oil and gas prospecting involves the deployment of highly experienced and expensive engineers in remote and uncomfortable places. They’re typically working on a number of potential oil or gas fields at the same time. Or rather, each may spend some hours or days on one field, and then some hours or days on another, doing seismography or other forms of wizardry.

Often such oil and gas fields are explored by joint ventures, each of which may be owned in different proportions by a number of different investors. It is essential therefore that costs should be distributed fairly across each of them. This ‘fair allocation’ of employee-related costs is usually based on the time that each engineer reports against each field.

SunSystems is an excellent financial system for oil and gas companies. It has the flexibility to deal with both local statutory reporting (which may be based on a statutory chart of accounts and will certainly involve many different kinds of tax report in local currency), and with corporate reporting (which may be based on a corporate chart of accounts, may require corporate accounting policy adjustments, and may involve translation into a foreign currency). SunSystems also contains a module for the automatic redistribution of costs against nominated entities (these may, for example, be departments, or projects, or, for that matter, oil and gas fields).

But SunSystems doesn’t include a timesheet module.

systems@work’s time@work fills this gap with a browser-based timesheet module that can be accessed by users whether they’re in the office or at large, using their PCs, Macs or mobiles.

Engineers record time against individual projects, in this case projects related to oil and gas fields, and at the end of each month or accounting period, time data are exported from time@work into a SunSystems Memo account (where the Project code in time@work is represented by a transaction analysis code in SunSystems). SunSystems Corporate Allocations module can then be used to pick up all the costs related to each engineer and to allocate them across projects in proportion to the time spent on each, based on values in the Memo account.

systems@work’s time@work is used by many international petrochemical companies:

OMV
Lekoil
Afren
Addax Petroleum
E.ON
Enquest
JKX
KBC
Lundin
Oryx
West African Ventures
Seplat Petroleum
Gazprom
Dana Petroleum

time@work can also be used for the capture of employee expenses, with authorised expenses being automatically transferred to SunSystems, where reimbursement can be initiated. Expenses can also be imported from electronic credit card statements.

It can also be used for scheduling and planning the allocation of staff to projects.

It’s relatively easy to implement, since it’s configurable software rather than software modifiable at source code level. It’s simple on the surface and therefore easy to learn and use, and yet flexible and powerful as an analytical tool.

Contact me if you are interested.

On Systems Integration – How to reduce the risk?

A couple of days ago I wrote about the challenges of systems integration, and the advantages and disadvantages of Best-of-Breed and Fully Integrated Solutions.

See Systems Integration.

If you’ve chosen the Best of Breed approach, how can you reduce the risks of integration, and design systems that enable integration that’s as ‘seamless’ as it can be?

The first way is to keep things simple. Don’t integrate the impossible. In my experience of business systems, which is largely with financial, manufacturing, expense management and professional services management systems, integration usually involves a ‘front-office’ system that reflects the special needs of an organisation, and a financial system.

I’ve come across two main reasons why organisations choose to do this:

Some ‘front-office’ systems, such as our systems@work software, don’t include accounting modules. This is deliberate, in that they aim to work with any system.
Some ‘fully-integrated’ systems don’t possess powerful enough accounting modules to meet organisations’ corporate, management or statutory reporting needs in every country in which they operate.

In many instances I’ve found myself working on the integration of, for example, hotel management systems, or time@work (our timesheet, expense, planning and billing system for professional services organisations) with back-office accounting systems.

The synchronisation of ‘reference data’, those core data items such as ’employees’, ‘products’, ‘projects’, ‘departments’, even ‘accounts’, is usually handled manually, though on occasion automatically too (if automation is cost effective) with ‘slave’ and ‘master’ well defined.

When it comes to transactional data it is usually the ‘front-office’ system that is passing data to the ‘back-office’, and rarely vice versa, the back-office accounting system being essentially more ‘passive’. Even if this transfer is done periodically rather than daily, it is not so difficult to ensure reconciliation.

In all of these cases integration is relatively easy. Data flow from ‘front’ to ‘back’. But the integration of manufacturing systems with accounting systems is much more difficult, and although I have done this too, there are areas, such as ‘costing’ (the determination of the ‘actual’ cost of a product) where the task becomes much more complex. Costs of raw materials, components and semi-finished items, often based on accruals, may already have been transmitted to the accounting system, and will usually need subsequent revision as further costing details are obtained. Techniques such as standard costing can alleviate problems of this kind, and data may still flow generally in one direction, from the manufacturing to the financial system, but the number of transactions and the reasons for passing data are many more.

Where, first, to record transactions?

More complex questions also arise when you must decide where to record various types of transaction. In which system, for example, should supplier invoices be booked? Most organisations prefer to record similar transactions in just one place in order to avoid mistakes and to simplify procedures for the finance department. But the data derived from supplier invoices may be needed by both systems.

In the professional services world, supplier invoices are often recharged to customers, so supplier invoice data are needed in the professional services modules. If they are first booked there, then the question arises as to whether it make sense to book, say, utility invoices there also, rather than directly into the financial system’s accounts payable module?

In the manufacturing world, supplier invoices contribute to the cost of products, so must find their way either by direct initial input or through integration into the manufacturing system’s database.

The choice of where to enter data is further clouded by the fact that many ‘front-office’ systems are less well adapted to meet the burdens of statutory reporting, such as VAT reporting, and do not capture the information required for this purpose.

Transaction History

You must also make sure that modifications of data are achieved through additional transactions rather than through change to existing ones (the original values thereby being lost). You always need to know the before and after status of data. This is commonplace in most transaction systems, such as accounting systems, where posted journals are not usually modifiable. Corrections and any other kind of value changes are achieved through new journals. This is important because you must always know exactly which transactions have been transferred during integration, and once passed to another system, a transaction must not change.

Marking as Passed

It is also essential that there be some way of determining whether integration processes have been executed in respect of particular data. If you’re exporting transactions from one database to another you need either to be able to mark a transaction as exported or to store details of exported transactions in a separate table. And, of course, assuming that you have taken note of the second rule of integration, and as noted earlier, a transaction that has been exported should never change its value.

Date and Time Stamp

Make sure that all transaction data are ‘date and time stamped’. This isn’t essential, even if it is wise, in a ‘fully integrated’ system because processes are executed fully and at once and any processes that depend on the evaluation of data at the time of processing will of necessity evaluate that data correctly. But if a process is split between systems and cannot therefore be completed fully and at once any data evaluation may be influenced by later transactions and processes. Separated processes therefore need some other way of determining how to evaluate data ‘as of’ a particular date and time.

In a final post we will look at how software systems should be developed with integration in mind.

The Necessity of Agility

I’m a nuisance when it comes to system design because I can’t get things right first time. I feel guilty, of course, because asking that things should be done again, or done differently, costs us time and money, and I really ought to be able to get it right at the start, if only I thought about it more carefully.

But, better that I should raise issues now rather than later when it’s too late.

Last Friday I was reviewing the new browser-capable version of invoicing that we’re developing for Version 4.9 of time@work, due out in September (or so). Our invoicing module is complex (I should say ‘sophisticated’ really – it’s the right salesman’s euphemism) since our system is multi-company, and invoicing allows recalculation, discounting, exclusion, addition, rounding and all sorts of other features. Producing a .Net browser version has taken months, but we’re nearly done.

It all began some months ago when I sat down with our systems analyst and looked at the mock-up he’d produced. This followed some hours of discussion over the previous days. The mock-up allowed us to click through the invoicing process, from one dummy screen to another, ‘trying out’ how invoicing might look. Our invoicing process can involve about six different pages, and we’d thought very carefully about what fields should be where, and how to reduce the end-user’s clicks and make the whole process as intuitive as possible..

But, despite that, a mock-up isn’t real, so, to our developers’ dismay, when I looked at the system on Friday, with real data and real programming logic behind the screens, it didn’t seem so easy to use as we’d thought it might be, and it was obvious to me that we’d made a few mistakes.

Years ago, when I worked for Coopers & Lybrand Consulting Services in Budapest I went on a ‘Summit D’ course which was all about systems analysis, specification and development. I was taught the typical ‘cascade’ method. Each phase must be completed before the next phase is begun. Once systems analysis is complete, a requirements document must be produced that the end-users will sign off as correct, then a system specification, and then you build the actual system. Not much room for revision. When the system is complete, it’s take it or leave it, and ‘this is what you signed off on!‘

But we’re human and our imagination is limited. We need to touch and feel things before we know they are right. So, nowadays, I much prefer the ‘agile’ method of system development or system implementation. You engage in repeated demonstrations and mock-ups and at every stage you allow for revision and successive approximation to what is really needed. The end-user sees what he’s getting long before the system comes out of the laboratory. Of course he’s never HAPPY but he’s less UNHAPPY this way!

True, without careful control this can be an expensive method, but it’s certainly cheaper than delivering a big, expensive, system to users who find it totally unusable.

So, though I feel guilty from time to time at contradicting myself and asking for change, I know that it’s inevitable, and it’s the best way I know. So, forgive me, designers and programmers. And, after all, it’s not as if you don’t occasionally make a few tiny mistakes yourselves.

Here’s a happy user:

Professional Services Organisations borrow staff from one team to use on another’s project. How should that be managed?

Efficient deployment of professional staff in a diverse PSO often means one company, business stream, department, or team borrowing from another if utilisation is to be kept high, and if clients are to be satisfied. Each team will inevitably staff a project from its own resources by preference, but if skills are in short supply, they must look elsewhere. This is one reason why visibility of availability, skills and experience across the entire organisation is important.

Conversely, a team with time on its hands will want to promote its professional staff and ‘sell’ them to others.

However, these issues create challenges in terms of revenue sharing, costing, and motivation. These need analysis.

A perennial issue in the management of PSOs is that of responsibility. There is the ‘line management’ responsibility of team leaders which includes:

Responsibility for the day-to-day deployment of a team of professional staff
Responsibility for the personal career development of the team
Responsibility for the profitability of the team

And there is ‘project’ responsibility:

Responsibility for the staffing of a project
Responsibility for the profitability of a project
Responsibility for all commercial decisions (invoicing, etc.) associated with a project

In most organisations, these responsibilities overlap, but they can also be in conflict unless there are clear rules for the resolution of issues with respect to inter-team charging. As PSOs become more commercially driven and team leaders and managers are rewarded according to the profitability of their team these conflicts can become serious.

Let’s look at an example:

Let’s suppose there are two teams, led by A and B. Each team leader employs a number of staff as follows:

A employs AA, AB and AC
B employs BA, BB and BC

In a simple world, each team executes and invoices projects using its own staff. Budgeting and forecasting are relatively simple, and there are no cross charges.

But what if B sells a project that requires the skills of AC?

In this case, he or she must borrow AC from A.

But how is this to work in terms of gross margin (on which the bonuses of A and B may partially depend)?

Should some of the revenue that belongs to B be passed back to A?
Alternatively, should some of the cost that belongs to A be passed on to B?

There are no entirely right answers here, but my own preference is for the second option, for several reasons:

In a commercial organisation it is the obtaining of revenue (or rather gross margin) that should be rewarded most clearly
In a commercial organisation it is the incurring of loss that should be penalised most clearly
People should not generally be rewarded or penalised for circumstances that lie outside their control

Let’s consider what would happen if our cross charging rule were that A should receive 85% of the revenue earned in respect of AC’s work on the project.

When B comes to A to tell him about the project, which hasn’t yet started, he’s optimistic:

‘You’re going to get good money for AC. I’ve negotiated a rate that’s higher than the usual. So you’ll probably end up getting more than you would if you’d sold him yourself. Sadly, I’ll only see a small part of that revenue myself, but, sadly, those are the rules.’

Of course, as in all cautionary tales, things don’t work out well. What B didn’t really tell A was that this is a fixed price project, and B has made some dodgy assumptions about the number of days the project will require. When it comes down to it, the revenue is spread more thinly than planned across the days that AC has given. When A receives his share of the revenue, it doesn’t even cover AC’s standard project cost.

‘I could have sold AC on some other projects and made more money,’ he complains.

However, this is just one of the problems. When A complains to B that he was expecting more revenue, he points out that the project has gone wrong through poor project management, and poor estimating. Why should he be penalised for that, since it was B’s team who were responsible?

B has to admit that some of this may be true, but he counters with a complaint that AC wasn’t actually as experienced and suitable as A had suggested, and so some of the problems were AC’s fault, not his team’s.

And so on.

Not all of these problems are resolved by looking at it another way, but some are. If A charged a fixed price for AC’s work, regardless of the revenue associated with the project, then at least the first kind of problem is averted. But what should that price be?

Full fee rate (B’s notional or actual fee rate for his project) would seem too high, since it would remove any incentive for B.On the other hand, standard project cost would seem too low (let’s suppose that AC has a standard project cost of 450), since it doesn’t provide much of an incentive for A, and provides him with no reward for the ‘risk’ of employing staff (and incurring overheads to do so).

In fact, assuming that appropriately skilled staff can generally be found in one team or another, a clever team leader wouldn’t bother to employ anyone at all. He would simply buy the time of his colleagues at standard project cost.

Of course, there are reasons why this would be a foolish policy. If you ‘own’ your own staff you may make your own decisions about how to deploy them, how to reward them, and you have a much greater chance of running successful projects if you have at least some influence over, and have earned the loyalty of the staff you deploy.Risk must bring rewards, and so the risk of running a team must be reflected in a margin to be charged to other teams when they need to borrow your staff. You should be rewarded for having recruited them, trained them and obtained their loyalty and for the risk that you face that they may be idle and unprofitable.

In the next post, I’ll address the question that arises from this: how should cross charges be calculated?

Fragile and Vulnerable, but Marvellous When it Works

If there’s something worrying me when I go to bed, I dream that I’ve got to play an oboe concerto. The score is missing, or I haven’t a good reed, or the piece is far too difficult. I wake up relieved, and only a tiny bit regretful that I am not a professional musician. Such were my dreams on Monday night.

But the task on Tuesday morning was nevertheless a performance. I must wake at 3.30 am to present time@work, our timesheet software, to a roomful of lawyers in Singapore. I am in Sofia, six hours behind them.

I’ve sent out the Webex invitation earlier. Webex is a software tool that enables you to share your screen with people all over the world. My partners in business, Ramesh and Charles from Kuala Lumpur, are in the room in Singapore and they’ll project my PC via their PC and a projector, onto a screen. We’ll talk through Skype, and they’ll pass an iPad around the room so that people can ask me questions. I will never know what they look like, or if they are smiling or frowning, or even listening.

This is fabulous technology. Cheaper than flying to Singapore and back.

So, I ‘m awake at 3.30 in a hotel in Sofia. Quick shower, and then down to the lobby, where I’m told the WiFi network is more reliable. It’s dark, but the receptionist is standing behind reception (he has no chair, poor man, so I suppose sleeps at his post like a horse, standing up). He works 8 am to 8 pm, he tells me, two days on, two days off. He is nevertheless cheerful.

Yes, he can make me a cup of tea. This is marvellous news. Without tea, I am useless.

The security guard is sleeping on the sofa in the Lobby Bar, so I move to another dark corner from where Singapore won’t hear Balkan snoring and where my declamatory tones won’t wake the guard.

Power plugged in. Earphones on. I open my Inbox l to discover an email from late last night that says the potential client has changed the agenda and wants to see a few more things that I haven’t yet prepared. Alarming, but manageable.

35 minutes to go, so I do some quick changes to the system, amend my PowerPoint presentation (don’t worry, I only do five slides), and make sure the system is still working.

10 minutes to go, and I suddenly realise that I’m not connected to the internet. The icon says I’m connected but I’m actually not. I can’t start the Webex meeting so something must be wrong. I do the usual troubleshooting to no avail.

9 minutes to go. I force a restart on the PC. But that doesn’t help.

7 minutes to go. There’s no one at reception now, so I decide to try to connect from my room, where clearly, at some point in the night, the connection was working.

5 minutes to go. In my room it doesn’t work either.

3 minutes to go. Back in reception. The cheerful receptionist looks dubious, but agrees to restart the router.

2 minutes to go and finally it’s all working.

Ramesh has been Skyping frantically, ‘Where are you?’ thinking, perhaps, that I have overslept.

Now I am calm. ‘I am Mrs de Winter now,’ I say to myself quietly.

And then I’m on air.

‘Good morning, Singapore!’

Of course, I lost my changes to the PowerPoint presentation when I forced a restart, but it doesn’t matter and the presentation goes well. No one knows anything was ever wrong.

There are so many links in this wonderful technological chain. It is marvellous when it works, but oh, so vulnerable.

Choosing New Software – Best of Breed or Integrated?

When you’re looking for new software, one of the first things you must decide is whether to look for two or more systems that are best in their particular fields, or one software system that does nearly everything you need.

This choice is between ‘best of breed’ systems:

or ‘integrated’:

The problem with the best-of-breed choice is that you have to do the integration yourself, or commission it. This means developing software to map the data in one system to the data in the other, scheduling the execution of the integration software, ensuring that reference data such as account codes and department codes are synchronised in both systems, and that both systems can be reconciled. It gets even more complicated if there are more than two systems in the mix.

The problem with the integrated choice is that you rarely get everything you want from one system, or, not affordably. And it means that if you only want new software for one particular purpose (e.g. professional services management) then you have to throw away everything else that you have and start again.

It’s not easy to choose.

But if you decide to go the best-or-breed way then Infor’s ION integration framework solves the integration problems by providing technical, logical and procedural management of all aspects of integration.

See this YouTube video to see how we’ve integrated time@work (for Professional Services Management) and Infor SunSystems (for back-office accounting):

http://youtu.be/nS78-f8yU-g

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: time@work