I'm David Newman and I'm going to share this presentation with Dennis and we're going to give you sort of a FIBO 101 to get you introduced to FIBO and what it is, where it's going. So some of the topics I'm going to cover is what is FIBO, how does it use semantic technology, why is it important to your firm and to regulators, what are some of the significant ways that FIBO can be applied now, how can FIBO be applied in the future and then the process behind FIBO, what is that, what is the methodology, how are we going to grow and evolve FIBO into the kind of broad capability to reflect the entire financial industry. And so if you ask, you know, is FIBO boiling the ocean, the answer is it absolutely is, but as Sherry said it takes a village, well it takes a whole industry to create a FIBO and that's what we're all about. So Elaine talked also about BCBS 239 as being one of the major drivers for FIBO from the regulatory point of view where we learned from bitter experience that financial organizations couldn't actually identify the risks of their own portfolios and global regulators couldn't tell the risks of the overall financial system and so there was a demand to create a common language in the industry. So besides fulfilling BCBS 239 if we take a look at many of our major processes, in this case loan origination and securitization which I picked because that ties back to the global financial crisis, not only did we discover that data was highly opaque within organizations and across the industry, but standards themselves are in many ways highly siloed and highly opaque because processes cut across horizontally many, many different standards. So we have the MISMO standard which covers borrowers and loan originators and loan investors and part of the securitization process and then going beyond that into many other phases of securitization there is no one single common standard. So the intent of FIBO is to come up with a standard that will tie together all of the other standards. So the enterprise data management council which has as its constituency many of the global financial organizations and regulatory agencies said that well we're very well positioned to lead the charge to come up with this common financial language and we're going to partner with the object management group which is a technology standardization organization and we're also going to put a stake in the ground that the standard that we're going to use to define the common language has to be upwardly compatible with the future 5, 10, 15, 20 years out and so we looked at many different conventional approaches which we discarded and we selected semantic web technology because it is the most expressive capability to define concepts. So FIBO is a system of concepts that are essentially based on the notion of contracts. So as financial instruments are based on contracts and parties to the contract have to be defined and customers are individuals or organizations that are participants with contracts through accounts. We've modeled all of this holistically in FIBO. Again the mother of all concepts in FIBO is the contract, is the agreement. So this is something that you will see throughout FIBO. So some of the organizations that participate in the FIBO effort is a list of many of the major financial organizations across the world as well as many of the key regulatory agencies that are very interested in FIBO because they are beginning to see that there really is no alternative to achieve a common language in the industry. So how does FIBO use semantic technology? Well a little bit about semantic technology. The strength of any information management paradigm is directly related to the level of expressivity of its internal model. So as we look at a linear trajectory from weak semantics up to strong semantics we can also see an evolution of looking at information from strings to a much more animated sense of objects, rich objects that are animated that have relationships with each other with rich forms of expressivity. So as we move up the stack of expressivity from relational models to XML to relational schemas to XML schemas we come to the semantic web language stack. And then even beyond that we see certain indications of other next generation semantic technologies that are even more expressive and that we're moving up this stack of expressivity. Something like the evolution of the nervous system. So we want to have that most advanced capability. So semantic technology defines concepts through the notion of an ontology. So an ontology is a way to express concepts. Take the example of corporate ownership. Now the basic elements of an ontology we can define as subjects, predicates, objects, basic statements that are linguistically aligned with how we think and speak. So a corporation owns another corporation as an example, subject, predicate, object. Now we could weave in additional concepts into the structure which we could call subclasses or sub-properties if you will. So owns greater than 50% voting shares is a kind of owns. We say it's a sub-property of owns. We can also weave in other concepts. We could say that the concept of is majority owned by is the inverse or the polar opposite of owns more than 50% voting shares. If you know one and you know the other is inversely related you could infer the other concept. So we could also insert facts or individuals into an ontology. We could say that global bank is a type of corporation, subject, predicate, object. London bank is a type of corporation. Global bank, a type of corporation, owns more than 50% voting shares of London bank. We can then use the computer to look at the rules of the ontology and draw an inference. London bank is majority owned by global bank. Global bank therefore plays the role of a parent company and London bank therefore plays the role of a subsidiary. So we could use reasoning and inference to infer relationships and conclusions that are not immediately apparent by the fundamental data. So why should FIBO be important to your firm and to regulators? So FIBO essentially will provide an underlying conceptual data scaffolding by which you can also weave in the concepts that are unique to your own organization. So it will provide that backbone of concept that's been validated across the industry so that we can have alignment on common meaning. That is the most important aspect of what an ontology like FIBO can do. It'll also help us to fulfill use cases like BCBS 239, provide a financial Rosetta Stone capability across the enterprise. Because if we have a common model, we could link in and align information that's defined in many different legacy databases that all align on common meaning, we can link that to the common model. We can also use FIBO and semantics as a way to improve regulatory compliance from a regulatory reporting point of view, reduce those MRAs. We can use also the graph of relationships to help us to better manage risk, financial risk, credit risk, market risk. And then lastly, faster time to knowledge is really what this is all about so that we could have knowledge at our fingertips that workers at an organization can get answers to their business questions immediately. Customers can have immediate answers to the information they're seeking. So a few more things on how can FIBO be applied right now. So if we look at conventional glossaries that you would find in a business enterprise glossary, we can look at this as two-dimensional. We have a label or a term and a definition. If we're lucky, we can actually have a taxonomy that's somewhat operational. So that's basically two-dimensional data. Fast forward to FIBO, semantics, and the reality of information is that it's multi-dimensional. Concepts are linked into other concepts which are linked into other concepts. What you see here is a screenshot of smart logic semaphore, which has taken in what we're calling the FIBO vocabulary, which is an extraction of our core FIBO RDF owl-based semantic model. And it's converted automatically into a form that we could drop into many vendor products like smart logic semaphore like Calibra, Abinicio, and others in order to begin to see this multi-dimensional view of concepts. As I said a little earlier, it could also provide a conceptual scaffolding for companies to extend their own information models. So with the elementary structure of FIBO, we could extend that. For example, with Wells Fargo, we would have a Wells Fargo business ontology that reuses FIBO, it imports FIBO, it reuses FIBO, and will extend FIBO with Wells Fargo's unique business definitions with its own unique DNA to create an enterprise model. And then you could extend your enterprise models with line of business models that will reuse the enterprise concepts that reuse the industry level concepts. And so you can have concepts like the definition of customer that may vary at differing levels managed and governed in one common, broadly multi-dimensional linked model. So this is also how we could begin to support a Rosetta Stone capability. So the notion that global bank owns more than 50% voting shares of London bank is unstructured information, but it means something very understandable and very similar to what we have in this example from Excel, which is very similar to this example that we show with a relational database and so on and so forth with XML or big data. We can use semantic mapping capabilities to link to this common model that we looked at a little earlier, the notion of corporate ownership. It's all the same concept from a business point of view, even though the legacy data is defined in very disparate ways. Another very major important innovation of semantics in FIBO is the ability to unify data at rest with data in motion so that we don't have this Tower of Babel syndrome that we have today. So here is an example of a derivative, an interest rate swap trade confirmation called FPML, it's an XML dialect. We can represent this XML payload in FIBO using a protocol called JSON-LD and the terminology that's in the payload is the exact same terminology that's in FIBO. It's the exact same terminology that FIBO describes a particular interest rate swap contract. So the terminology of the data in the model equals the exact terminology and meaning of the data at rest equals the exact same terminology of the data in motion. This is a big, big thing and will make a significant innovation to reducing the reconciliation hell that we take for granted today in the sense where the proverbial frog in the boiling pot, it is a pain point that we can fix and we can change. So a few more things, how can FIBO be applied in the future? So one area that we're actually working on right now is to take the meaning of concepts in FIBO and be able to represent this as semantic markup on the web. So there's an organization called schema.org. It's basically formed by the search engines, Google, Yahoo and Bing and Yandex and a few others. The goal is to take the common language of the financial industry and make it available for publicly facing websites to take the models that are in FIBO and allow this to be embedded in web pages where a machine can be able to consume the content on a web page and understand it. So Google, for example, is capturing information that's marked up semantically on web pages updating its knowledge graph so that when people enter a text string into the Google query box, they're able to get answers where we'll be able to go with this using FIBO's initiative, which we'll hear about later in another presentation, will be, for example, find the lowest 30-year home mortgage rate that ultimately I may qualify for. So it's going to open up a lot of opportunity for digital agents to be able to understand what people understand today on the web so that we'll be able to delegate so many more activities to digital agents, like applying for loans and others. The notion of blockchain, that's a massive new innovation in the field today. However, a big gap with blockchain is that there are no standards. So this is an area where we believe that FIBO can also make a tremendous impact positively by providing standards for smart contracts. Smart contracts you'll hear more about in a blockchain presentation tomorrow will allow the capability of having this notion of a distributed ledger, which you'll hear much more about tomorrow, where we can perform transactions and eliminating a lot of intermediaries today so that we could perform settlements in seconds rather than in days. So in this example where we have an interest rate swap, this can be rendered over a blockchain. And if we use a standard like FIBO, we'll be able to fulfill regulatory requirements and we'll also be able to better understand the content that's going to be expressed or anchored in the blockchain in the exact same standardized way that I've described. So we basically can leverage FIBO for helping us to make sense of information in a decentralized world, and FIBO is the answer. So let me turn this over now to Dennis to tell you actually how are we going to do this? What is the FIBO methodology? What is our rollout strategy? In addition to hats, we have an outstanding program. I think you agree, those of you who have been reading what it is, without standing speakers you've seen three of them already. And basically all the things that David talked about, there's a talk that's coming up about that. My part of this is the methodology we've been developing for the last three years since I've been part of FIBO. I began my quest with this many web technology as a Chief Technology Officer for DoD, which had exactly, that I did for five years, for business, which had exactly the same problem that the financial industry has, and that little number at the bottom right-hand corner of the spreadsheet had to be zero by putting some fudge factor in, and that wasn't the way to go. So FIBO began in 2008, Mike Bennett back there started to do FIBO along with Mike Atkin, and then David Newman came along, and I began in 2012 after I left the department. So my job has been to figure out how to deliver these FIBOs. Began in 2012, 2012, in fleshing out the FIBOs, in taking what was a business exceptional model in UML, and beginning to do FIBO in RDF-L, and it went a big way, and that's still going on. In fact, the FIBO V that David talked about, the camera, I'll mention it again in a few moments, that is a SCOS version of FIBO, which is RDFS. So it's taxonomy. It's not a true ontology, the way that we look at it, but even better than that is we can then go from an RDF-L model to a natural language listing that's like a business index that you'll be seeing. So 2013, we moved into being able to scale FIBO, which is our goal we have to achieve. So we developed a build, test, deploy, maintain methodology, much like we build airplanes in DoD, that same kind of a concept that build it, test it, deploy it, see what's wrong with it quickly, and then figure out a way to keep it going. So it's RDF-L plus ODM-based UML, that's adopted as our system of records. Everything is based upon RDF-L. So Spiral Development, I have an outstanding team, in fact, I'm gonna introduce my team to you, and I really love it when someone does something better than I could have thought about it. This was Bob and T-Garden. Bob and stand up, where are you? Not in the room? There she is, okay. So Bob and T-Garden developed this slide, which shows how we build, test, deploy, maintain. When I was in the architects of business, I would always be asked, when will your architecture be done? Never, because the business is always evolving, and this is also true with FIBO. There are 35-Bode domains, and these domains, and they're subdomains, within that there's 30 domains. You've heard about a few of them from the speakers already this morning. They change over time, and so there's a lot of interaction. So the circle goes around and around and around. We have a continuous integration spiral methodology built on the kind of technologies that you probably all use, which is GitHub for the repository, and Jenkins to test FIBO as the domains are evolving, and then Jira to manage issues, and last in confluence to enable us to do wikis. So there are about 150 people right now who have access to GitHub. Those are the true FIBO geeks, and there are about 500 who have access to the continuous process that you are using or using our wiki. So we have teams. The key team is the leadership team of FIBO, which is myself, David Newman, Mike Bennett, Mike Atkin, Mike Mariton, those are the EDM Council staff, and everyone who is ahead of one of our other teams, so our FIBO content teams, those are the people who are taking one of these domains, let's say derivatives or loans, that's Lynn Callaghan who's gonna be talking along with Mike Gushold later on this afternoon, in fact, right after lunch. This is a very simple 25 page document, and it is available on the EDM Council website, and it is what guides our delivery of all of our content with the FIBO content teams, and also proof of concepts. You're gonna hear proof of concept talk tomorrow, State Street is doing rather has done that work, so there'll be people from State Street. Is Mike Levansky here? Okay, so Mike is from Dunn and Bradstreet. So all of these teams, I think you're starting to get the idea. This is a village that's worldwide doing FIBO, it's not me, certainly it's not me, it's not me and David, not me and David and Mike Bennett, it's everybody working together, figuring out all aspects of how we're doing this together and going forward. So 2016, this is a breakout year for us. We've done the release of language and country codes, that's the LCC thing, finance and business concepts, the FBC, Indies and Indicators, Byzantines, those are OMG specs. What's already in testing now is loan, securities and derivatives, sorry, securities and equities and derivatives, and then the POCOC is the phase one derivatives that was done by Dunn and Bradstreet, State Street and Cambridge Semantics, who's also here. Cambridge Semantics, someone here from there? Yeah, back there in the back. So part of the team. 2016, we're introducing what we call four FIBO flavors. We have FIBO colors and the colors are ways of helping us keep straight the status of a FIBO. A red FIBO is a FIBO that has had not much work done on it in the last year or so. A pink FIBO is a FIBO that's in the testing process. The yellow FIBO is FIBO that's been documented and a green FIBO is one that is a OMG ratified spec. So the colors I think make sense, red, pink, yellow, green. And if you look at those colors, you can tell exactly the degree of confidence you should have in what they are. But better than that, we've had people who want to get into FIBO today. So we started an early adopter program. We hope we call it FIBO V. And that's the RDF, that's the RDFS, which is SCOS. And David mentioned FIBO.SKIMA.ORG. You'll be hearing a talk about that today as well. And FIBO Natural Language, which many vendors can already do, just ingest the RDF out and produce the English. So earlier adopter program, I'm gonna show you a picture of what that is. That's initially started by Wells Fargo, by Deutsche Bank and by Bank of New York Mellon. And there'll be two more banks added probably by the end of April. So they're taking the FIBO now and forming a super FIBO content team, if you would, focused on debt and equity bonds. And they'll be fleshing out all of the FIBOs. So the FIBO that's released in September will be some subset of all 30 of these domains. So a different departure from what we've done before. So we're on a at least quarterly release schedule going forward through 2016 and beyond. We're retiring the red FIBOs because red FIBOs are conceptual models that have been sitting, we're taking them all out now, focusing on debt and equities. And now we're calling that the baby pink. It kind of looks purple on that chart. So what happens is that the content teams take the content out of anywhere in the baby pink and they decide that they want to focus on either the system of record, all that stuff that's in the pink pink that's showing there. And they want to publish the RDFL and the FIBO in an involving OMG standard called the Semantic Integration Model for Federation. Hope I got that right. Or they want to align with fabadaskiman.org so the team that's doing that or they want to generate natural language or they want to generate SCOS. So you see the feedback loops in here and that's really the important part and that's where the tooling comes in. How do we understand what each of the teams is saying to us? But here's a model that I'll leave up there for a little while and let you kind of study it. So you see all the colors that are in there, that old ancient drum looking thing. That has the two repositories that are all both in GitHub. One of them is the baby pink. Those are all the FIBOs that are raw material, huge amount of data. And then you see the pink, the yellow and the green. If you don't know what that means, it means not tested or being tested. It means able to be released. That's the pink. And it means documented and it means OMG standard. So I use the word and advisedly because it means all of those things. So what we've had in the past is that left-hand side. The FIBO leadership team, the FIBO content teams, the FIBO vendor team, the FIBO process teams all working together to listen to what our constituency, us has been saying to ourselves and then having an automated process using Jenkins to tell us whether or not these FIBOs behave internally like using the inference engine that David said. And what happens if you put two of the domains together? So we've had that left side. We had in this picture last year the vendor part of this at the bottom, but haven't had much traction because we haven't had much for them to do. But tomorrow there's an entire vendor track here. In fact, it's two sessions. So all the vendors that are speaking are now stepping up to the plate. Many of them are joining EDM Council to be able to do with their tools what we've been doing with only a couple of tools so far. Look at the right side. What's going to happen is that we're going to publish and this will begin in September. We're going to publish not exactly in the wild like some of our members would have it, but we're gonna be publishing FIBO on the right-hand side with all the documentation that you would see if you were publishing software. This has been changed, that's been deprecated, this has been added, those kinds of things. So a FIBO with release notes. So some subset of all 30 of the domains will be published and then the fund will start because instead of having just a dozen or so people telling us what's wrong and we like to hear feedback even if we don't like what the feedback is we have to have it.  So much like any open source project would work except this is data and this is vocabulary the banks have to depend upon. So that means an extensive amount of testing has to happen. And so that right side over there goes back and follows the very same path that we've been following here with our close team and it'll be much more input. Our intention is to use the same JIRA and the same Confluence Wiki that both of which are open to be a real, to have access to the real GitHub. We're requiring people be EDM council members but to have access to what's been published that's gonna be on an EDM website called spec.edm.org and then whatever the status of the particular ontologies are. So this is a big change for us. We have to learn how to do it. All of this is a learning process and you can see our two little owl people up there. One of those owl persons is an ontologist and on the other side are the subject matter experts or the taxonomous. These teams are required to be organized like that. And that's why we have our in-house ontologist Mike and Lisa and Dean and then other people who are the teams who some of whom are also quite advanced in understanding how ontologists work and then of course subject matter experts who provide the data, who provide the understanding of what the data really means. So we have our early adopter program for this year. If you follow those numbers there, those numbers are to do how we operate, extract from the red, which is what's happening now, into that baby pink that's over there on the right side and then look at all the colors on the left side. That's through our material that the Fibro content team for the early adopters have to work with and then they'll be fitting into the right side of that standard Fibro process. So we're treating them as users. And this is a small prototype team compared to how many people will eventually be using Fibro over the next six months. And they'll be in that standard process so that in September, our intention is to have a, who most like to call it Fibro world. David and I like that term in Manhattan, New York City. That's where most of the financial industry is. And at that time we expect to be rolling out Fibro V. But remember that Fibro V is a SCOS version of Fibro RDFL plus UML. So it's a SCOS version of the system of record. Always when there's a change, and you should have seen that in that other drum picture that I showed, all changes go back to the RDFL. So even if someone has a brilliant idea, they wanna change the SCOS. Nope, you go back and change the RDFL, generate the SCOS. That's how we'll keep all of this straight. The back of these wonderful hats say unambiguous shared meaning. And it has to be unambiguous across all of those flavors. The system of record, the Fibro V, the schema.org and the vocabulary.


