by sylviamunson

LDCs Really Are Different!

My career has been heavily pipeline transportation focused – hence the book on pipeline transportation! In the last several years I have been working more with Local Distribution Companies (LDCs). While I worked in the pipeline world, I had always considered LDCs as a flavor of pipeline, just like intrastate pipelines, midstream, and interstates are pipelines.

Most LDC’s accept nominations! Doesn’t that make them a pipeline?  Not really!!

All natural-gas LDCs are pipelines in the literal sense. They are physical pipelines in the ground that are used to distribute natural gas. Some LDCs come closer to acting like an interstate or intrastate pipeline because of deregulation – in the instances where they are required to support transportation on behalf of others – such as marketers and shippers.

Acting as a pipeline is only one of the many services that LDCs perform. There are a host of others.

This is the first of a series of posts on LDCs. I thought I understood them. I now know that I have a lot to learn from them.

by sylviamunson

7 ways to give a natural gas scheduler good customer service

Gas scheduling is an important part of natural gas transportation. A good friend, Norm Walker, often referred to scheduling as “the center of the universe” in the pipeline business. I have yet to find any information to prove him wrong.

The scheduler is the logistics coordinator for the entire business flow of gas. A scheduler takes all of the information about what has been bought, sold and what contractual obligations and rights are in place and creates a daily plan to get the gas from all of the receipts to all of the deliveries, at the best rate, with the best likelihood to flow. Next, the scheduler has to put all of this information, via nominations, into the multiple pipelines on which the gas will flow.

Imagine a coach trying to coordinate the plays in multiple simultaneous games. That is what the scheduler is doing working across multiple pipelines. Now, add in the factor that each pipeline has different service offerings, different scheduling rules, and different web technologies. Often you will see that schedulers will focus on and specialize in a region of interconnected pipelines because of the huge learning curve for each individual pipeline.

I have seen schedulers who nominate on eight different pipelines every day. They are amazing! They know the contracts, locations, rules and idiosyncrasies of each of the pipelines they work with. It is a stressful job.

So how can we make it better?

Standards in natural gas have eased some of the learning curve, but there is still a lot of room for improvement.

1 – Make pipeline websites that work on all of the major browsers, Chrome, Internet Explorer, and Firefox.

Make the websites work on multiple older versions without any custom configuration in order to use the site. This is so important. A scheduler doesn’t have time to deal with the fact that Pipeline A only works on Internet Explorer Version 9 if patch x.y.z is installed. They don’t have time to have to have multiple versions of a browser on one desktop so that they can use version K for your pipeline and version J for someone else’s.

2 – Make the screens plain and simple.

Put the minimum amount of information on a screen, especially a data entry screen. Minimize the number of keystrokes in every way possible. It may be really cool and high tech that you can resize grids, rearrange data, etc. But if the scheduler has to do that every time, then that is time wasted for them. You may think that you are giving the scheduler really interesting extra information that they will find useful. But if they have to provide extra information or have to navigate (wade) through your “added value” data then it becomes burdensome fluff.

3 – Use the standard terms.

I don’t know how many times I’ve had this conversation. I don’t understand why people question it. You are doing your customer no favors if you choose to use interesting derived terms instead of industry standard terms for a screen or a data field. The scheduler should not have to use a nanosecond of brain translation to determine that when you say “business party” you mean “shipper”, or “agent” or something else.  In this case, the real, correct term is “service requester.”

4 – Minimize the number of fields that have to be provided.

There are a handful of fields that are always required for a nomination transaction. There are a lot of fields that are selected by the pipeline as either business required or optional. The pipeline should look for every way possible to avoid using extra fields. Every variable that is added creates a possibility for failure of the transaction. Minimize the moving parts and you minimize the failed transactions.

5 – Provide default values in as many fields as possible.

If the scheduler knows that their service requester id is defaulted from their login, that their transaction type is always defaulted to current business and that their start date is always defaulted to the next available timely cycle, then those are three things the scheduler doesn’t have to juggle. This minimizes the keystrokes required and the possibility of transaction failure and makes both parties more successful.

6 – Provide ample warning when screens change or systems change.

There are certain times in the business cycle when a scheduler’s time is pure chaos. With a timeline well ahead of the implementation date, schedulers can test the changes, receive training, and ask questions without having to do those tasks during bid week.

7 – Have awesome help files.

If a new service comes online, it would be great for a scheduler to be able to click on help and see the nomination requirements for that new service. If a new system is launched, provide thorough help files as well as web based tutorials that the scheduler can watch on their own schedule. Some pipelines have done a great job with help files in very imaginative and creative ways.

What are other ways that pipelines, as service providers, can provide good service to schedulers? These are a few ideas to get you thinking. I’m sure you can come up with more that should be considered.  I’d love your input to develop a “best practices” list.

by sylviamunson

