The Live Series Podcast
Dynamics 365 Business Central vs Dynamics 365 Finance and Operations | Roundtable
Frankie is joined by four engineering experts to battle between Dynamics 365 Business Central vs Dynamics 365 Finance and Operations.
Our guests are:
Renato Fajdiga - Business Central MVP & the Head of Business Applications of Happening
He started his ERP career as an NAV Developer, and has since worked extensively with both Business Central & Finance & Operations.
Zeljko Hajdinjak - Head of ERP at MisterSpex, a global online Opticians.
He has been working with Microsoft ERPs for around 20 years.
Stefaan de Prest – Head of Business Applications at ConXioN.
Stefaan has been working with D365 AX for 17 years, and has recently gained experience delivering both F&O & Business Central for his customers.
Steen Rabol – Freelance AX Developer
Steen has consistently worked with AX for over 25 years, starting out as a consultant in his native Denmark.
- Broadcast on:
- 25 Sep 2024
- Audio Format:
- other
(upbeat music) - Welcome to the September edition of our Dynamics 365 round table. Today, joined by four very exciting guests from across the D365 Business Central and Finance and Operations world. Joined by Renato Fadeja from Happening, joined by Zilgo Haidiniak from Mr. Specs, the sign of the press from connection, and stay in Rabel, a expert F&L freelancer. Guys, if you can all go around the room and introduce yourself in a few lines, that'd be really appreciated. Renato, we'll dive in with you. - Okay, thank you. Thank you for having me in this round table. My name is Renato. I'm a leading business application division in a company called Happening. Happening is an IT and tech hub for one of the biggest Romanian and European betting software. So here in Happening, we are implementing finance and operations and business central, so we have both tools. And we are mostly implementing in-house and then rolling out to different countries and based on our business needs. Together with that, I am also responsible for SAP success factors and other tools that are not part of today's discussion. And yes, I'm Microsoft MVP for business central and maybe we'll see it today that I'm more on the business central side. And yeah, my career started as an NAV developer, then moved to VC and then later on to F&Ls. - Good, thank you. - Thank you very much. - Thank you. - Thank you. - Thank you. Yeah, I'm Jelko. So I started to work with ERP many, many years ago, Microsoft's ERP when ERP was usually the biggest system in the company and people didn't have a deal with cloud, it means. And then during the year, taking part of transformation of ERP, one side from companies when ERP is still taking, you know, the biggest part until companies like company, whatever today with specs where ERP is maybe just one app between many, many other apps. And then you are creating architecture, which you need, no. And considering, of course, Microsoft ERP's but some other ERP's and looking forward to be today here. - Yes, my turn. So Stefan, the press, I've been in, I just calculated it. I've been in the Microsoft ERP for 17 years now, which was a bit of a surprise. Started as an accountant, then I actually became a functional consultant, working with AX, AX3.0. Then went to freelancing, started my own company in 2019 and my company, we also started as implementing Business Central. So since 2019, also Business Central. And now I'm part of, I saw the company two connection last summer. So connection is a bigger Microsoft partner, which offers basically the full stack of Microsoft M365, everything included in the Microsoft licenses, but also now Business Central and FNO altogether. So, and next to that, of course, the power platform, the SharePoint, everything basically. And within connection, I'm now leading the bit same as Renato, the business application team, to basically the Microsoft software, all everything, basically. That's my job today. But thank you for the invitation, David. I wanna say that. Let's hope we get a lot of views. It's all, it's all. - Stay and see you. - Yeah, thank you. Thanks for having me here. So my name is Steve and I'm from Denmark, the birthplace of D65. I started with accept a 0.99 way back when in 1999. I remember the first installation we did was, we picked up the Golden CD at the Danghar data in Gigaworld in Denmark. And then we went to the customer. And from there, I have been working in the US, in Europe, as a developer, solution architect. I worked at Microsoft for some years as a solution architect in the retail space. And now I have my own little company doing freelancing more or less at the moment in the Nordic region. And I don't think I could find a better ERP than D65. - Well, I suppose we'll have to see about it in this conversation. Not too sure we'll sway 25 years of opinion, but who knows? Renata and Gjelko may be very, very persuasive. I suppose if we just start the conversation, if we could just open it up to the table and say, what are the sort of core differences between business central and ethanol for all that viewers? - I think it's a way that you develop the application and do customization, that's the most different parts. I think end of the day, they could solve more or less the same tasks, except for as far as I know, businesses and do not have production and planning and so on. - So it has manufacturing model and so we are also on that side, manufacturing, but also what I would add, it's a bigger big difference is the licensing. I mean, if you start from the beginning, when you want to sell some license, you will find yourself in different F and O. - The configuration and all the license and not maybe even know that you are using some type of license versus business central having it much more simple. You have a central premium team member and that's it. - Well, the thing is we definitely need to start with, you need at least 20 licenses. So the cost price of that is already a big difference in relation to business central where you can just start with one license. - Well, I think if I compare it to functionality wise, so yes, there is production, of course, and there is also a little bit of planning, a little bit of MRP. So functionality is a big difference. What I always compare is intercompany capabilities. That's one thing. I think intercompany capabilities in F and O are more out of the box because F and O is running on one data base. It's one different legal entities in one database. Well, if you have multiple countries inside, multiple localizations, well, business central has different databases. So that's a bit more a challenge in that aspect. I think that's one of the bigger things. And next, if I can continue, I mean, business central runs, if I, maybe I'm not using the correct words, what I'm calling a public cloud, of course, but in Microsoft, but you have no say in performance or any settings of that cloud. Well, in F and O, you basically give your estimations of consumptions to Microsoft and you can define your capabilities of your Azure along the way. I think that's, that may be a big difference. - That is maybe one more aspect, depends whom you ask, what's the difference now. Many customers, they are saying, you know, if you are SME, like small, medium, then for you, it's business central. And then you have enterprise level, like some other ERPs, you have F and O. And then it's a lot of about scalability, no? And if you are company who needs really big scale, and you would like maybe to focus on your business and not maybe take care about scalability on your own, then what customers are saying, okay, is it's I'm then, I'm candidate for F and O. No, and there it's one more, let's say maybe meet what it's in the market present, maybe again between users, no? They're saying, you know, if you have BC, then probably you will get a lot of customizations. You can ask for it. If you are buying F and O, then by default, this is not made for heavily customizations, and you as a company would like buy versus build. Oh, and then you will buy and you would like to use what you have. And then you would like to maybe build what you don't have in the F or you would like to build around because it takes time, no? And what is still feedback if you buy BC, then even even society community, they are more eager to go into customizations and there may be made solution for your needs if this is required. - I'm not sure if F and O cannot be customized. I mean, I have been working with customizations for the last 25 years. So they, of course, Microsoft encourage customers to stay on standard as much as possible. But I, in all my years in this ERP world, I have never seen a single installation that did not have a single customization. All F and O is implementation has some kind of customization. - So, this is correct, no? And this is, I think, super hard to implement ERP without customizations. Every customer is almost different, but there is still understanding that if you already have so big investment, no? And this is, I would say, when we can talk later about investments, you would like still to get as much as you can out of the box. You would like to have, you know, what you are buying and maybe not mix yourself into your specific requirements. Let's go full of standardization as much as you can. But I agree what you said, of course, you will always have. But it's just feedback that it's, let's say, longer trip to do this in F and O versus VC. It's a understanding what usually customers are saying. Now, if someone would like now to come to you and say, okay, I'm Microsoft partner, I would like to know, you need ERP, let's see what you need, and then you can maybe see two branches. Even this is today, I would say it's getting less and less difference, how they are accessing to customers and how you can shape both products to majority of the customers to you, that it's kind of direction. - Okay, I mean, when we speak about Jacob, you mentioned that small and medium businesses are for VC and enterprises are for F and O. I mean, I would say that here, usually when we say this phrase, and when we see that it's like, okay, I have 100 employees and I don't know, enterprise in, let's say, my region, where I'm coming. But, you know, in US, this is like small and medium. Oh, I mean, this is small or micro-companies. And here, I would say that the biggest challenge that we need to face is like complex of the process. And then this is, this will trigger if you are small or medium or enterprise, because if you have some long processes that are standardized, I would say that this will mean that you are like big enterprise organization, rather than let's say smaller, smaller component that has only in-way seen or something like that. I would say, yeah, good, good, good explanation. It's mostly question about complexity and scalability. You know, if you can fit all your needs with VC, why you would choose something else. No, if you're coming to real enterprise level on any kind of level, which is working worldwide, then you will already think, you know. And usually they're saying that scalability has big price. No, and if you would like to buy scalability on the enterprise level, then you will probably think twice. No, in which directions you're going, but none other you said, no, one of the difference. And I think that one more thing which we was facing a lot as well, and really this is discussions, this is really on the higher level defining strategy. It is time, no? Time to market, and how, when do you see first effects of implementation product E or B, no? And some companies, you know, like they would like to see, they even maybe don't have enough resources after six months. Some of them, they are totally free to go into project with it several years. From financial point of view, but from the time as well. This is pretty specific to customer. What they would like to have. And this is actually for the ERP, this is one good side because people understand more and more that you can't just go to ERP and to say whatever you will buy now, I would like to have in one week. If you are not small organization, if you're not out of the box, you will still need to put their F. The biggest you are, and you would like to cover maybe your core processes or even have even patterns. No, I would like everything have standardized. How much you would like to need to change you all before even going into the direction of implementing ERP. And then starts all game, no? MI for BC, MI for F&O. - But I think that it is equal to both BC and F&O. If the customer wants a lot of customization, you cannot get it very fast. And if the customer is willing to go out of it with out of the box functionality, I think BC and F&O are equally fast to implement. And I cannot speak for development of BC, but I would say that development deployment on BC and F&O, I don't think the time is so different in doing customization, it's more like. - But it's like you say, when they ask me how much time does it take to implement BC and how much time does it take to implement F&O? Then you say for BC, you say average six months a year depending on your processes, F&O one to two years. But what's the difference, not the package, it's the amount of people, the amount of alignments you need to do. So if you take the whole period of an implementation and you look at the different parts of it, then I agree with Steen and saying like you, the real implementing, developing the system, when everything is clear, should take that much more time. - But the proper with when the call, enterprise level is actually the amount of people in the meetings, because as soon as you have more than four or five people in the meeting, it's very difficult to reach a decision. And therefore, implementation takes longer. - Yeah, I mean, I would say that BC, maybe you can implement it in two weeks, three weeks time. If you have good team, you know, you have knowledge, you know, accountants, what they want, you have business, I mean. - You should say F&O. - Yeah, well, it's the same if you compare it's like, what do you need for BC? Are you import some customers, some vendors, some products and basic and a ledger account and you're off? Same with F&O? - That's no difference. - No, so that's not the biggest timeframe. It's indeed more the people and the alignment. And yes, there's more time because why an F&O is just more international, way more cultures, way more different people, it just takes way more time. - And this is probably connected with the company size. No, you really have thousands of the users who need to use, you need to implement in so many parts of the company, even if you would like to be super agile, what you already said, this alignment and everything else, this needs time. And even if some companies would like to combine transformation together with ERP implementation, this is getting even longer. What I just noticing for BC, you have group, again, it's about size. If you have super become, it's getting time to prepare even yourselves, to adopt yourself to book time for old people who can be part of it. But I can agree, no, majority of the development time, development time can be similar and probably all interfaces which you are building again depends how many you need to do, no? Would you do all of them in the Azure or would you do somewhere else? It's a work which needs to be done. - I think I was going to ask about the pros and the cons, but I think we've kind of dove into it really. Some of the conversations that I've had in sort of build up to this have been sort of focused around different pros and cons that come, quite commonly. I think one of you mentioned earlier, Stefan, in terms of sort of intercompany activity, one of the people I spoke to mentioned about, he was interested in learning about intercompany training, and I think one of the people I spoke to mentioned about, in learning about intercompany trading, and then sort of the consolidation of data and the consolidation of the finance and stuff like that, just sort of want to open it up. Is there a noticeable difference when it comes to business central and F&O? - Well, like I said, the intercompany, it's F&O is on one database, so that's easier for automated processes in relation to intercompany. If we talk about different localizations then we see there are different databases, of course. I mean, there's always solutions to solve it. It's just like, okay, what would you do in a BC if you have, let's say, companies in 20 different countries, but you do want to have automated processes. Yeah, you can put EDI in between and just have it automated, problem solved. What do you do with consolidation if you have 30 or 20 different databases? You put a Power BI on top of it, problem solved. I mean, so there's always a solution for every problem. It's just a matter of what's the best one fitting. So when we also have customers that are basically in between the two, they're like, becoming too big is not the word, but they're big, they're growing fast. Do we go for a BC or do we say, okay, we start to implement an F&O, but they're only in two different countries. So what do we do then? They both can fit. Then I'm looking also in their future. What's the plan of the company? What's the plan? For example, to give you an actual example, whatever company has a business central, it has three different countries and they want to sell one of their countries next year or two years. It's easier when it's a separate database. You basically sell your whole database to your buyer, problem solved. If it's an F&O, it's the same database, what you're going to do. There's some challenges there. Is that the biggest decision maker? No, but you have to look into the future. Like, is it the growing company or is it stagnating? Is it going to keep going? Is it the family company that you know is going to last for another 20 years and then the daughter or something's over? You have to take all that into account. That's, yeah, it's an exercise. That's something we do with our prospects, with our customers. We go in, we do the analysis of the processes. We don't think about BC or F&O. We do that at the end and when we have all the complexity, like we have one with a lot of production, heavy production, maybe some difficult warehousing. Yeah, you're going to put the pros and the cons. You're going to be like, OK, in BC, we can also build this, we can extend this. Gonna cost you 20 days to say something, or maybe it's standard in F&O. Which option do you take? You just do the analysis. It sounds like, that's all. Go ahead. Now, it sounds like, for instance, when we talk about complexity, that of course there's a solution to do in BC. I was not aware 100% that they have multiple databases for localization and different countries and different companies. But, and as you say, well, you just put the power of BI and the power apps on top, but again, as soon as you add more components into the landscape, you also add costs, you add the point of failure, and moving parts are, yeah, you never know what's going to happen, so. But, yeah, I agree. As you said before, that at the end of the discussion with the customer, you decide on the product. And I actually, even though that I'm F&O, I totally agree with that. You should find the best tool for the company. And not, I think as Roman also talks about it, it's not about the size, it's about the, what is the best for this company? - Yeah, we have, I mean, we see both, we see, and I think David's mentioned it in the beginning, we see F&O implemented companies going back to business central and the other way around. And why the one is not bigger than the other one, it's just about functionality, complexity, integrations with other systems, yes or no. And that's what we do see. And of course, at some point, also money and licenses, as mentioned before. But we see that movement, and I think still, the day that Microsoft decides to have business central, structurally the same as in F&O, a different legal entities in one database. Yeah, sorry, but then I will not know anymore what to choose. I mean, I mean, it's very close, it's hard to compare. I'm also from origin in F&O, or a Exopt-A-Guy, an F&O-Guy. But it's more out of the box, BC. It's also automatically links without look, like there's nice features, super nice features that are present today in the package, which we don't have in AX. And sometimes I'm like, yeah, why not, you know, like why not AX, in the past, as is the recipe boards and everything. And we see, we do the, I've got the name now, you export it to Word at a DLC. I mean, you can do layout adjustments, you know, like it's just more easier, faster, implements faster, implements faster than the Word, but you can do modifications faster, that's it. But again, then I would say if you comes down to reporting, you know, reporting, so once you put on the form pipe on top of it. Yeah, yeah, yeah, yeah, yeah. I know. Just again, solutions. Exactly, yeah, yeah, no, but that's actually one I see more and more, or doc centric or something. Yeah, because I think we all can agree that working with the report is not the easiest part in the world. Stephen, one question, you now explain how you're working with your customers, no? But do you, and you said that you're covering BC and FNO? And we know, no, I know this well, that in, for example, production, it's for companies who have complex production, I would say BC doesn't fit always. Oh, we know that if you have, let's say, fulfillment or your warehouses, which, and you would like, maybe even to use as VM, a WMS, even your ERP, then in BC, maybe you won't get what you would like to have. And do you have, maybe, there are even some patterns that you are saying, okay, I come into customer and, you know, they are really factory and then we immediately go to FNO, or you always consider both of them. It depends on the situation again. I mean, we have, like, now real-life talking, customers are now working on NAF 2016 and we're thinking, okay, should we bring him to FNO or do we go to business central? But you can do the question with everybody. I think sometimes customers, they may select already something because I think that's the solution, but I think it's the people, the consultants like us that should advise the customer which way to go. But again, with all the criteria, potential criteria, when I go to a production company, yeah, of course, we're gonna go into the details. I'm not looking at the finance in that sense. You know, finance, they both can do the same, you know, finance, you have the regional expectations and sales, they can all sell. I mean, to simplify words, I don't wanna oversimplify it, but of course, if there's production related, that's for me the key takeaway if you go for FNO or BC. It's complexity, it depends on the levels like build on materials and that whole thing. I know from BC, you can also run MRPs and it will also propose your purchases and sub-productions and outsourcing and everything else. It's more simple, it's simple in a sense, it does what it needs to do. It's easy to set up, you run some processes, but you can just with way more criteria work in an FNO, you can add way more criteria to get to that specific result. But again, I think what's the challenge for us is that sometimes customers have, or what they see as very difficult, complex processes, but if you take it back to the bone, you always have to go back to the bone, then at the end, they're all the same basis in. Production is production, now you take two products, you put them together and you have a third one, again, not oversimplifying things, but it's something, yeah, I don't know. It's a hard one. I mean, but I think we still need to guide the customers. But for me, when you say production, complex production, then I'm thinking about a lot of transactions, and then I'm more thinking about an FNO, also in relation to performance. I think that's a big one. Because BC can do its thing, but you know when you stress it too much, you feel it faster than when you do it with an FNO, and as I said in the beginning, in an FNO implementation, you can request certain minimum amount of transactions per minute or whatsoever with Microsoft, so you have a decent setup. So I think you have to look at amount of transactions you process and integrations, and yeah, I think that's one important thing. - Joe, can I imagine your system process is quite a high number of transactions and stuff. There's the stuff you've done to mitigate performance issues, or is that something you had to consider as things that we've done? - I was asking all these questions, because in the companies, let's say, who has a really high number of transactions, no? And where you are considering that you have many other systems, no? And you actually live from transactions. You would like to log everything. You would like to track everything. You would like to have out of the box. Then what you're starting, you're starting building your own solutions around your building microservices. You're using a lot of stuff there. I think there are different reasons you are doing there because of scalability, because of load, maybe because of even you have joy to start completely something new, maybe because you were in kind of a really big company, not big, and then you saw how they are doing and you would like to cope with it. And then you're coming maybe to question, no, that you are building a lot. And what you, Stefan, what you Stefan mentioned, no, that you would like to actually go back to the basis. You as a company, you would like to use product, which you can buy maybe, which it's enough scalable, and you would like to build, not product anymore. You would like to build value for your customers. Maybe shift focus now taking care about performance and taking care about observability 24/7, everything with events with our own resources versus, let's go maybe to something, what it is enough scalable, what we can just, you know, if it's need scale up, scale down, and move this out of our focus. And take care that our customers and providing value to company and to customers with maybe band. And I know what you do with you David, ask, no, a lot of transactions and this is, you're getting performance now. And you can solve them, I don't doubt. And we're solving them and we will solve them. And it's just that you come one moment that you ask yourself, okay, why people are building software for the same by default, even maybe it's not always correct. I'm just for the enterprise level. It's time for the smaller. And maybe you then come into conclusion, okay, what it means scalability, check what other companies are doing, how they're solving scalability. And always you have, okay, people are saying, this is expensive, no, if you need to scale, then you have expensive stuff. And this is what all my questions are coming that especially today, no, where you would like to be fast in providing the value, where you need to be, where you need to change yourself all the time, where to put your focus, no? And when I'm talking with different companies and peers, some of them, they are thinking in this direction. If they have a lot of transactions, they have the same issues, and some of them, they are just maybe, they don't have that kind of need and they don't worry about it. And usually it's going mostly what they're saying. Simplicity, take or make simple as possible as you can. We'll, and then you can scale. Make simple, you will scale easily, no. And just therefore, I'm trying to, and even Microsoft is saying, and differentiate, you know, steal, okay, I have a lot of transactions, a lot of, maybe I think that they have complexity, but you're right, no, many companies don't have, just personal view, maybe already target and what future brings to something bigger. And you maybe sometimes need to go back, you mentioned as well, but on other side, just putting focus on the systems, maybe it's not your product, no? Maybe your focus should be how you can help company. If you are inside of the company or even, even if you are consultant, you're coming to the company, every company will be happy to provide there, you know, not just solving, start to score, providing additional value. And this is what everyone asks. And I see mostly this in this whole electric car industry who's fast to reach, no? And who can, and who can take care about innovation, about bringing something new, better, faster, stronger? And this is what maybe one is not pros and cons, no? Where company would like to put focus, no? You know, have customer, customer needs, no? How do they see themselves in the future? And they are different companies. - I think if you compare, I feel a change in how you implement regardless of which ERP. I see a change in over time in how you implement an ERP with customers. When I started, it was more like, you know, you're a consultant and you work for a partner and the customer comes in, I want to know your ERP, it doesn't matter which one. You go there, you sit down with your customer and you say one question, what do you want? And then they start like talking and talking and it explodes. And you build and you start building and that's where it goes wrong. But that was what I saw in the beginning of my career, the bit of the methodology that was used. But that's what I'm saying now is, and those companies, they grew like this, you know, a lot of them have different packages for this process and that process and all linked and exceptions on top of exceptions. And of course it's difficult, yeah. Of course, it's very complex in that method. And that's where I'm saying that now, how you approach it. And I think that's also a bit more the Microsoft way I've been subtracting from Microsoft as well as we go to a customer and say, look, this is the process, you know, this is how it works. This is a sales process. This is how you deal with it in AX or BC. This is the production process. If you have a internal production or only internal whatsoever, this is the process. Now you tell me where you see that you cannot match this process, yeah. That's a whole different angle, yeah. So the customer needs to tell you why Business Central or AX doesn't fit them. And second, next to this, when they do say, okay, fine, we need some deviation here in the process. What we do is basically we make a change document or whatever you want to call it. But I want to see also what's the return of investment on that change. So I want to see if we need to build something for you and I'm happy to build. But I would like to see that whatever 10 or 20 or 100,000 of euro is going to cost you, what's the return for you as a company? Is it worth it? Is that deviation, mostly something very unique. It's not a general process. Some deviation that we need to build, is it worth it that kind of money? Is it on the long term? Does it bring anything back? And I think that's a different approach with what I see over the years. And also that's what's seen in the beginning also mentioned like Microsoft wants you to go standard. They want to have the automatic updates. So they don't want you to do a lot of changes. And yes, there will be always changes. And we're not talking about extra fields or this or that. We're talking about process changes. Of course they don't want it. And I think that's why I'm taking it back to basics. And you will see that 95% is standard processes. Or it's the 5% that messes up the other 95%. - But if you look at it, as a freelancer, I've been working with different partners over the years. And as you say, they ask the customer, what do you want instead of saying, okay, this is what the system can provide. And we can see now some of the bigger partners that start to struggle because customers are now finding out that we don't need this. But they still need to sell the hours. And then sometimes they say about this system is easier to implement XYZ because of whatever. And then they still get the sale of one system. But at the end of the day, I truly believe that you're right in saying that we need to make it simple. And then try to convince the customer to look at their own processes before they say do customisation. - Yeah. - Do you think, and most definitely, touch on this and you in your 52 topics conversation of a very similar vein, the rise of sort of industry specific is an essential based resources. There's not a bit such a horizon over the air across so many different industries, is that sort of one of the big driving forces behind them? - Well, I think if you go industry specific, do you mean like sector specific, customer specific? Well, the thing is that we ourselves as connection, we don't have any sector specific product or development. I think we start with standard, we show how it works, we define, okay, this is how it works. And then of course, when we do feel that there is some deviation, we first go and check on the marketplaces where we can download simplified solutions from partners and second or third, then and only then if nothing helps, then we're going to develop. But again, it needs to prove some return of investment, I think that's important. Because we all know once we start developing, you need to be a good qualified developer to make it really nice and tight and make sure that no other processes are touched because six months down the line, the customer says, hey, I want something else. And then we say, hey, it's standard and it's messed up because the development wasn't done correctly. And then it starts, of course. So, yeah, that's our approach. We show how it works. Standardly, if it's not, we go into the marketplaces and as third one we develop. And yes, Mike Steen said, I mean, there's always development, there's always. And that's I think also a logic because what Microsoft offers is not sector specific. It's general matching process for as much companies as possible. Of course, there's always deviation. So there's always some development. But yes, I see also more development in FANU than in a PC. But then again, it depends on the complexity of the customers. - But I also think that the regarding the development, when you say that it destroys other functionality, I think it's also a little bit about the consultant and the discussion with the company where sometimes the consultant say, but what do we need this one? No matter what. I have now, I have a discussion more or less on a daily basis with my work saying, do we really need this development? Yeah, but it will simplify this and this. Yes, but if you do like this and this, you have the same result. Oh, okay, okay. But the customer, I think that's, well, I don't know how it is in BC, but I think it's equal that if the consultant does not strongly advise or support the process but bent for the requirement of the customer, then you will have equally number of customizations in both systems. - Yeah, true. For me, I can answer with this simple term. You need a good solution architect. In both systems, it doesn't matter. - And could know a job or consultant that know the processes and how the industry standard process goes? Because company can say, okay, I want to produce shoots like this, but then if the whole standard in F&O and BC is like, okay, I want option B, why not think about changing our process? Maybe it will be more efficient with a new process. And I will also say that it's also a matter of a strategy where the company wants to see itself and how, what they expect from the process as well in the future. Because, for example, if we have 100K transactions per hour or whatever, I mean, they need to be posted immediately or they can be posted during the night and so on. - Customers will always say, I want to be posted right now. - Oh, yeah, but you need to understand why it is right now or how can you? - Yeah, but that's what I mean. That's where you see a shift in the job consultant. It's not just execution. It's more you have to advise and define the solution at the end, but especially advise, it's not just executing. And I refer to a solution architect because he or she is, for me, the key person in a project. He or she needs to define if it's technically possible, feasible, if it's wise or not. And/or work grounds or other solutions. - They are saying that success of implementation depends on how good consultants are because they are this proxy to customer now. And as they are better, then success is probably better. And even, no, this is switch again, then solution architect are now doing more pronged and work together with consultants just to fine tune solution as it leads to both sides. - Do we think that's maybe one of the reasons why historically that the numbers of projects have failed so much because the way the system and built and partners have sort of, like what you mentioned, Stefan, delivered what they wanted as opposed to forcing a conversation in one of the big ones. - Yeah, once you go down that route, you need to have a plan and an end. And that's sometimes the problem, it just keeps going. You keep developing and then more and more and then the budgets are over and then what? I mean, that's what I see in the past and there have been big budgets spent on big projects, yeah. And then you're sometimes asking, but why? Why is it so, why is it so hard? Like, well, again, some companies have difficult and big, big, different, difficult processes. They don't get me wrong. But yeah, once you start developing, you have to be very careful. I mean, and again, we're still be developing again, and again, you have to have the gatekeeper and the solution architect. And mostly, if I talk Microsoft way, they mostly have a functional solution architect and a technical solution architect. And then of course, that is for F&O projects and then it also explains why they're more expensive but at the end, it's necessary. The gatekeepers, making sure that the project can still be delivered and that it's working. Yeah. - There's only one problem with going standard out of the box. That is that we all lose our job. - Yeah. Maybe, who knows? Yeah, I don't know. There's no functionality coming. And yeah, I think it shifts a bit. But you can say that already from like, let's say take BC, when I started BC, I never followed any course. I was like, oh, F&O, I've been doing F&O for so long. I want to start implementing BC in my company. So what do you do at the night? You open Google, you buy one license, there you go. You find so many things on BC, so many things. So even now, the customers could do it themselves. They could just go online, buy a license, go for the flow, but it's about time. It's about advice. It's about, yeah, they don't have that time. That's why they go external. So anyway, I'm not sure, Astin, if it's going to have me short term. That's what they say from Copilot as well, now. Some jobs are going to disappear. Some others are going to come. It's, yeah, I wouldn't be scared. - Oh, no, I'm not so scared either in reality. But basically, if we followed the advice of both SAP, Microsoft, and so on, and Oracle to go out of the box, then we would only have business consultants. There will not be any solution architect anymore. And I don't think it will ever happen. But I absolutely agree that the key function is the solution architect. And I have seen over the last few years that in my opinion, there's a little bit inflation in the title of being a solution architect. I have seen people working with, in my area, FNO for one and a half, two years, and then all of a sudden it's a solution architect. And I think that's at least a smaller partner. They have a tendency to promote people to, for instance, solution architect before they really are ready in order to keep them in the company. And that can also be a little bit of an issue, but-- - That's a salary discussion. That's the only-- - Yeah, I agree, because I have now been working as a freelancer, yeah, I don't quite know how many years. And I can be a developer or I can be a solution architect. I don't really have to say. For me, the title is not important. But I can see that many times I start as a developer on a project and then I have discussion with the consultants and business process owner and so on. And then they drag me in to discussion about solution. And then at the end, I actually do solution architect work, which I like all of it. But it's very important that you have people, obviously on a lower level, so to speak, that knows the system from the ground up and not only talking about profit and making the customer happy. Because I mean, I have been into many discussions where I say, well, if you do this, you will lose time and money. Yeah, but the consultants said, yeah, but-- but if you do this, you will break this in this, for instance. And so-- That is maybe one somebody that's happening and what they see from the customer, their expectations, a little bit switch. Because today, we have consultants and then we have kind of take roles. No, it can be architect, it can be developer. But actually, no, if you would like to go to this simplicity and implement out of the box, what customer needs, customer needs to you. Let's call them advisory. There can be technical, can be business to actually how this fit to their system. And they would like to connect data, work with the data. And then you need to, okay, how we could connect new ERP and all my stack. What does it make sense? And then you come, same person, a solution architect, maybe we just have another title. But you still will maybe push it more to customer side to consult and actually help customer problems and not maybe so much code. But in the end, customer will need services. Now, would you now code or would you really see how customer can benefit all the data and pushing somewhere else and then even do great analysis? I think this is, this need is getting bigger and bigger. And it's getting bigger and bigger architects who are not just connected to one tech stack. Because if you are now working just with F&O and customer, okay, then I need to have one for F&O. I need to have one for the Azure stack. I need to have one for, I don't know, everything else. And how great would be that architects can maybe know some skills which they don't need, just release and just gain new skills and actually help us customers as well. To have great enterprise architect, this is not so easy to find. And then there, you know, let's not do this at all. And F&O, let's just use services because it will help you with transformation. You don't like it, just exchange it. But you can't exchange so easily, kind of, I would say, bigger or the smaller ERP. And this is, I think, a lot of potential and co-pilot council in the next five years won't be so strong, but that kind of skills and kind of needs and who they are wanted to something like this. - Well, I agree, actually, it would be better that we get good enterprise architects in, instead of a financial solution architect or a trade and logistics solution architect or XX solution architect. I mean, I agree with you. That's an enterprise architect is much, much better than a specific architect. And I mean, I also use check DDB and the co-pilot and so on. No, but I, but I don't think it will replace anybody because the result you get from these AI in order, if you blindly use it, you will fail. You need to know what you, you need to know what you, what your results should be, because what they spit out of information to you is not necessarily the best solution, at least not for now. - No, correct. - I know, I know that we were automizing a lot with LLMs, our customer service. No, and this is not just that you will turn on one service, even not co-pilot, but this is really work. This is many flows, this is really seriously work. But in the end, you see this move, how actually they're helping you to auto my stuff and how they're helping you even to do things which even people don't want to do. And I think it's switch, it's there, push forward, it's happening. But of course, it can't replace everything, no? But every year, you know, that it's kind of before was just even in ERP world. No, you didn't have anything, no? Now you're starting to have some co-pilot give me some assistance, no? And this is probably will go, okay, help me with analysis. But if you now take this bigger picture, and now we can combine like enterprise architect, no? Combine even great consultant who would be able to combine process, possibility of that kind of co-pilot and maybe kind of future vision. I think this is probably next step for ERP, more what I could say with saying autonomous agents who can help you your activities. And today, even if you'd like to automize a lot with LLMs, as I said, it's a effort. An automized deployment, everything, it's not on the level as you would like to have as kind of tech guy, but it's going. It's solving the problem, and I will say future will come. Not 100%, we will still be really busy with maybe similar activities, but they will have their pet for sure. And I will be happy if they can be bigger role in ERP to helping users. Now, if they have questions, please don't ask for a level support, just ask for support, how great this will help us. Yeah, but I agree that the LLMs is really, really nice. However, I have also seen that some companies use these AI robots entirely. But I agree that the co-pilot in F&O is actually quite funny because it can actually help you. But you also need to, a little bit need to know what you are looking for. It's not that it can give you, I mean, the, as I said, I will say that the input you give will also reflect the output, so to speak. I'm going to ask the joint thing. Sorry, we're not so pleased, go ahead. I just want to say on co-pilot in F&O, even I like it, for example, the one on the vendor card, I always go and check if it's correct, you know. Thank you for this nice summarization, but I'm going to validate if that's correct, if it's correct that I don't have any overdue invoices on that vendor. Yes. - You have to blind trust the machine. - Yes. - Can we? - Well, I don't know. - I think that's, I think that's a whole other round table. In fact, my previous round table was an hour, an hour and a bit of just about this. And look, I think we can sort of many, many more hours about LLMs AI in the future of it and where it stands. But we try to keep these limited to an hour, maybe closing remarks from everyone. If that would be really great, or you're going to start yourself for now. So business central versus F&O co-pilot separate topic. - For myself, I mean, it depends on the complex process complexity. And this is where I would like, then I would like to choose BC versus F&O. As I said, in my organization, we have F&O, even though we don't have a so big comp, I mean, we have the one company, one set of companies that are using BC central. They use the same processes as one that they're using F&O. So now is the question, do we need that big monster of F&O and can we switch to BC central and so on. So that's why I would say that for me, it depends on the complexity of the process and the new number of users and what you're expecting in the future. So that's for now, but my heart is always with the BC central, if I need to choose. - Yeah. - And I'm not, I can, I will, I was more or less on the same page as you, you should use a tool that fits the business. However, I think that F&O will fit all businesses. - But you can customize everything. (laughing) I can't throw that wrong. - I'm more, you know, I would like to follow simplicity and then with this achieve scalability. And then if, and in the end, these are these maybe competitors, no? And then based on your needs, you will then choose product BC or F&O. I see future of both products. I see, and this is, again, feedback from the many, if you have, and you said, I don't know, you have, if you have a lot of complexity, you have big load on the system. And you would like to have really focused on what come on company product and not take care so much about your systems, then I will go for kind of enterprise product, this space to F&O. If I am not fitting to this term, if I are still growing, but I'm smaller and I'm exploring different stuff, I will go to BC, why not? I have bigger community. It's easier for me to change. And it's always phase two, how you can be agile, how you can change easily. No, one simple event, enterprise, big software, not so easy. If you're smaller, and if you do mistake, you can, I suppose you can change easily. So first maybe kind of what you would like to reach, but as again, I'm more, if whatever I need to do that it's simple, it's scale, and then which software brings to them, but like both of them, and I hope Microsoft will maybe make them even better in the future. - I just wanna add one more thing before I answer the final question. F&O is becoming so big that commercially speaking, you see this Microsoft, what they do before it was one package, X, F&O, but now they're making its finance, supply chain, projects and operations. So in my feeling, they know they've like, they didn't hit the limit, but it's like on the high ends, we're getting up to the peak of the mountain, you know, and then commercially they're splitting it, and then of course you can have a business central and a supply chain for F&O if we're all what they want, that's better commercially for them. So in that sense, I have the feeling that today, they split it commercially speaking, and I feel that Microsoft could be wrong, they can react to as a comment on this video. I have the feeling that currently they boost a bit more the business central software package, sort to say. So yeah, I think, yeah, it's, I don't know, it feels different, they have different purposes. Now to answer the final question, now it's F&O or VC, I like them both. I have F&O at heart, always, always been there, always will be, but I do see a lot of benefits in a VC, and the interaction with office packages and so on. And like I said before, if Microsoft decides tomorrow to move a VC onto Azure, fully control world and performance wise, I think it's gonna be a difficult, even more difficult discussion than now. - Thank you all so much for a very, very quick hour, it flew by, I learned a lot in both of you guys, all of them maybe learned something as well. (upbeat music) (upbeat music) (upbeat music) (upbeat music)