Helo, mae gennym yn ddod i'r hollu'r seisio'r dystod. Mae'n hollwch yn ei gyd ddod a'r hollu eu hun byddio'r cymhau a ydych chi'n gweithio'r gwahod. Dwi'n enghraiffti'r gwahodd. Dwi'n gweithio gweithio'n gwahanol am y sanddfaen ac yn ymddangosol. Rwy'n gweithio'n cydweithio'n gweithio'r gwahodd ar y gymuned ar y university. Mae'n gweithio'n gweithio'n gweithio'r team digital ac y moddol maen nhw'n ddysgu ac yn ysgrifennu yn gweithio. Felly, ydych chi'n gweithio'n gweithio'n gweithio'n gweithio'n gweithio'n Gweithio Kevin Brace a Angus Macdonald. Thank you. My name is Angus Macdonald. This is Kevin Brace. We are both learning technologists with the digital learning team at Arden University. And yes, we are going to talk today about module maintenance. We are going to talk briefly about Arden University, the growth in module production and the development of this project. We are going to talk about the processes, lessons learned and how we refine these processes over the last few months. So we will talk about future developments and progression and reflect on how successful we believe the project has been so far. So a brief introduction to Arden University. Beginning as a producer of distance education courses, Arden was awarded university status in 2015. It has since expanded and grown and we currently have approximately 20,000 students working on online and blended learning courses, both undergraduate and postgraduate. Over the last year, Arden has continued to grow dramatically with 130 new modules developed, 183 modules refreshed and 18 new programmes. When Arden began, I think there was maybe three or four people developing all of the courses. And as you can see over the last year, you can see the digital learning team has grown considerably with over 30 members of staff. And we are all committed to further development and continual CPD. And you can see over the last 12 months, including Seamold. Over the last few years, with the expansion of student numbers, the size of the digital learning team and the amount of new courses being developed, it obviously becomes necessary to take stock, assess and perform some high-level auditing and housekeeping. This has led to the development of the module maintenance project. Running across the entire university with a collaboration of all heads of schools and several departments including quality and library services. The maintenance project has been divided into four specific pathways. The first is refresh, and this deals with small but urgent issues that need fixing quickly, such as changes in laws or policies, amendments to diagrams or images, typos and corrections to content, and updates to links, those kinds of things. Those kinds of things that hamper a student's day-to-day learning. SMEs can raise a ticket for one lesson at a time, multiple issues but one lesson at a time. And this is triage to a specific team, depending on what the issue is. This part of the process is similar to a help desk scenario, fixing issues as quickly and efficiently as possible. The second pathway is review. This is for more significant changes that need a longer period of time to implement. There are three fixed windows throughout the year that SMEs can submit their modules. The third one is renew, and this involves far more changes and significant rewriting of modules, which will require the modules going through revalidation. And the final pathway is retire, which is archiving modules that are no longer running. Currently we have only put the first two processes into place. Refresh has been running for almost a year now and is something we deal with on a daily basis. Review has been running since the beginning of the year in specific blocks of time, and involves a more elaborate process with more extensive communication and collaboration between the digital learning team and the SMEs. To support academics in completing these maintenance tasks, we've created a SharePoint site to promote the service and provide as much information to staff with links to all resources they need. We've created interactive staff guidance on the different stages of maintenance, including our branching activity, which staff can follow to help them decide which other pathways they need to go down. We've created a how-to video guide on how to complete the Refresh Maintenance Forum, and using Power Automate to this forum pulls through the information and produces a specific ticket.  There's also access to the JISC survey forum for the review process, which heads of schools are required to complete in far more detail, and heads of schools and module leaders have to carefully review and select which modules and lessons they want to nominate for the process and provide us with very specific details about the amendments required. Sometimes a review request will have amendments that are minor enough to fall under the Refresh process, and they will be asked to follow that route instead. Sometimes this can happen vice versa. We've received tickets for Refresh that require extensive changes across an entire module, and we will propose that they go for a review instead. Over to Kevin. Leading from the last slide, we have a Microsoft form. We're talking about the Refresh process now, so these are small but significant changes we handle on a daily basis and triage off to teams. You saw on the previous slide, we've got a Microsoft form embedded within SharePoint, and it's really quite a detailed form which guides the staff, guides the academic staff and the subject meta experts down the route into deciding what sort of content change they want to make and what changes it might be. A reading list, it might be a typo, it might be printable materials, for example. That form is embedded within SharePoint. They fill out the form, and then through Microsoft Power Animate, Automate, sorry, that gets pushed into Kyoko. That was our original process. Kyoko was a ticketing system that we used up until the spring of this year, so that was a very simple shared inbox system that we used. We received an email from the Microsoft form with the full details of the form within the body of the email. This is a shared inbox, essentially, with multiple teams across Arden, and we knew that we could do better because we had simple notes in there, but it was very clunky, and we wanted to make it much more intuitive and be able to control the process much better. In addition to the Kyoko system that we had, the ticketing system that we had, alongside that we ran a spreadsheet, and that monitored the tickets that we had coming in, so we mapped and logged all the tickets coming in for the time that we got them, the time they were open to the time they were closed, what particular team, whether it's multimedia or learning design maintenance team, we're working on it, or whether it's a library team fixing ebook links. We had very detailed information on that spreadsheet, so that ran in conjunction with Kyoko. In the spring of this year, we decided we wanted to do much better than that, and we decided to move over to a new system. The system that we chose, and it seemed to be quite obvious because everybody was involved in using Teams anyway, was Microsoft Planner, and using Power Automate, as well as the Microsoft form that we saw earlier on. We already had the Microsoft form, which was very, very detailed, so there was a consistent move from Kyoko ticketing system to this Microsoft Planner system. Rather than just take the information out of the Microsoft form and put it directly into the description area, what Power Automate did was to take various aspects of the form and create labels and details within each task. Essentially, we're using an individual task in Microsoft Planner as a ticket. When somebody submits the form, when an academic submits the form for these small refresh changes, it will take aspects of the information they've put in the form and create labels, it will put dates on it, so we've got service level agreements put in there as well. We've got information in terms of what type of content, what change it is, whether it's content or ebooks or library information or a video. We've got quite a lot of detailed information within the ticket. We've got a number of buckets there. There's a new request received bucket on the left-hand side. That's where we carry out our initial triage process. We'll check the ticket and see if we've got enough information to then process the ticket on. Essentially, if we haven't, then we'll get back to the academic information, but what we'll do at that point is just check the ticket, check the details, and if it's okay, then it's usually a sign option within Planner to assign it to a particular team and then move it along a bucket to in process. We've only got about four or five buckets in there, and it goes along the process like a normal Kanban board when one team's working on it, they'll assign it back to us and say, well, I've finished my job. It might be, for example, the library team would have fixed a link within an HTML module or a rise module, and then it'll be passed over to the product developer who has to confirm this or rebuild the HTML module. We have multiple teams working on the same ticket in some instances, and it does work very well. People are able to check the status of the tickets and they can access the tickets and they can work with them very efficiently and effectively. In addition to that, more recently, we've got a Power BI developer, and what he's done is create a reporting dashboard, which is the image at the bottom of the screen. That extracts data from the Kanban board and formats it in that reporting dashboard format where we can basically filter it to a particular week, a month, and we can click on each one of those windows and drill down to get more information on the status of a bucket, how many tickets in that bucket or the status of tickets through the system and if there are any blockers and how many closed tickets. We're essentially trying to use that reporting dashboard to replace the spreadsheet that we're still using to a degree, so we feel that we probably might have them running in tandem. Finally, on that particular page, the Microsoft Team site, this is all built within a Team site. First of all, we built a Team site, so we set up a refresh maintenance channel, added the board to it, and we're also using the communication aspects within the channel as well. It's all really self-contained within Microsoft Teams. In terms of future plans, these are current plans as well. We've got super user group meetings that we hold monthly now. We used to hold them more frequently, but we've decided recently that we only need to hold them monthly. So we're resolving a lot more issues and things within the actual system itself. So that's working, so we don't need to have these two weekly meetings every couple of weeks now. So it's every month that's working well. We're getting resolving issues, important issues if they can't be resolved via communication, via Teams. We are also designing and delivering school roadshows, so that's just to bring more attention to these refresh and review processes that we're working on. So that's happening as we speak, and we're going into individual schools and walking them through the process and explaining the difference between refresh and review in more detail. And this refresh board has been so, the Kanban Board and Teams and Power Automate and Power BI have been so successful that we are going to use them for our review process. So the review maintenance process is three times a year. People will submit an entire module with multiple lesson changes. So we're going to be using that Kanban Board to control and monitor that process. And in respect of currently it's an internal team, but we are going to be adding academics temporarily into the Microsoft Teams so they can have control or they can see where the tickets are and where the lessons they're working on are. So that's the new development we are. We've only had a meeting just this week to finalise that process. So in terms of what the reflection on this is we have a centralized process now which everybody's buying into. We've got a whole lot of materials on SharePoint which we're constantly updating and keeping fresh and looking at those and getting feedback from people because we've got comments in SharePoint. We are having... We've got high visibility of all the tickets within the teams. So this is what the feedback that we're getting from the multiple teams. So we've got learning designers, we've got multimedia, we've got library people. And the feedback that we're getting is that we're using this Kanban board type of system as a ticketing system. We are... Everybody is very intuitive process and much better than the Kayako system we had previously which was the whole point. It's self-contained within Microsoft Teams. We're using the communication channels much more so we've essentially eliminated most if not 99% of all emails and and it's very positive that the feedback we're getting from people from the multiple teams using Kanban boards and using Teams. And I think that's us. Thank you. Any questions? Thank you. Yes, thank you very much. I did have a microphone last time, didn't I? But it was a bit of a last-minute change to the chairs. So I'm just jumping in. But yes, thank you. Thank you for your presentation. It's really interesting to see and I know that there's been an awful lot of hard work that's gone into what you're doing. I know that it's a 15-minute slot and I'm sure that this could have gone on for quite a lot longer and I know that we could have talked a lot longer. I'm sure if people have got questions you'd be happy for people to get in touch with you. And obviously details are up on the screen I think but I think Vvox is up at the moment. If people are around and they do want to put anything into Vvox feel free if you are happy to stay a couple of minutes later but obviously don't feel that you have to. But I think for now as it's quarter past five and for everyone that's here we're going to go off to the gala shortly and listen to lots of 90s music and for those of you that have joined us online thank you for joining us. Make sure you have a good time tonight as well if you have photos on Discord even if you're at home get those up on Discord as well. So just one more round of applause to Kevin and Angus as well. Thank you very much. Thanks everyone.