What Can I Say?

It’s not often that I run out of things to write about.  Actually – that has never happened.  The situation that I’m in right now is that there are so many things that need to be written about that I find myself stuck – unable to make a choice and run with it.

I could spend days on the upcoming changes from Order 809.  It is potentially the most exciting set of changes that I have seen out of FERC in quite a few years.  If we don’t do our job well on this one, they could be minimal, boring changes. But I am hoping and praying that we do our job well and make some changes that positively impact our industry and our customers.

I could spend days writing about technology and the challenges that we face when met with such wonderful opportunities in technology.

I could spend days on the details of the business processes in natural gas.  I learn more every day and am regularly surprised at the new ways that companies find to do business in such an ever-changing marketplace.

I love hearing from you.  I have learned through three different people this last week that my questions to you put you in a difficult position. Often you cannot provide a response to my postings because it would be seen as a company position and you cannot afford to make that statement or, more likely, you are not permitted to make that statement. Don’t hesitate to pick up the phone and call me!  Don’t hesitate to send me an email.  I can use the information, if appropriate, by stating that “A friend told me,” or some other vague reference that points no fingers.  I promise that I won’t say “A friend that works in building X for company Y in the Z department told me…”

Sylvia

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.

Those picky little details in gas system design – elements that look like a key, sound like a key, but they are NOT keys!

Good Afternoon!  This is becoming a series of blogs on the topics of details in gas system design and, in particular, the nomination key.  Look at the two previous blogs to get up-to-speed on this discussion.

The first one, talking about composite data elements, can be found at: https://contentsunderpressurebook.com/2015/08/04/those-picky-little-details-in-gas-system-design-that-can-cause-so-much-trouble/

The second one, talking about the nomination key, can be found at: https://contentsunderpressurebook.com/2015/09/09/those-picky-little-details-in-gas-system-design-the-nomination-key/

Today we’re going to talk about two NAESB data elements that are often mistaken to be associated with the nomination key. We’re going to stir the pot and talk about the nomination dataset’s Activity Code and Nominator’s Tracking ID (NAESB WGQ Standard 1.4.1, Version 3.0, www.naesb.org, password protected).  Neither of these is a key to a nomination and neither is part of the key to a nomination but a lot of people try to use them as a key.

The Activity Code is best described as an alias for part of the nomination key.  NAESB does not define the data elements that the Activity Code represents, therefore one pipeline may see it as representing a contract + path while another pipeline may include other, non-mandatory elements in their definition of Activity code and a third pipeline may use the Activity Code as the entire nomination key.  It is up to the individual pipeline to determine which elements it uses to comprise the Activity Code.  The Activity Code was created in the early days of the nomination dataset when two pipelines offered services where the shipper could provide an alias plus dates and quantities in order to nominate without having to provide the whole string of nomination data.  One of those pipelines included the Package ID data element as part of the Activity Code and the other didn’t.  A few other pipelines picked up this feature, with varying methods of implementation, when their shippers expressed appreciation of the feature.  Today, with all of the web technologies that are available, some of those same pipelines have abandoned the Activity Code because they can use copy functions and other tools to give the shipper the same level of service.

The Nominator’s Tracking ID was designed for EDI (Electronic Data Interchange) transactions as a method of communicating error- and warning-messages related to a specific nomination line item in a dataset transmission that might contain many nominations.  The Nominator’s Tracking ID is only valid for the lifecycle of the initiating nomination and its corresponding validation message within an EDI dataset pair.  After that, the Nominator’s Tracking ID has no value.  If a shipper sends an update to the same nomination line item in a later dataset, the shipper may use the same tracking ID or a completely different tracking ID.  This information is not validated by the pipeline because the tracking ID means nothing to the pipeline.  Likewise, the shipper can re-use the same set of Nominator’s Tracking IDs every time they send a new nomination file because the tracking ID means nothing beyond the validation of that file.

It appears that often, when a developer looks at the Nomination dataset and sees these two elements they interpret one or the other to be “the key they’ve been looking for” in place of constructing a nomination key out of that long list of data elements we discussed in the previous blog.  Unfortunately, that won’t work and will, soon, cause other problems to arise.

Avoid the problems.  Study the datasets.  Understand the key.  Have fun with this puzzle.

Oh – and for those of you who don’t know – the book is out on September 15th!  Amazon now has it listed for pre-order – or you can buy one here on the website!  Woohoo!

Those picky little details in gas system design – the nomination key

I said I’d talk about the nomination key speedbumps “tomorrow.”  Well, “tomorrow” came a little later than I had intended, but here I am.

The nomination key, in NAESB’s 1.4.1 dataset causes so much confusion.  The key is defined in NAESB WGQ Standard 1.3.27 (Version 3.0, www.naesb.org, password protected) and, to those who help develop and maintain this list, it is very clear.  To those who read this list and try to apply it to the dataset, it becomes muddy quickly.

First of all – what is a key?  If you’re an IT developer, you may think that we’re talking about a DB key which is a system generated unique identifier for a row of data.  If you’re a business person, you may be looking at a key as the data that I need to find a nomination.  And you are both partially right!

