 I'm Jeffrey DeSmit, the lead of the Business Resource Planner and the Opto Planner project. About 10 years ago, I had the idea of combining the Drulz rule engine with the local search algorithm to solve optimization problems. I worked on that for several years as a hobby and then I got hired by Redhead and now I'm working on it with a team. Business Resource Planner is a planning engine. It solves planning problems such as nurse rostering or any kind of employee rostering, vehicle routing and cloud optimization, for example. The world is full of planning problems such as, for example, shift rostering. In shift rostering, we have to assign, for example, nurses to shift in, for example, a hospital. And we have a number of constraints. For example, an employee can only work one shift per day. Another constraint is, for example, that we want to make sure that every employee has enough sleep. For example, when an employee gets a late shift, the next day we don't want to give that employee an early shift because that employee would only have eight hours to go home and get some sleep, which is far too little. Today, when we take a look at the software that solves these problems or the human planners that do that, they actually do that relatively suboptimal. We've actually shown that we can actually improve that and basically get better schedules. Business Resource Planner can also deal with vehicle routing problems. So, for example, a company that has a number of stores across the country needs to deliver a number of items to these stores every morning to restock them. And to do that, it sends out vehicles, trucks with items to deliver at these stores. We can actually optimize that and basically deliver the same number of items in less time and with less fuel. This is both good for the environment but also very good for the profitability of the company, of course. Business Resource Planner is also a great fit with the workflow solution. In the workflow solution, we have to assign tasks to users. And to be able to do that, we need to make sure that every user has the necessary skills to fulfill the tasks he's assigned. This is hard constraint. That means that we have to do this. On top of that, we also have soft constraints. Each user, each employee, has certain affinities with certain customers. If we can actually maximize the affinity between the tasks and the users, the users can actually complete their tasks faster. Again, this saves time for the company, which is good for the overall profitability of the company. And it can also improve the customer satisfaction because there is an affinity between the customer and the user. Business Resource Planner fits very nicely in an existing Java stack. We can reuse your existing Java classes and use that as the model for your constraints. This means that you can leverage the power of Java, such as polymorphism, object-oriented design, and just plain old existing Java methods in our constraint satisfaction solver. And this is very unique in the market. Unlike other vendors where you have to rewrite your constraints as mathematical equations, in Business Resource Planner you can write them as score rules or even plain old Java, and you can reuse existing Java methods. Because we use plain old Java objects, this means you can integrate them easily with a database, for example with Hibernate, or you can easily integrate them to serialize to XML with X3, more JXB, or any technologies like that. One of the things I'm very proud of from a developer's perspective is that if you use Opto Planner and you do the wrong thing, you configure something that isn't illogical, Opto Planner will fail fast with a very nice error message immediately. This allows you to easily see what's wrong, fix that, and figure it out way before it ever hits production. One of the great features of Business Resource Planner is we can respond on real-time events. We can respond on that in two ways. We support continuous planning, where we have a sliding planning window, and we also have real-time planning where when the problem changes, we can actually react in milliseconds without restarting from scratch.