Mind The Gap
Why do traditional software platforms in Supply & Trading not enable daily scheduling operations?
The short answer is two reasons - the smallest unit size of the volumes that need to be tracked, and the smallest unit of time that volumes need to aggregate over.
Typical Supply & Trading enterprise application landscape consists of transaction lifecycle processing systems - the ERP (contract lifecycle and accounting general ledger) and ETRM (Energy Trading and Risk Management) systems. ERP systems track volumes at a contractual level; aggregated to a financial reporting month, and processed in arrears. ETRM systems track volumes at a transaction level; aggregated to a forward risk month, valued daily. The database architecture of both systems is set up to classify all activities at a contractual or transactional level and a monthly time unit.
A contract can be composed of multiple transactions; a transaction composed of multiple movements. Movements can be made up of multiple distinct volume batches.
ERP systems aggregate actualized batch tickets to the contract level and associate an invoice to the contract. The process is to associate the movements to the right cashflow month and contract so that the results align with the invoicing cycle and eventually how financial reporting is conducted.
ETRM systems capture planned transactions to represent forward inventory and aggregate them by month to report risk exposure. Scheduling activities (timing, volumes) are not planned forward for months or years by rule. And once planned, because scheduled movements, batch sizes, and timings are changed frequently they are not updated under the corresponding transaction in the ETRM until executed and sometimes not until fully actualized. Why bother, if it is going to change anyway?
Scheduling operations need to track volumes at two fundamentally different volume unit sizes and have to deal with changes on an hourly or daily basis.
Scheduling has to account for the smallest unit batch size for a movement (1,000s of barrels on a pipeline or vessel, 100’s of barrels on a railcar or truck). And account for inventory at a product & grade level (100,000s of barrels or gallons) at multiple geographic locations served by different transport modalities with unique capacity attributes that make up the batch volumes arriving at different times. Both inventory and movements are aggregated to a daily time bucket going forward at least 30-45 days. Batches arriving in the next 24 hours are aggregated to intra-day hourly time buckets – to project volume availability or how time-based pricing formulae will resolve before or after midnight.
This enables operational activities such as re-grades, split batches, sales off the line, partial or full re-directs to be accurately assigned volumes. In addition operational issues like tank contamination, maintaining required finished product spec quality (RVP, octane, cetane, sulfur), capacity constraints, cycle constraints, production schedules, channel commitments, seasonal shifts, turnarounds, etc. can be managed down to the smallest volume and time units.
ERP and ETRM systems are not designed to track and aggregate volume at these time frames, much less reflect the nature of the physical assets. They can be painstakingly customized to perform some of these activities, but the core data models based on a contract and monthly aggregation of volumes are a show stopper. So the default has been to run scheduling operations using a tool designed to be a computerized analog of paper accounting sheets - spreadsheets.
Scheduling operations are done manually in spreadsheets because the user is not constrained in defining unit sizes and each cell can be set to represent an aggregated time bucket, usually daily which then can be simply rolled up to weekly or monthly buckets using the summation or average function as needed. But it comes at a huge price. Size and performance limitations constrain the ability to add more data. The flexibility of creating unique spreadsheets results in diverse, or worse inconsistent, assumptions being employed to project forecasts. Because spreadsheets overwrite forecasts with observed values as time progresses, the historical record is only a single snapshot of a state of inventory. This constrains the ability to do any robust analysis of how changing inputs contributed to how the plan was actualized. On a broader scale, it inhibits understanding the real feasibility/tolerances of operations.
We’ve seen 200MB spreadsheets straining to keep track of all these moving balls in a live network. It’s a full-on 100% mental effort to keep updated. The result is that the best that can be done is manage to the average. Take what the market gives, minimize the bullwhip effect of timing and use the inventory to hedge against the variability in demand and capacity outages. Key data sits in offline spreadsheets across multiple trading and scheduling desks, each reflecting the biases and views of their owners.
Visibility? Available retrospectively in the ERP once everything is said and done.
Analytics? Snapshot exercises using a BI tool where the analyst has to manually reproduce a facsimile of the underlying data.
KPIs? Limited to product level summarization and produced weekly due to the effort to consolidate a singular view from hundreds of disparate spreadsheets.
BAYZYEN solves the volume unit size and unit time problem, relates it to physical and contractual constraints to create a commercial twin of the underlying physical distribution system.
By automating data ingestion and data processing it tracks and improves data quality. By allowing configurable business rules, it solves for data gaps or process requirements. By layering in constraints and alerting against them, it allows users to manage by exception, freeing up valuable time to focus on higher-order problems.
Users have full visibility to a single location or the entire system with a single mouse click, updated automatically as any input changes. Analysts can create robust analytics or custom reports using data from the application.
As for KPIs, customers can build baselines for operational and economic KPIs they never could track before at a single asset/location or across a large portfolio of assets/locations and measure deviations so as to employ corrections in real-time.