“…The nomination key is the group of data elements in a nomination that, when a value in one or more elements is different, causes a new nomination to be created. It is important to understand the key and how it works in the nomination process. The list of elements that comprise the key are those that, when combined, create a unique line item of a nomination. When an element is not part of the key, then the value of that element does not contribute to the uniqueness of the nomination and may be changed without creating a new nomination. When an element is part of the key, then a change in the value of that element will result in a new nomination being created. (Contents Under Pressure – The Complete Handbook of Natural Gas Transportation)

Okay – that’s simple enough.  Now go look at the list of data elements that comprise the key.  NAESB has a list in NAESB WGQ Standard 1.3.27 that contains 18 data elements.  Two of those elements are mandatory for a pipeline to support and for a shipper to send.  The remaining data elements are mandatory in certain conditions, optional in other conditions and not used in some conditions.  The pipeline will determine which of the elements will and can be used.  The shipper will have to apply the dataset conditions as well as any pipeline conditions to determine which of the pipeline elements to use and when.  There will never be a real scenario where only the two mandatory elements are used.  There are quite a few conditions dependent on nomination model type and direction of flow that cause either the receipt side information (Receipt Location, Upstream Party, etc.) or delivery side information (Delivery Location, Downstream Party, etc.) to be sent.  Most of these conditions are not determined by the sender of the information (the shipper), but are determined by the nomination model type being used, the direction of flow and the pipeline business requirements.

The Package ID is one example of an element that must always be supported by the pipeline but is always optional for the shipper to send.  The Package ID is used for the benefit of the shipper if they need it.  The pipeline may make other data elements such as Upstream Contract and Route optional or mandatory and the pipeline include use of elements such as Capacity Type Indicator as optional for the shipper.

You’ll notice that the key does not contain a nomination begin and end date.  That may seem strange, but it’s not strange at all.  NAESB WGQ Standard 1.3.7 establishes a rule that each nomination exists for a single day and when a multi-day nomination is submitted, each day of that date range is treated like a unique nomination.

