 Okay, good afternoon. Good morning, good evening, depending on where you're based. My name is Gary Chrissy. I'm gonna be presenting today on what we call the ideal proof of concept. This was a wing-to-wing proof of concept for an inter-company distributed accounting ledger. Again, my name is Gary Chrissy. I'm an enterprise architect at General Electric at GE corporate and financial systems. So let me go ahead and get going here. Probably familiar with GE. I won't spend a lot of time talking about the company, but significantly large global manufacturing in various different areas, healthcare, power generation, renewables, aviation. And so a lot of, if you look at kind of that grouping of companies, what you start to see, because one of the first questions I get is why would this be applicable to blockchain if you're talking about inter-company or why would a distributed system be necessary? But I think one of the things you'll see is that right off the bat, an enterprise, a conglomerate is a built-in consortium. So we kind of went kind of based off that premise to say, well, what can we do internally first and then potentially down the road, open it up to external suppliers and customers as well. But today we're just gonna talk about what we could do within the walls of General Electric. So here's the agenda. I'll run through the problem statement in our overview for a solution, talk a little bit about blockchain and hyperledger fabric. I won't spend as much time on that with this group since if you've been at the global forum for the last two and a half days, then you probably have a pretty good idea at this point. You probably came to the table with the decent amount of knowledge. So we'll talk about the solution architecture. This was built using Oracle's blockchain platform. So we're gonna talk a bit about Oracle. But I think that what you'll see is that a lot of those components are interchangeable. And we'll talk about that because that was important to us as well. And where we use different things that were provided by a vendor versus where we worked with our implementation partner, which was Deloitte and where we used internal systems. And we'll talk a little bit about these different pieces. And again, this is wing to wing, right? And I say that because I'm not just focusing on the blockchain itself, right? So blockchain is a storage mechanism at its most fundamental premise for what it does. But there's a lot of things that have to happen around that to build an actual application that does something for functional end users. So we're gonna talk about different things there, both pre-chain and post-chain. And we'll look at the user experience, what we developed as a front end and then we'll close it out and hopefully we'll have a couple of minutes for any questions. Okay, so the challenge, what we were looking to do is we had a internal billing system, IBS, which is a 25 year old mainframe that was processing about four million intercompany invoices each year. Very high total cost of ownership. If you think about the cost to maintain a mainframe, the scale of this work was not necessarily mainframe worthy, but that's where it had been built over 25 years ago. So you have a significant cost in maintaining that hardware, that software and the people skills to keep that running. So what we wanted to look at was what would be possible for intercompany transformation? And just to kind of take a step back for a second for those of you who may not be familiar with that term, it's pretty much what it sounds like. And so if I am one company, General Electric and I have two divisions, let's say aviation and power, and they want to sell, buy and sell goods between them, I can't record that revenue and present it to Wall Street as revenue that came into the company because it was really revenue that was paid from one part of the company to another. So before that, we do our external reporting, those numbers have to be backed out. So all of that intercompany accounting for activity that happens between the businesses has to be backed out. And there's a tremendous amount of cash settlement that's involved in intercompany because when one company buys from the other, you have to move that cash from one balance sheet to the other. And that's expensive. So you wanna optimize your cash movement. So you wanna do netting for settlement. So the concept of netting is this idea of if I owe you $100 and you owe me $50, well, we don't have to do two cash transfers, we can just do one cash transfer $50 and call it even. So all the accounting that goes into that and being able to track all of this activity is what we do in an intercompany billing system, okay? And so what we're looking at is how do we improve upon that instead of having a centralized mainframe, what would a distributed ledger look like? And so these were some of the things that we wanted to have in the system beyond just the ability to have it on a blockchain. It had to integrate with the financial systems. We wanted a mobile first, modern UI, especially the users coming from an old mainframe. We wanted to give them something that was very modern and functional, microservices, architecture, very modular, being able to swap pieces in and out as needed, a dispute management system and analytics. So we're gonna run through all of this. So this is really quick. I'm gonna give you an idea of what an intercompany transaction flow looks like. And you can see that the way we structured this proof of concept is around, we took three different businesses, our corporate aviation and healthcare, and we took a subset of transactions that we knew were relatively easy to work with. They were fairly clean. And we went ahead and we processed how those flows would go between our different legal entities, between our different company codes. And so this talks about how we structured that and set it up. So the solution design is really tied to a business capabilities model. So if you're not familiar with this term, this is something that is an enterprise architecture concept. And I encourage you, when you go in, one of the things that we learned very early on was that the technology was gonna be the easy part. Getting people to understand how this technology would work and help them and really understanding about the process change that needed to take place for this to work was really important. And so we had to really understand and know what the business needed. What did they expect? So we went through this exercise of building out a functional capabilities model. We identified in different ways, what activity the current system did, what activity the new system would need to do, and was it net adding? Was it crucial? Was it something that the users wanted but they didn't have today or something that was critical that they had to have? And so we kind of used this as our North Star as we were developing that to keep referencing back to are the tools that we're building and is the capability that we're putting into this software, this application that we're building meet these requirements and ensure that we were gonna deliver what they needed. So this is something that I like to take a minute to discuss and I think it's a good tool to use as you're going through this exercise with the users that you're gonna be developing the application for. Let me advance next side. There we go. So this is the design overview and you can see again what I was saying before blockchain smart contract is just one of the building blocks, right? Blockchain with smart contracts. It's in that middle layer there. That's where we're gonna do the invoicing and purchase order validation. We're gonna do the netting in the settlement and basically the intercompany agreements are those smart contracts. And that's kind of that rule that says, you're allowed to bill me up to a certain amount each month for certain activity. And as long as it's within that we're gonna let it go through or not. But a lot of other processes needed, right? We have the source systems in the ERPs where we're tracking this activity. We have data integration, data warehousing and of course the front end for the user interface, how they get at this information. So this is the solution architecture. Again, we did leverage a lot of the Oracle tool set here but there's different ways to build this and structure it out. But you can see that we kind of had a process flow here that went from the ERPs through these different, what we were calling microservices or modules. You can see in the integration layer we talk about enrichment and validation. And that was really kind of our take on on setting up oracles and not Oracle the company, little oracles, the idea that I could call out to other systems to get information that I need for the transaction. So DRM is a master data system, Eve is a validation engine. And what those things do is a PO might come in with a cost center or a legal entity but that's limited information. And there may be things that there are rules that I have. For instance, let's say I'm doing business with a restricted country. If I'm moving funds through a restricted country, there's certain paperwork that has to be filed. So we have to hold that transaction up until that paperwork is received. Well, the only way to know if it's a country that has restrictions on it would be to look up what country that particular legal entity is operating at. So you have to get that information from other systems. And then we go and we move it through the process flows. We have our smart contracts, which really helped us get kind of righted inception, being able to get those rules taken care of upfront because the biggest problem you have with a system like this is the reconciliation that comes at the end of the reporting quarter or the reporting month, depending on what cycle you're on. So having something that is self-reconciling upfront through the use of a smart contract takes a tremendous amount of manual work and incorrect entries and processing out of the mix. And so then we go through, we have our data warehouse and our analytics and the UI. I'll talk some more about that in a little bit. I gotta keep this moving because I know we don't have that much time. This right here is really just to kind of show you some of the process flows. I'm not gonna get too deep into this, but basically the way it was structured, and this is a simple one, this is a successful path, data comes in from the ERP. It goes through the integration layer. It gets validated against those other supplemental systems. We use the smart contract to assign a status, right? So it evaluates the transaction. Can it be approved and validated right off the bat? Does it need maybe documentation restriction? Is there a dispute, et cetera? So everything is recorded on the blockchain with a different status code. And as the transaction moves through its lifetime, those status codes change and it's all recorded on the blockchain. It's immutable and anyone can go back and see the different statuses of the transaction as it was working its way through the settlement. And when I get to the analytics screen, I'll show you why that's really, really valuable. Okay, this is a more complicated process flow. Again, for the sake of time, I won't jump into this. These slides are up in a schedule. So if you wanna download the PDF, you can review them and certainly reach out to me if you wanna discuss. This is dispute management. Dispute management was very important because today a lot of that was being handled through informal communication channels, right? Maybe email, maybe internal text messaging and sending documents and communication back and forth. But what we did was within Oracle's integration cloud, they have a process management tool which allowed us to create workflows. And the great thing about that is that the status of that workflow is also getting recorded on the chain. And any of the documents that are getting posted, we didn't put the documents on chain, but we were able to hash those values and put that on chain so that we know that the underlying documents that were stored in the document retention system were the documents that were there when the transaction got processed. So we were able to do some interesting things there. So why blockchain? This is a place where I can speed up a little bit. Certainly preaching to the choir here, I would assume. If you're here, you're hopefully a believer. But one of the things that's interesting that I'll call out here is trust. Because trust is one that again, I'm talking about GE within GE, and you say, well, why do you need trust, right? GE aviation is not going to try to defraud GE power for an internal transaction. And you're absolutely right. That's not the problem. That's not the kind of trust we're talking about. But trust goes beyond bad actors, okay? Trust in a process like this is I have to trust you to do it the right way. And you may through no malicious intent do something incorrectly. Maybe you thought it was correct. Maybe you didn't realize it was incorrect. A perfect example, I started to say earlier, maybe we have an inter-company agreement that says you can bill me $10,000 a month for certain services. And then halfway through the year, we decide that the project is getting smaller. We're gonna cut that down to 5,000, right? So in June is the last time you could do 10,000. Now July comes and you can only charge me 5,000. Inevitably in July, there's a very good chance that that billing is gonna come through at 10,000. Maybe somebody forgot to update it. Maybe somebody didn't get the memo it was being cut down. In the today's world that would go through and it would be something that would have to get reconciled and corrected later. In a blockchain with a smart contract world, if that smart contract inter-company agreement was changed, then now we stop that transaction right at inception and say, wait, this can't go any further because it exceeds the agreed upon amount. So those are the kind of things when we talk about trust that are really important even within an organization that is working with themselves. And transparency helps obviously be able to give everyone the understanding of what's going on there. No intermediaries, right? Today, corporate is the intermediary. If healthcare and aviation are doing business with each other or power, it all goes through corporate. You could question, why does corporate need to be in the middle of that? We're not really governing anything that they're doing. If anything, we're just adding extra layers of complexity. So why not let them work with each other and have Treasury just be a participating node on that network? And when they see it's time to settle, they do the cash movement. So there's a lot of really, really strong benefits in this that we felt that the blockchain value proposition was correct for what we were trying to do. Again, I won't dig into this at all, but federated enterprise focus around hyperledger fabric. We're not interested in trying to do this on an open permissionless kind of a Bitcoin network or an Ethereum network. Potentially you could do it in a closed Ethereum network, but we really thought that hyperledger fabric was the correct tool for what we were trying to do. Important to have a reality check on, not get caught up in your own hype, right? If the only tool you have is a hammer, then every problem starts to look like it nailed, right? So blockchain is not the solution to everything. So we wanna make sure that we're checking ourselves and saying, why are we doing this on a blockchain? Does this really fit? Is it appropriate? Cause if it's not, then let's not go down that road. Let's use some other known technology and keep it there. So this is kind of the proposal, the current state and the future state of how we move data across the system. And again, this is that parallel shared ledger that you have that operates alongside each ERP. So the data flows or it goes from the ERP onto the shared ledger, that then goes into the counterparties ERP. And this is all animated through the REST APIs and integration tools. And then you get the responding part of that transaction. Everybody needs to know, if you may say a charge is coming, but you can't charge me until you get receipt of the product. Well, when that hits the ERP that I've received it, that should kick off a integration that runs a smart contract that says, okay, they've received it. Now let's build them, et cetera. And it goes through that whole life cycle. So blockchain really gives us the ability to move that process along very well. So hyperledger fabric, again, this is even getting more into, I'm really not gonna spend any time on this. We think it's the right tool for all the reasons why you're probably here. You could certainly go and read this. One bullet point here, no cryptocurrency required. We are not doing tokenization. We are not doing crypto coins in this. It's something that we discussed as part of our brainstorming session. Maybe in the future, we would look at that. You could see a use case for tokenizing these assets and using that to minimize cash settlement in the form of an internal cryptocurrency, but that was way beyond the scope of what we were doing here. So for this, no crypto, just leveraging the abilities and the features of hyperledger fabric. Smart contracts, that's how we get the algorithmic trust and the rules that I've been discussing. So this is the smart contract that was written. There was seven different functions. And so this kind of explains what those functions were. And again, each one of these functions main task was to change the status on the transaction. So there was a PO submission and validation, invoices, matching the agreement itself, dispute handling, the netting and the settlement. All of that logic was written into these different functions and then that was used to update the status. And we had a master table of what the status codes meant. And depending on what status the transaction was in, that moved it through its life cycle until ultimately it got resolved or potentially rejected. Nothing ever gets deleted, right? We have it there, it's immutable, it's there, but we can certainly have a status of canceled or rejected or settled, whatever status you need to close it out. Okay, so this kind of talks a little bit about what we did with Oracle, what Oracle brought to the table for us and why we decided to use a PaaS service. I could go out and download Hyperledger Fabric and start using open source software and start building a network. For those of you who've done it, you know, it's not a simple task. There's a lot going on there. So working with a provider like Oracle who's kind of taken all of that technical infrastructure work and kind of isolated us from that. They spin up all the containers, they provide the rest proxies, they do the patching, all of that. We go in as a PaaS customer and we orchestrate. We grab different tools and we say, okay, I'm gonna go create a node, I'm gonna go write a smart contract, I'm gonna use their integration service and we're gonna bring all this together and we're gonna develop an application. So there's some additional things that Oracle does to enhance on top of Hyperledger Fabric that was useful and made it very easy. We did this whole proof of concept in about 90 days. So it was pretty extensive for what we developed in that amount of time. So this is what the architecture looks like. You could see kind of everything from going from right to left. You have your data sources, whether it's an on-premise ERP or a cloud ERP. You have your integration components which leverage the REST components that talk to the blockchain. And then on the other side, what Oracle brings to the table and you could do this in your own environment, but it's nice that they do it out of the box is this database as a service where you can stream your blockchain data in near real time into a parallel database for analytics and reporting. And that was really powerful for us because our users need to interact with this data and we didn't wanna be in a situation where we had to do these really intensive queries against the blockchain. That's inefficient. Blockchain is a transactional based system. The same way in my sub-ledgers and my ERPs, I also have limited reporting and I bring data into a data warehouse for my analytics. This gives us the ability to run that off-chain in parallel and they even have a concept in their database of blockchain tables where you could kind of maintain the integrity so that you ensure that what's on-chain and what's in the reporting database that you're not getting anything to break there in that process. And then we developed, of course, a front-end app to give users the ability. That's where they could check on what the status of their transactions were if something wasn't reported back to their ERP. Maybe they needed to file a dispute or they needed to submit supporting documentation. All of that would be handled through the front-end GUI. It was relatively low code, pretty simple, but we got that up and running as well and the users were very pleased with that. I like this slide, this kind of aligns the functional kind of that business capability and what we built as a solution to the technology itself. And this is one of those cases where, again, some of these components could be augmented with other providers and things could be swapped out. Maybe instead of Oracle Analytics Cloud, one of the providers prefers Tableau. So they use Tableau to do the analytics. Maybe instead of Oracle Integration Cloud, somebody else is using Dell Boomi where they want to just write it themselves. They have a proprietary integration tool that they use. So you can kind of swap things out and that's really important for decentralization because for me to go out there and tell the businesses or then if I ever extended outside the business, hey, come use my blockchain app, it's decentralized, it's distributed, but by the way, you have to use my vendor and you have to use my tools and this is the way you have to do it, it kind of defeats the purpose. It's not really, that's not a good way to do consortium building. You really want to give people the opportunity to build on this in the way that they need to themselves. So I know we got to keep moving. These are really just screenshots. We're almost at the end here. So this is just screenshots of the different tools, the identity cloud management. This is where you create the users and you set up your remote identity providers. This is, again, just how you would do authorization and authentication, getting users into the system. Data integration, these are the workflows that would take the data out of the ERP. They would basically monitor the ERP for messaging in the queue and then they would run a workflow that would bring it onto the blockchain, execute the smart contract, et cetera. This is an example of the Oracle Blockchain as a service console. You can see there my Hyperledger Fabric Network. I have three organizations, Corporate Healthcare and Aviation. And then you can see my ordering nodes, my certificate authority and my peers that are running on each one. This is, again, through the console view, I can actually look at the ledger and I can see the actual activity that's on the ledger itself. So as a transaction gets processed on a smart contract, I could see it here. Or, again, I could go to that external database and see it there. Or, through any kind of application UI that I've developed. This is all it takes to set up this rich history database. You just come in, you click a button, and you say, here's the connection string to my database, my username and password. And it automatically starts streaming the data into the database. It creates the schema for you and then it loads the data there in a JSON format which we then created views to parse the JSON and stage the data in a more kind of a denormalized manner. And then we built executive dashboards. And so we were able to show things like total invoice amount for a particular period, the total number of invoices, geographically where the activity was happening. Interesting side note about the text, the executive summary there. That text was not written by a person, a human. We, that is actually in the Oracle Analytics tool, it was able to define that, write that text using an AI algorithm. So earlier I talked about changing the status codes and what this really comes down to is what I refer to as transactional provenance. And so we hear that term used in supply chain but for an accountant, especially some kind of like a forensic accountant or any kind of analyst understanding the life cycle of a transaction is extremely useful. So being able to kind of show that at any point in time and you can see here the different timeline views of all these different activities taking place by cost center, by invoice, et cetera that somebody could analyze and look at. We could also see the transaction flows of how things are moving through the system, whether they were cashless transactions or if they had foreign currency translations, if they were purchase order or a non-purchase order. And ultimately this was the end result front end that the users were able to log in and see through their UI and interact with the data to be able to interact with the blockchain and the rest of the system. And I think that brings me right to the end. This is the overall summary, integration, blockchain, data warehouse, analytics, everything I've talked about enables flexibility and business agility and that's it. I'm gonna jump over to Q and A. I apologize for rushing, but I know this was a short amount of time to discuss a lot of material. I'm certainly happy to discuss with anyone if you wanna reach out to me. One of the first questions that I'll answer real quick and then I'll jump into the QA and try and close that out is one of the first questions I get is did this go to production or why didn't it go to production? Basically why it didn't go to production is that you, what we realized from this was that the technology was easy. The hard part was changing the functional process. This was going to require a significant amount of change for our business users. And in a world where we were heading into COVID and some other things that were going on, we decided to table that temporarily. We are still planning on doing this. We're using the foundation of what we learned here for some other supply chain proof of concepts that we're working on, actually pilots that we're gonna try to launch to go into production. And I feel strongly that we will get there, but it's definitely the lesson learned is you need to bring the functional team along with you and they need to know what they're getting into. So it's questions Q and A. It says impressive POC, but in a consortium, if one party uses Oracle Blockchain Platform, every participant has to do so too, right? The answer there is no, they don't. This is a hyperledger fabric foundation in Oracle and I can spin up nodes in AWS. I could spin up nodes in my own personal blockchain as long as they are hyperledger fabric nodes and they are compliant in terms of versioning, then yes. And so we even talked about in terms of deeper resiliency, would it make sense to have nodes running on other networks? So those are all things that we would consider if we did go to production, but yes, you definitely are not locked into using just Oracle if you use their pass. So I think this is a related question. It says it defeats the purpose of what you said, avoid vendor lock and give options to all companies in a consortium, but yeah, so you do have options. You're not locked into just using Oracle. And then we put here, you mentioned that trust in data is also about reducing human error. Have you taken steps to reduce in human error during data entry, i.e. when users create a transaction? We didn't tackle that in this concept because the primary entry point for that data entry is the ERP. And one of the things that we set out right from the get go was that we were not gonna try to reproduce ERP functionality. We did not wanna bring people out of the ERP and into the inter-company system to do things that belonged in the ERP. So to your question about getting the errors right, there are other programs that we have. I don't have time to get into them now, but there are other things that we do at the ERP level to try and improve data entry errors, but that is definitely something that we felt needed to stay at the point of entry, which was in the ERP system. So I think that's it for Q and A. I'm two minutes over, so I'm gonna go ahead and wrap. Thank you so much for spending time and hearing about what we did. I was very proud of it. I think it was a really good step towards moving us into using, getting some more skin in the game with Hyperledger and with Distributed Ledger Technology. And again, if you wanna reach out, I also have a link there to my blog post which dives in deep to how a lot of this stuff was done in terms of setting up the network, setting up the data warehouse and setting up the analytics. So feel free to take a look if you'd like. And thank you again. Have a great day.