The Deep, Deep Details – Transaction Types

Do I need to apologize first for this post?  This post gets deep in the weeds of data interaction on the nomination transaction.  But somewhere, somehow, someone has to get down in the weeds to explain why people keep tripping over transaction types.  It has to be said! So here it comes.

Transaction Types are data values on nominations that indicate the shipper’s usage for the quantity that is being requested.  That’s Sylvia’s definition and it assumes you know what a nomination is and who is a shipper.

The standard default transaction type in nominations is ’01 – Current Business’, meaning that this transaction uses the general terms of the contract.  There are over 100 transaction types available in the North American Energy Standards Board (NAESB) Nomination dataset, but a single pipeline will usually support only 5-10 of those types.

Okay – that’s easy – what’s the big deal?  There are, actually, two big deals.  The first is that the transaction type can occur on each nomination in each model type and this opens the door for confusion and varied interpretations.  The second is that there are three different transaction types – Transaction Type, Upstream Transaction Type and Downstream Transaction Type – and people tend to make assumptions regarding their meaning.

The first issue:

A pathed nomination uses one nomination line item to transact business and, therefore, one transaction type.  Easy.

A non-pathed nomination uses two nomination line items to transact business and, therefore, two transaction types.  So we need to have rules in place on what transaction types are used in which situation and how they are balanced.

Then we get to the pathed non-threaded nomination and see that it uses three nomination line items to transact business and three transaction types.  Now things are starting to look complicated.

Let’s look at a few of the most commonly referenced transaction types.  These would be the ’03 – Imbalance Payback from TSP’ and ’04 – Imbalance Payback to TSP’.  Note that TSP in this case stands for Transportation Service Provider.

If you are submitting a pathed nomination and want to use ‘03’ to receive 500 DTH of gas back from the TSP then you’ll submit a nomination with zero as the receipt quantity and 500 as the delivery quantity.  Clear and easy.

If you are submitting a non-pathed nomination then you won’t need to enter an upstream nomination but you’ll enter a downstream nomination with ‘03’ transaction type and 500 DTH as the quantity.  In this case the payback is coming from the pipeline’s linepack volume and there is no need for a receipt type nomination to balance the transaction.  Still clear and easy.

So what happens if you are submitting a pathed non-threaded nomination?  My first choice would be for you to enter a downstream non-pathed nomination with ‘03’ as the transaction type and the quantity of 500 DTH on the downstream non-pathed nomination.  The corresponding pathed nomination and the upstream non-pathed nomination would be with ’01 – Current business’ as the transaction type and would contain either zero or the quantity that needs to be transported.  This seems pretty clean because the shipper is only telling the pipeline where the payback gas needs to be taken off the pipeline, without association to any transportation or supply of gas.  The second choice that I have seen in implementations is to create, essentially, a whole path of gas for this ‘03’ transaction type.  In this implementation, the shipper would create an upstream non-pathed nomination with a quantity of zero, a pathed nomination with a receipt quantity of zero and a delivery quantity of 500, and a third nomination as the downstream non-pathed with a quantity of 500.  All three of these nominations would have the transaction type of ‘03’.  This second choice is technically correct and do-able, but it puts a lot of extra work on the shipper and unnecessarily ties the payback transaction to a path of gas that is not needed.

There are other transaction types which cause these same scenarios, but NAESB and most pipelines do not give clear instructions on how they are used.  This leaves room for interpretation – a dangerous game.  Interpretation results in different pipelines solving the same problem in different ways and  different shippers trying solutions that the pipeline doesn’t expect.  This makes it hard for everyone involved to get the results they expect.

The second issue:

There are three (3!) different transaction types available on the model types.  For a long, long time there was only one transaction type and it was called Transaction Type.  As NAESB standards progressed, pipelines asked for an Upstream Transaction Type and Downstream Transaction Type to be added for the confirmations process.  The Upstream and Downstream Transaction Types, if you look up the NAESB definition, do NOT refer to the business being conducted on the current pipeline. The Upstream Transaction Type refers to the transaction type on the pipeline Upstream of the current pipeline. The Downstream Transaction Type refers to the transaction type on the pipeline Downstream of the current pipeline.  Interestingly, people look at the name and think that the Upstream Transaction Type must go on the Upstream Nomination in the Non-Pathed and Pathed Non-Threaded Model types but this just isn’t so.  The Upstream Transaction Type can go on the Pathed or Non-Pathed Model but NAESB clearly states that it is referring to the transaction type of the nomination on the upstream pipeline.  All of the same logic/rules apply to the Downstream Transaction Type, of course.  And, the Upstream and Downstream Transaction Types do not exist on the Pathed Non-Threaded Model Type at all!

Clearly looking at the definition of data elements is essential before assuming their meaning or intent because the name is not always the only indicator of the purpose.  Nominations are complex transactions.