The toughest part of the key is when you need to determine which value of one of the compound elements, such as Upstream Party or Delivery Location should contain to satisfy the key requirements (See previous blog at: https://contentsunderpressurebook.com/2015/08/04/those-picky-little-details-in-gas-system-design-that-can-cause-so-much-trouble/ for more information on this condition).

Understanding what is the key, what comprises the key and what is NOT part of the key is terribly important in implementing these NAESB transactions.  I’ll write next on what is NOT part of the key.  Stay tuned.

Those picky little details in gas system design – that can cause so much trouble

http://www.contentsunderpressurebook.com

We’ve all encountered them – those times when you know you have everything nailed down perfectly in your system design.  Then, three weeks into production, you hit that “gotcha” moment where you realize that you didn’t know all that there was to know about some of the details.

There are plenty of those that we can look at, but today will be about one my personal favorites – the business party name.  In NAESB-speak, there are four business parties in a nomination.  Let’s focus on that one transaction set.  There’s the Pipeline (aka Transportation Service Provider or TSP), the Shipper (aka Service Requester or SR), the Upstream Party and Downstream Party.  Each of these is identified by a high level grouping such as Transportation Service Provider Data, Service Requester Data, etc.

This high level grouping identifies three data elements in each grouping. The name, the common code (NAESB uses the DUNS number), and the proprietary code.  There are, then, conditions and standards to provide instructions on when to use each one. The pattern is very consistent.  Names are required on web sites but not in EDI or flat file formats.  Common codes are always required but the proprietary code is required if the common code is not available.  This means that you can send the data without a common code if you have the pipeline’s proprietary code instead.

The solution providers, the IT guys, have to know which data element to put where and how to properly label it.  It isn’t impossible to determine, but it does take thought and planning and cannot be just plopped into the dataset.

Okay, that sounds easy enough, so what’s the big deal?

The big deal comes into play when you realize that the Upstream Party and Downstream Party are part of the nomination key.  The nomination key is that set of data, defined by NAESB that, when put together, distinguishes uniqueness between nomination line items.  The reference to Upstream Party does not select the DUNS number or Name or Proprietary Code.  It references the grouping.  And since there are a whole set of rules to determine which one is used and when, this means logic must be created that determines the key in chorus with these mutually exclusive fields of data.

For instance, if I am sending a nomination via flat file and I do not have a DUNS number then the proprietary code is the code that I will use to identify my Upstream Party and that value will become part of the key. However, if I am sending a nomination via a web site (EBB application) and I have a DUNS number then the DUNS number will be part of the key.  In either case, the expectation is that the pipeline will always receive either a DUNS or proprietary code and not just a name.  Unless that name is all that the shipper can provide, which happens!  So the logic to determine the key must take into account the entire set of conditions and determine whether the conditions of the key are met in this line item.

It’s not looking so obvious any more, is it?  And these aren’t the only two data elements where this can occur. It can also happen on the locations and there are four possible locations in the dataset.

Now that we’re talking about the nomination key, there are a couple of other places where you can hit a speed-bump in development.  I’ll provide more on those tomorrow.  Have a great day!

There is a movement in the FERC . . .

www.contentsunderpressurebook.com

NOPR for NAESB 3.0 Issued July 16, 2015

On Thursday of last week, the FERC (Federal Energy Regulatory Commission) issued a Notice of Proposed Rulemaking (NOPR) proposing the adoption and implementation of Version 3.0 standards of the Whole Gas Quadrant (WGQ) of the North American Energy Standards Board (NAESB).  Whew!  That’s a mouthful!

Hooray!

This was a new and unusual position for NAESB in that the FERC never took action to adopt NAESB’s WGQ Version 2.1 standards.  By adopting the Version 3.0 standards, the adoption will incorporate all changes made for Versions 2.1 and 3.0.

The FERC is proposing these standards be implemented for business on April 1, 2016.  This makes a lot of sense and complements the timeline for the FERC’s recent Order 809 deadline of additional intraday cycles for April 1, 2016 (see other blog posts for other components of the Order 809 document). Additionally, this deadline gives everyone a big window of time to make the changes, test thoroughly and move into production for April 1.

So what does Version 3.0 contain?

1 – Moving the nomination deadline from 11:30 a.m. to a later 1 p.m. time.

2 –Addition of another Intraday cycle into the nomination timeline.

3 – Removal of the requirement to use, display and maintain common location codes through the Data Reference Number (DRN) location identifier.

4 – Reporting requirements for Design Capacity and definitions to distinguish Design Capacity from Operating Capacity.

5 – Requirement to post Offers to Purchase Released Capacity

6 – And, of course, the usual maintenance modifications, additions of new elements, additions of new codes.

The good news is that none of these are major game changes to the way we do business today.  The other news, however, is that the impact on IT systems can often be deeper than anticipated.

Moving the nomination deadline from 11:30 a.m. to 1 p.m. sounds like a huge win because now shippers and marketers will have the ability to trade gas for an extra 1 ½ hours each day! The other side of that coin, however, is that now pipelines have to shorten their confirmation and scheduling window from 5 hours to 4 hours.   Four hours may sound like plenty of time to schedule a pipeline but scheduling is not the only time consumer.  The confirmations process may require several iterations between pipelines when the gas flows through multiple interconnects between the wellhead and the burnertip. And for pipelines with a complex scheduling scenario, such as multiple constraints and reticulated, the scheduling process requires multiple iterations; some before the confirmation process and some after.  Pipelines that have solved this problem and whittled it down to a short a precise timeline will be able to move to a four hour window easily.  Other pipelines that still struggle to meet the five hour window will have to have process changes and system changes to squeeze the process into four hours.

And this is one example.  My point is that any of the seemingly clear and simple requirements of NAESB V3.0 and FERC Order 809 may be ones that cause difficult system changes for a pipeline or for a marketer.

Terminology: What is an EBB?

I work with a lot of young people in the energy industry.  They are often in the technology end of the business, but they are just as likely to be from the business side of natural gas.  When the term ‘EBB’ comes up, I get the quizzical look and the imminent question…”What is an EBB”?  And it is a question that I don’t like answering because it is somewhat embarrassing.

EBB stands for Electronic Bulletin Board.  Back in the days before the Internet, there was EnerNet.  EnerNet was a company that formed out of the FERC Order 436 requirement that interstate pipelines make certain information publicly available for shippers and potential customers on their pipeline.  We didn’t have the Internet, but we had fancy 2400 baud dial up modems.  Some pipelines formed their own public boards for posting this information and some subscribed to services, such as EnerNet to make that information available.

The EBB is a term that has lived a good life and a long life, but to use the term today causes confusion.  Today, in natural gas we have websites.  An interstate pipeline usually has two distinct website offerings to meet regulatory requirements: the Customer Activities Website (CAW) and the Informational Postings Website (IPW).

CAW and IPW have meaning.  When you mention a CAW you know that this is the secured access site that customers use to transact business with a pipeline. When you mention and IPW you know that you are referring to the public information, unsecured posted information on a pipeline.

So does the EBB cover both the CAW and the IPW or is it something else? Good question!  In some of the NAESB standards they refer to the EBB/EDM as those electronic standards related to the website without specification of whether this is the IPW or CAW.  Elsewhere in NAESB WGQ definitions there is a definition of EBB/EDM that points directly to the CAW with no mention of the IPW. If you go deep enough to look at the EDM manuals, you will see that the EDM subcommittee has distinguished that EBB is the CAW and they refer to the IPW as IP/EDM.

Are you confused yet? You are not alone.  It is time to change the terminology and put the EBB term to rest and let the distinct IPW and CAW terms become the common language.

The answer to the question is that, even though Electronic Bulletin Board precedes the internet, it refers to the Customer Activities Website in Natural Gas.  For me, I try to avoid the term all together and just refer to them as CAW and IPW.