Let me know when you can see my screen, okay? Can you see your module? Yes, yes, I can see it. Okay. Now, let's say if we work with SD, In SD, we can see that if I identify here, I'm just marking for the time being, we will do something with it later. That is, which things are unfinished here for us. So, we marked it. Is there anything else here? This is at 50%. You have finished most of it here. Okay. Now, here we saw that Sales Arena, you haven't finished this. You haven't finished Today's Task. And this is Location Tracking, this, this, meaning you haven't finished it. Okay. Besides this, here we can see that more or less, according to your feature list, I would say almost 99.99% of yours is finished. Right? So, this 99.99% of yours that is finished, this, how is it interacting to the business? Okay? How... How it is interacting to the business means... that is, in this operation, their... its performance This is... how is it for you specifically, if I say, how is this You have developed this module for... to perform a specific methodology, right? You have developed SD for the market. For sales and distribution. Now, this thing you have developed for sales and distribution, how is it performing? Is it... If I... if I one thing, let me just share it with you to explain a little. I think this will be a bit easier. Let me share screen. Yeah, please.

Okay. Actually, I took the initiative to create this presentation, but I couldn't do it due to a lack of time. Basically, this is at JARPET NGPIL Pharma Competitive analysis, yes, a before and after. Let me just show you one sheet. just... where is that? Here. Okay. For example, Order to Invoice. Okay? A comparison between previous and current. Before. Before, there was paper-based ordering, where I have made a competitive calculation that for placing an order, an MIO, the MIO places an order on paper from the field, a time has been set for that. The AM verifies this on paper for them. Then this, this paper is sent to the depot again. The depot's data entry operator again does data entry for this order, and after the data entry, prints an invoice. As a whole, this order, the order time takes about nine and a half minutes. Okay? And what is the costing for these nine and a half minutes? My average, its... the cost of these five minutes, according to that, or the cost of one minute for the AM, according to that, from one order to an invoice, I have calculated the costing to be around 19 taka and 90 paisa per invoice. And approximately, the monthly expenditure is for about 180,000 invoices, and this is the cost. Okay? Okay, now let's talk about app-based ordering, meaning when an order is being placed in our system, then... what is the average timing? An MIO takes hardly 15 seconds to place an order. It takes less than a second for the AM's verification, still I've considered one second. It takes five seconds to create a DIC's invoice, there is no data entry, nothing else. After that, printing. Even in printing, it's one page in two seconds. Ultimately, 23 seconds per invoice is being spent, where before it was nine and a half minutes. And the approximate costing, if we calculate with that same rate, then per invoice, where it used to be 19 taka and 90 paisa, here it is 2 taka and 82 paisa. Ultimately, the approximate cost for order to invoice is like this. Now, the thing is, this money, the difference in costing that I... 3,074,400 taka, this is not actually a cash saving. This has impacted their capacity in a way that the capacity has become 20 times what it was before. Where before it was very difficult for them to deliver 20 lakh taka at the depot end, yes, they had to sit until 12 AM, 1 AM, there, let's say after implementing this, the biggest depot's DIC is saying I can deliver 7, 8 crore per day. Where before, it was a 20 lakh taka delivery, so... it's like that. In this same way, invoice to dispatch, dispatch to delivery, delivery to collection, like this, and then stock management, offer management, target management, customer management, I intended to create these, but honestly speaking, I couldn't get enough time to make this analysis, comparison analysis. But when I'm a bit free, I will make it. It needs to be made. To do the 'as is' and 'to be'. I might need this for marketing purposes later. No, no, it's a good thing. It has contributed like this. When we replaced this manual system with this system, there are such contributions from this system in every sector. Okay. Am I on the right track? A guest has also arrived, I'll just take a minute, okay? Yes. Thank you, Arif bhai. This is a good thing. We definitely have to do the comparison. If we don't, we can't approximately explain that how our team members are benefiting the company. It's a good thing. If I come to my decision... that document, however much you have done, will you share it with me or... No, I... I actually... I have actually made only one sheet I will share this slide of mine with you. Okay. Right now, we have a general idea... if you give me a brief on the things you are planning to do, since we have access, according to that brief, we can also complete it further. It won't be a problem. Okay? Because what you have done... Of course, you can. For example, if you give us a brief that, we have developed this module. In this module, when there was no ERP, no JAR, this used to happen, after JAR, this has happened, which you showed. So, if you give us a brief for each module, then we can do it. No problem. Meaning, showing an overview, to the stakeholders that we have come to this stage from here. Then we will explain this again, that it has reached this stage, how can we save more money? if we do... to extend this to the next level. Right? So now, if I talk about the SD module, first, we are thinking about how JAR is supporting the business, like you gave one, you gave an example. This example, we need to create a use case scenario for it. Okay? Okay. A use case scenario needs to be created. What is the use case scenario? For example, the module you have developed, within this module, this... so many, like 69 individual... things are there... features are there. This 69 individual feature, how is it supporting which user? So, for each user level, if we say one thing, that... And why do we need this? We will need it more, we will control the users, right? So, if we control the users, then we will need this, that this 59 module, how is it aiding whom? We will use the word 'aid' here, why? Because each module is made for a different person. Right? Not everyone will use one module. You mean about the features? Feature, sorry. This... In this, actually, feature... for example, the sales area feature. Sales area feature Let's say in my total SD module, on and around, there are people of 20 roles, meaning... there are 20 types of users. Among the 20 types of users, it was seen that 10-12 types of users, meaning 10-12 roles, access this sales area feature. This feature has various operations, those are called actions. Actions. I have controlled these actions based on roles, that these two actions will be for Role 1, these three actions will be for Role 3, these five actions will be for Role 2, 3, 5, like this, so, I have developed the feature only once, made only one, but I am presenting this one thing to 12 people in 12 different ways. No, that's right, that's what I said here, that we need to identify that thing in the work we are doing now. Okay? Why will we identify it? Because when we develop this work further, or when we need technical resources, or when the people working for us need it, then according to this, you haven't made an admin panel, you are managing the resources now through the back end... meaning through hard coding or through the back end, right? Not hard coded in the back end, everything is in the back end, we have manually kept the configuration in our hands at the database end, we haven't released the front end yet. We have done the front-end designs, we haven't started development yet. Okay, we actually didn't get time to go, we need to... this whole thing, for this whole thing, we need to identify the use case scenarios. For your SD module. that how it is benefiting the business, we already said that... what you showed, we have to do something like that, maybe we will arrange it in a slightly different way. If you share the document with me and if you send me the total story in a message, then according to that, I will see how this SD module is specifically supporting the business we will create that and after creating, we have these use case scenarios that it doesn't matter, you can have a thousand types of characters here, users can come. Okay. Although it won't be infinite users, at least, if we consider an ERP user here, there are at least more than a hundred types. Okay? And it can be 100 or even 200. It can even be 300. Now, these 300 types or 200 types or 100 types, this thing we... will understand only when we arrange the use case scenarios. That Suman bhai is a user, he is a PM. So, what kind of access will he get? Arif bhai is one type of user, what kind of access will he get? Now, if Javed sir wants to access this, what will he see? Okay? What access will he get? We need to document these things with this use case scenario, that we want this. Because here, be it the total JAR or if we want to build this professionally for someone, we need to close it. That we can also make it dynamic here. Okay? And making it dynamic will be feasible, that we have 20 users here. If we want to add more, infinite users, then we will proceed with this process. That the user, it doesn't matter. Adding modules, it doesn't matter. Adding business policies, it doesn't matter. Adding changes, it doesn't matter. Everything will be done with a methodology and with automation. So that we have to stop these manual interventions. Okay? Because if we... the manual interventions... One minute, please inform Julfikar bhai. Okay. Yeah. If we don't stop the manual interventions, our cycle will not end. It will never end. This... you have been working on this for a long time, you are more expert than me. That we have to stop these manual interventions. So, firstly, what we have to do is, specifically, how we are doing this, to what stage we will go, for that, we will create a document. So, you will need from me, at what state did you start for the company? What state have you brought it to now? And by working together, to which stage will we take it? We will see our future. Okay? And to see that future, we will create the use case scenarios. That this user will get this, that user will get that. To create the use cases, can you from your side help us a little in creating the use cases? Of course, I can. We gave the brief, no problem. Absolutely, feature by feature, it will take a good amount of time to brief each feature. That in the sales area, what can be done, what they can do, and in the remaining 30%, what they can do but we haven't developed yet, we can say that. What actually happens with the monthly delivery plan, what is its necessity, what is its impact after that, where is it used. We can brief about each feature like this. It will take a good amount of time. No, that will be needed. I know it will be needed. But that's why we are doing this work. It will take us two, even three months. It might take more than three months. We don't know until we start. We have an... we have an assumption that we will close this entire project within three to four months, this initial discovery phase. Hmm, hmm, hmm. Because if we cannot finish the discovery phase within three to four months, here, what do we want? What does the company want? We want to do the discovery. What does the company want? The company wants a specific pathway on which they will proceed. Now they want that I need to do cost-cutting here. Now, our point is that cost-cutting is needed, that's one of the other pieces. Right? This needs to be taken to the next level. This is one of the puzzle pieces. These projects need to be 100% completed. This is one of the puzzle pieces. Now, if we can't discover these puzzle pieces, then, for example, the company said I need to lay off people. They said, okay, we laid off 20 people... we eliminated them. But this elimination, how it's affecting the current workforce, we don't know. To do that, each of our things, we... 100% accurate... after doing this discovery work, then we will say that you stakeholders, that you wanted to reduce the workforce. But you can't reduce the workforce because it has this constraint. So, the company will suffer. Or we will say something like, yes, there is a scope to reduce this, this, this, this, this space. Okay, and the existing condition. Yes. The company will not suffer. So, we are not making the decision. What are we doing? By doing discovery, we will create a 100% core report. From that report, the company will make a decision, okay fine. That's the thing we're going to do. Okay. So, to do this, we... Today, today let's go into a brief on this SD module one by one. Yes. So, to do that, first our user... cases need to be defined. The use cases can be based on the user, since the system is made for each user, right? We don't build a system without users. We build the system for our human users. Some can be doctors, some can be engineers, some can be project managers, some can be CEOs, some can be MDs. We are creating the system for them. Okay? Right from top to bottom. So, what we will do here, along with the feature list, here... we will create a user scenario, and before that, we will create a user list. Okay? According to this user list, we will divide the total scenario. That these users will come here now. And in the future, users will definitely come, in the future, the business will definitely change. This is normal. Okay? But what we will do is, after locking it, the whole thing, whatever changes come, we will build that separately and connect it so that my current workforce here... is not affected, is not harmed. Because you know well that hitting one table of a database means the whole database becomes like an earthquake. Right? So, we will slowly move away from this, that no, we will move away from the manual interventions. What will we do first? First, according to this, what we will try to do first is that, this SD module or the other modules that are there, how we can develop them in an automated way so that our resource expenditure is less. And our work is done faster. Am I clear? Do you have any questions? Okay, by user list, do you actually mean that... you mean the role list... basically, MIO, Area Manager... who they will be, that is... the literal role is the same, of the same type. The role is for you... One role has multiple users. I sent you a user list. This is... for each role, I have sent one user login. Yes, I know that. Your... It's the same thing, how many roles you will put here. Okay? Within one role, different users get different things, different privileges. Okay? So, that user list or role list, whatever you call it, we have to define and state that first. And for that... I have already probably sent a role list, along with that role there is a corresponding test user for each. I sent it to you. The very first time I gave the database and the access for the test application. Okay, it's there. Okay, that's not a problem. What we will do is, we will define it properly in this user list. After defining, we here... on this side, if I create a table here... So, what we are doing here is, first, we will discuss the business. What was in the past, what you are doing in the present, and what we will do in the future. Because we have to say this. We need to have this definition, that after one year or after five years, we want this. Everything of ours will be built based on that. Then there is the user list, as we said, we need to create a user list. Whether you call it a user list or a role list, whatever you call it, it's the same thing. So, you have made a list, we will define that and add it here. According to this role, we need to create use case scenarios for each one, that Role number one is Arif saheb, which module is Arif saheb getting here, and after getting that module, what is he... what is the end result he is getting? Okay? We need to understand this. What is Arif saheb? Arif saheb is the CEO or CTO, a senior C-level person. So, for him, actually, this module that is there, what will he need from it? What end result does he want? Because if we don't understand it from the personal use perspective, then our... we won't be able to identify it. Now, for example, Javed sir, who is the chairman, so what does he need? The chairman is a user or the chairman is a role, what does he need? We need to identify that thing. And for each user, a use case scenario needs to be created. Now, the use case scenarios won't be thousands of use case scenarios. If you have 100 people, for 100 people, or if you have 50 or 30 roles, for these 30 roles, you will have 30 use case scenarios. Okay? Where multiple users will get categories of different things, that doesn't really matter. Each person can get entry into four scenarios. That's not a problem. But the scenarios will be those 100, against this feature, that's what it will be. And if that's not there, we will have that plan, that we don't have this now. We have to do this thing in the future to implement it. So that we have the view or the vision that yes, we are doing this now, these things have happened with our database, with our software development, how we will implement this, and what our end result will be. So, if we do this work, we will more or less be done with each module. Then what will we do? Slowly, this work of administration, the work of dealing with the users, we can slowly start that work. Otherwise, we can never start this. Do you two have anything to ask me? No, I have understood. Now, the use case, let's say in one role... meaning, not one, there will be multiple use cases for each role, it has many things... these duties are there. Each role is actually defined based on its tasks and duties, responsibilities. He can do many things. So, just as each feature will be a use case for one role, again, one feature, let's say, is accessed by six or seven roles. In those six or seven roles, their work can also be different. So, one feature can touch several use cases. No, I understand that, that's not a problem. I understand that, now our point is, if we think about infinite things, we can't close it. Right, right, right. Now, if we... we have to do that... we have to think that this... this... 69 features that are there, okay? This feature... within this, one is inventory, one is stakeholders, one is local sales, one is your... these modules that are there, okay? Now these modules, for these modules, we will create roles, right? If there is anything outside of this, that's our future planning. Those won't be added here, if we want to do something in the future. Or this is now... New features will be added in the future. This is now, this will be the modification that... we will lock this in version... version 0.1. Okay? Now, by locking this, for each section... what I said, you also said, that for each section, we will create a use case scenario. Now, you can go section-wise or you can go role-based. This, I think... I think it's better to go with feature-wise use cases, maybe in that use case, we can have different role accesses... when mentioning the use case, for this role, it's this... it's better to go this way. You can do that too, no problem with that. Now, for example, configuration, right? Now, in configuration, you have these many features here, one, two, three, four, five features. Okay. Now, this configuration, to how many roles will you divide it, and after dividing it by role, what will be the use case scenario for the configuration? This configuration, the role list you are making, the configuration is against this list. Right. And the role you have created, that role can get configuration and can also get local sales. Or it might not. Hmm. Right. Okay? It might not. Now, if someone is a local sales person, that local sales person is within a limited boundary. Some characteristics, some roles, are within this limited boundary. They don't need to go to configuration. They might be able to go to inventory. Sales person, since they have a relation with inventory. They probably don't need to go to stakeholders because stakeholders... they don't bother. Now if I say, among the stakeholders here, for example, the chairman. The chairman, he might get access to everything, but what is his main need? His main need is reporting, how much money is he earning, how much is he spending. In which places in the market is there illegal penetration, what things are happening, if he is made aware, he has to improve the business. We will build these things, and for this, these things are needed. We will propose that to run a business, in an ERP, according to the role of a chairman, what he will need and what we have to implement. What will be needed for a sales person, what do we have to implement. Now, whether the market changes or the market extends or technology changes, we have to work keeping those in mind. Okay? In the future, we talk about Facebook that they released a feature, they released that feature without considering the users. Okay? After two days, the feature is tested, everything is done, and then the feature gets modified. And this is... be it live applications or the things you mention, be it ERP or CRM, we have to make them live. Now, while making it live, what we have to do is, its... the thing... the software itself, the penetration that we do, that the developers do, if this thing is automated, it's beneficial for the company. Because... everyone does this. We will do that work here, that whatever it is for us, we have to modify our software, we have to change our software, but its core foundation will remain the same. What will we do with the foundation? We will make various relations and spread different things in different places. Which will bring a combined result together. Our work now is to do the business thing, create a role list or user list. That role list, or according to our configuration... section-wise, either way, we have to make the role list. How we attach this is a later matter, but either way, we have to make the role list. That I will have 56 roles here, this role might be dynamic in the future, the role we bring, that will also have a methodology, that which role is coming, if a new role comes, then the old roles that are there, how they will be affected, or they won't be affected, that will also need a methodology that... And stakeholders will definitely know that if we add a new person here, then by adding this person, this is the thing that we have to do. Without being interrupted. Suman bhai, do you have any questions here? Yes, I listened to your discussion very nicely. Sir, you understood many of the gaps here yourself. Here I want to add something, like the features we are seeing here, 37 more features will be added. Okay? Because we have ignored the app's features here, okay? And your role-based... the use case you want, there, what Arif sir wanted to say is that... one feature is often accessed by multiple users. Whether... whenever you are thinking about orders, that's under local sales. Simply, an order can be accessible by MIOs from the app user, then his manager verification layer, then it comes to the Depot and where the DC approves this feature, and after that, the ADC prepares other necessary particulars there such as delivery schedule making, delivery preparation, and after that, it belongs to the delivery person. So, there are multiple roles accessible in only one order. So, each feature is like this here. And... it is in a highly manageable way here. Our... the features that are accessible here, as Arif saheb said, the user actions have been aligned like this in the database, that... meaning, I would say that if we have experience seeing a very high-level application, then I would say you there... the layer of this thing, I think you will find it very less, which here we... one... we have kept it, that we are controlling the action buttons. Okay? And not action button, action button, suppose a DIC. DIC is a role, okay? He might be NGPIL Pharma DIC, okay? Pharma DIC is saying that I have partial. And what did we do? We saw that no, medical device says no, no, we can't appreciate this kind of process in our order approval. We won't have partial orders. Then how can we manage for that DIC? We have this here, but we can also tune it SBO-wise. Okay? It is done nicely here, it is optimized. Okay? So, this use case that you mentioned, those things, what you said is right. I will just show you one small thing. Actually, what happens here for us is MVP, we are creating an MVP for the product. Because what are we doing? First, as quickly as possible, we are delivering his screen to my end user. That you start working. Okay? And behind the scenes, we are doing CI. Continuous improvement. That's what you mentioned, what Facebook does. Okay? So, we are doing it here. Okay? We work with this technology. Basically, we are delivering first. Okay? A part of the product, you start. But the rest of the work, we are managing. Okay? Then slowly we are releasing this. Okay? So, this is how JAR has become so big today, and it has the opportunity to become even bigger. Okay? That's what I'm saying. That Suman bhai, what you said, I understand and agree with it 100%. But what I said is that you can have several thousand more use case scenarios here. It doesn't matter at all. When an application of this level is made, when 15-20 thousand users will use this, If we want to sell this to many companies, many companies have... like a hundred thousand users, right? Yes. This whole thing, this thing, we have to get this ready on paper. Okay? The scenarios. And for that scenario, the kind of features we need to develop, we need to have that plan. Now, for example, you might have multiple scenarios here. You have multiple, several thousand scenarios here. It's normal to have that. But what do we want? We wanted to list all those scenarios and map the current system with the scenario. The thing that you don't have this mapping for now, and we have come to do this mapping. You will develop features, that's fine, you will definitely do that, you will finish the project, you will definitely do that, you will do many other things, you will definitely do that. But to do this, if we can't do this mapping, then it's a problem, and by doing this mapping, the entire documentation will be integrated into this JAR, okay? Now, for example, you have a few users, when you search, since we will include this, that give me the use case scenario for this user. One user can have four use case scenarios, can have five, can have 10. Because one user, according to you and according to me, is associated with various types of stakeholders. The scenario for each stakeholder will be different. Now, for example, when you talk with Arif saheb, you speak in one way. When you talk with your chairman sir, you speak in another way. Okay? Or your chairman sir doesn't even have access to go. Okay? So, these things, if we don't do the use case scenarios for these things, then we cannot close that application in a proper way. And it will go on like this, and in doing so, it will never end, simply put. Okay? Yes, I have understood. For a UAT, meaning... each feature needs to be... your user-based, meaning role-based, okay, for each feature, we need to have some use cases stand here. We need to bring... bring it so that... in the future, if we know the software, if we map the software, and we have this plan for the future, that... in the future, according to this feature list... you also said that 30-40 more features will come here, that's okay. Features can come unlimitedly in the future. That's not a problem, but our this version... What we are locking, that has to be locked. That has to be finished. Here, here we have 37 more features which are for the app. Okay? Which I am seeing here, it's not here. Then here, you need to provide the app's features. I... I will send it to you. Okay. Our this SD module, and here, which ones are within the app, you have decided that the app will come, below each module, one is for the web, another will be for the app. App. Yes. Another one will be the app, and this is how we need to provide the features so that, in the use case scenario, who will use the app, for that, we will need this methodology. Will everyone use the app? Will you? No, you probably won't. When will you? When you need to do quality control, then you might use the app to see what the feature I made actually looks like in the app. Okay? But you are not the actual app user. Who will be the app users? Those who will be in the field, more or less, those who are the actual granularization people for this. Okay? Now, for the SD module, the granular level people are the salespersons. Right. Now if I go to HR, in HR, the granular level people are... not salespersons. mostly web. Yes. What are they? We are keeping one part in HR. We are keeping one part in HR where your leave... your leave can be submitted, okay? The leave can be seen. There is a part for leave management, this is within the HR app. Okay? And some of his particulars, payment issues, we are keeping them in the app here. That very thing, we will put in this list here. That this is the HR module. These things from this are going to the web, these things will go to the app. We have to be certain for those. Every and every, every page, we have to set it like this. And when we set this, when the use case scenarios are done, when this list is created for each module, then our future planning, budget, and timeline will come. Otherwise, the timeline we are creating here is not the appropriate timeline. This timeline, this budget that is needed, that budget is not the appropriate budget. Why? Because we... the bag that we have, what things we are actually filling in that bag, what things will fulfill it, we haven't done that yet, the groundwork. So, after we do this thing, then what will we do here? We here... when we made the list, when we did this, then what will come for us? Then for us will come the timeline, with this, first we will do... People. What does people mean? Those who... will work on these things in the future. With people will come the timeline. Timeline or people, this can be vice versa. It can be before or after. This is not a problem. And on top of this will come our budget. Okay? These three things we must do before doing our project. So that we can understand that in this timeline, for example, if we bring a feature, we will bring a feature, we are given a time of six months. Okay. Now, according to six months, our people... and our budget, if we set it... I am taking the timeline up. According to six months, if we set a timeline, then how many people will we need, how much budget will we need? We need to know, the business needs to know. How much are we spending? And according to this, we have to decide that if we spend this money, how much are we earning in the future? Earn, another thing will be for us... with this... we need to know the earnings as well. That these things, if we do them, then we will come back up to the business. From here... after this... earnings will come, and the earnings will go back to the business. Why will it go? Because the money we will spend, is that money really well spent? Or we don't need to spend the money. So, our job is, after doing all the work, to show this entire thing to the stakeholders or to the senior levels. That the work you have done is at this state. In the future, we will do these works, for this, this timeline, this budget will be needed. And how this will return to the company. Meaning, your investment needs to be made until this date or for this many years, otherwise you can't get a return. Or you should stop right now, what has been done, earn from that first, then start future development. Let what is there now remain as it is. Now you might be developing various modules or doing things. All these things we need to anchor. We need to anchor and cross everything. After crossing, then we will start work again, that yes, and we will also decide this, since you have a team of 30 people here, that if we do parts, then what will we actually make this team of 30 people do? We need to set a goal for short-term, mid-term, and long-term. Okay, here we have to do, for example, this admin module, we have to... here there are some more things for SD which need to be finalized, or for example, the senior levels said, no, okay, then start HR. These things will run in parallel under this methodology. But we won't say it, the senior levels, they will make the decision, yes, okay, work according to this. But what we will do, so that even if it's not 100%, there is a more than 90% chance for us to properly consider everything. Okay. Got it. Okay? So, now if we close this meeting and... then first, what we are doing is we will start with the SD module. Arif bhai said that each module for us... needs to be done. We need to record each module, what you have actually done, and if you have a list for the future, that you will bring things in the future, I will request that you add that, that in version 0.2, we want to do this thing. Okay? And after this is finished, updates will definitely come. Because the business will change, technology will change, everything will come. Those are not our concerns now. Our concern is the feature you have made, the features that... in the next five years, if we consider that within five years, we want to bring these features, make a list of that. What will come in the application, what will come in the mobile application, make a list of that. Now your application is Android-based. Now if we... want to send it internationally in the future, we need to make it for iOS. Now, from what I have analyzed, I've seen that you haven't done anything regarding iOS. So, now if you want to do that, then we need to... for both platforms, what is done for cross-platform, we need to develop that way. Now, there is a cost involved in developing that as well. Okay? Anything we do has a cost. We will also do a cost verification for that, that... actually, now for example, you have made a mobile app, you have developed the mobile... the mobile app further, but after this development, if you want to make the mobile app for iOS, it can't be converted. Right. Then what should we do? Should we continue growing that or should we pause there and implement a new methodology. If you proceed now without making decisions on these things, in the future, this will backfire. It will backfire in a huge amount. from the measurement... or the work you have done, then why didn't you have a future plan. Okay? So, for this reason, what I will request is to proceed systematically. So that all stakeholders are happy here. Okay. So, for this feature one-by-one recording, will you... give a specific schedule? For this, I... I will give a schedule, yes. I will give a schedule for this, since we have finished one schedule, now we will do feature-by-scheduling. Now, for feature-by-scheduling, it's not enough for the project managers to sit with me, the developers also need to sit. Whom do you want to bring here? Or one or two key persons don't see... according to each feature... will tell us. Now, before saying that, what we need to do is, that is to fulfill this list, that your version... if I say this is version 0.1, Okay, Nesar bhai, let me show you another document, let me share it. Can you see it? Yes. Okay. Our first feature, Sales Area. For the Sales Area, it's a user handbook. How has this handbook been created? Meaning, roughly, the user handbook for one feature. This sales area, from where and how we will use it, what its operation is, it's more or less described in this manual. Will this be helpful for you? Absolutely all operations, who can do what when, or can't, this is almost a... what, a 14-page thing. This will definitely be helpful, but what we need to do now is, actually, after seeing each functionality, how you have defined or designed the database for this functionality. These things need to be mapped now. That this is just the feature list, meaning it's mainly the database. Connectivity with it. So, this feature list you have made, how it connects with your database, we will design that. How the users are accessing it, we will define that. Now, this can be multiple users. Your developers are also one sort of users. Okay? How are they accessing, how are they modifying, how are they doing the basic CRUD functionality, we need to define that for each. For each function. And then we can do... according to these scenarios, we will define this basic CRUD, as we call it, actually, which user will get how much privilege, who can do what, who can delete, who can view, who can share, those things need to be defined. My keyboard's battery has died. Ah, it's coming here. Why? You made it 500 taka. You made it 500 taka? Okay, this is white, sorry, that's why it's not showing up. Okay. If we say here, JAR version 0.1, we will do something with this. In version 0.1, we need to bring a locking system. I would say that... traffic system. Lock means traffic system. The traffic system, when will we bring new things, when will we turn it off. We need to understand this. We need to know this. So, JAR 0.1. Now if I say this is JAR 0.1, then here we are giving... JAR 0.2. Okay? 0.2... what have you planned for JAR 0.2? And that plan, what will we do, we are saying here again, that we, for five years, we will analyze the thing for the next five years. Okay? We will analyze the next thing for five years, that our target is to go here in the next five years. We will close it according to that. Now, for example, we didn't develop a new feature now, we did it after a year, that's okay. No problem. Okay? Plus, here will come another thing where we will talk about JAR 0.1 application, let's say mobile application. Okay. Cross-platform. Okay? Here, what you want in the mobile app, we will list that. So, this document is already in the folder that has been shared with us. I am sharing this with you again. I have saved it in your document. So, you are already here, Rasel bhai is also here. Okay, one thing I am... Rasel bhai's email is returning. Have you noticed? That has probably been fixed. I noticed that in the morning. Milton bhai has probably already solved it. Okay, I did that... I also informed Rasel bhai last week when I emailed. So, what I would do now is I will send you an email regarding our meeting and outcome today. And like I did previously, so, what we have decided first thing is to complete this... all these four, five modules, everything, based on this task list, what we wanted to achieve. We will include everything here, what we wanted to have in JAR 0.2, what you wanted to have in the mobile app, and everything. So, this would be our bible. Based on this bible, we will create a business five-year sheet, what we wanted to do, what we wanted to achieve, how we can save money. That's our first priority, to save money, and to earn money. Two things. First is save, another is earn. Okay. And to save and earn money, what we need to do is we need to understand... the business, we need to under-define the users, we need to tackle the user scenarios. And based on that, we can settle down a timeline, we can know how many people we need within our team for each sort of work, and then we can create a budget, and that budget and these things will be presented to the senior people, chairmans, or MDs, or whoever is making decisions. Okay? So, this is our first session. You need to know... you need to let me know when I will book the next sessions. We can start from next week because today is Thursday. So, we can start from Saturday, the 29th. So, we can have... I don't know how many hours we need. We can have two hours each day, and we will see until it's finished. We can say like, okay, 10 AM to 12 PM. So, 2 AM to... so, 4 to 6. Yes. I think, I think, a daily one hour... keep one hour because our... we are running in extreme development pressure, extreme. NJML is going live, JHRML is going live, there are several unseen issues for the new SBU's. For that reason, we are actually under some additional pressure, the whole team. So, let's keep one hour daily, from 4 to 5. And we... next... for the next week, we will plan for SD, feature by feature. In this next week, the six hours we can describe, one hour per day. Suman should handle this, I will be there, Rasel bhai will also be there, whenever someone's availability is needed. And Suman will decide if anyone else needs to be involved here, probably Faria also will need to be added sometimes to describe things here. One hour a day, how many days could it take? One week? Six hours? Full SD? Yes. I... I am hopeful that it might be possible to describe SD within this one week, and if it takes a little more time, we... at the end of this week, on Thursday, we will decide. Let's continue. This is actually feature to feature, for example, slab, number three, the slab. This will take you hardly five minutes to describe, what is it, and... how it works, where it works, just saying that much. But when I go to order approval or the order thing again, then I will have to reference this slab, that if it's like this in this slab, this will happen or not, the configuration. That's it. This is actually feature to feature. Okay, I have set six days, within this there is the Christmas holiday. Will you be closed on Christmas? Yes, we will be closed. We will be closed... So that means... that... no, that... on that day, on the 25th of Christmas, Suman... are you in Dhaka? I am available. We will give that one hour, no problem. Wherever I am, I can. So I've kept it for six days. one hour each for SD. And we again... depending on how we can close this progress, we will make some changes. Okay. And if on some day, we... one hour... meaning we will start at 4, even after one hour if we see that Suman is free or someone is free, we continue for a bit, can we extend that part on that day? Okay, okay. Then it's done. We will schedule it for one hour, but on the day we are free, that we can do it until 6, or no, I can do it until 7 today, on that day we will continue. Because we have to close this within this month. Because from January, I will be very busy again, I will come to Bangladesh again. So before that, if we close and create an initial report at the end of this month. So, within these next 12 days, if we can do quite a lot, the ones that are the main modules, it will help. This will be possible. Okay, after SD... even after SD, there are three more big modules in which, let's say, in SD, let's say if we need six days, we... production planning or material management, these will take a little more time because production planning is a bit more complicated. In one place, let's say, there is work for 20 people, the work of 20 people is of 20 different kinds, in one place, on one screen. Then material management as well. That will be needed, however we can complete it. We have to complete this now because another thing is when we do the documentation, this is the core... it will work as the core, the end-to-end documentation of the whole thing. And until this is finished, we... this... meaning the use case scenarios we are talking about, we cannot do that either. Right, right, right. And another... another thing, the blueprint documents are probably shared with you. Each one... has been done. Yes, SD... the total building of SD, let's focus on this. By focusing on the blueprint document, we have extracted the requirements and developed it. Oh, that's not a problem, we will identify that slowly, so... that, God willing, won't be a problem. No problem. God willing. Okay, Arif bhai. Thank you, Suman bhai, Arif bhai, for your time. We will again meet on Saturday, the 29th. Yeah. Okay, okay. Okay, yes, goodbye. Peace be upon you too. Goodbye. Peace be upon you too. Because... not after a day, you...