Expecting a TMS: 9 months of wonder, reflection and hard work!

Natalia Kurysheva 00:06 So hi, everyone. Thanks for your participation today here and joining the session. Today I'm going to talk about how to select the TMS. And they're all trying to provide some guidance to those of you who are interested in this topic. And let me first start with the quick introduction. My name is Natalia Cordova, I work at the Agilent Technologies as a localization project manager, and I'm localization technologist lead in the team. Before starting my presentation, let me share this results of this funny quiz, which Kate actually posted on SmartCAT, LinkedIn page. The question in the post was, what do you think is possible to accomplish while your team is big in a TMS and 42% of voters actually said that learning the language at a a one level is approximately the same time 29% That it is approximately the same as given birth to a baby. And they were not wrong. I'm going to now move forward with my presentation. And you guys can also vote in chat and give me your assumptions of how long do you think it may take to actually select a TMS and in the end, we can see what we have. So, I will start by by talking about who should be part of the project team selecting a TMS and actually a localization team is one of those member because TMS is a translation management system, and localization team is the main stakeholder of this selection. But it is not the only one. As a TMS is a software IT department should also definitely take part in selecting it because after all, it will be it who will be implementing new TMS and the whole in the whole architecture and then maintain it and troubleshoot any problems if there are any. sourcing team or procurement procurement team is another department, which will do a great chunk of work. Because if you're a company who are looking for TMS, so probably you're big enough to have your own procurement policies which should be followed and sourcing team will be taking care of communicating to the participants, potential potential participants or potential vendors requesting information from them, negotiate contract price and so on so forth. Now, is that all? Well, actually, not really, you will definitely need to cooperate with your content owners. Because most likely your TMS will be connected to their CMS is unless you want to do upload and download manually. Probably if you're looking for for a TMS you would want to connect it to all CMS as you have in your organization. So contact content owners can also be your internal clients or requesters. And that's why they may have their own ideas of what requests or interface of a TMS should look like what functions they would like to see and so on so forth. And actually a content owners would be your main clients probably and that will be very useful to have them in the project team. Then I think that LSPs or in house translator, depending on on what model you guys have in your organization's are also people who will be using TMS actively. It of course, again depends on what model you use, whether you have LSPs or in house translators, if localization PMS work actively in the cut tool or if the analysis of the source file is done on site of localization team or is it is done by LSPs. So all of that is of arrival, right? That depends on what you have in in place in your workflow. But LSPs definitely have more experience in working with, for example teams or cut models or QA tools. And that will be really beneficial for you to have them in the project team. And last but not least, consultants or consulting agencies can be also a good addition to this team. Most likely you do not select TMS every day, or even more than I don't know, once in your life. But consultants, engine agencies can help you a lot. And as they have more experience, obviously, and they will help you build your requirements will probably help you develop a scoring model for your candidates and they actually provide guidance on practically any stage of the selection. So now when I started talking about stages, let probably let me probably list all of them and then we'll we'll quickly go through each stage of the selection process. So the first one, the first stage would be probably a preparation of the requirements, where you will have to building metrics of requirements. After that, you will identify participants, you will initiate initiate your first contact with the requesters four with the with the participants to request for information so called RFI stage, after that, you will do the scoring for this first stage, then you will do demos. After that you will shortlist your participants, then you will do proof of concept or hands on testing. After that you will prepare final scoring and do contract negotiation and final decision. So this stages are can be different. Depending on some factors. For example, you may decide that you do not want to do demos, and you only want to do hands on testing with all the participants. But let's talk about the stages a little bit more. And then you can decide for yourself what exactly you would like to do during this process. But before we go to the stages, let's talk a little bit about how to be participants. Because it seems easy that okay, I will just invite everyone who wants to participate, and then you will end up with a bunch of participants who wouldn't fit your requirements for example, or there will be too many of them and you will be just lost in in this pile of RFI as you receive. That's why I suggest that you do some analysis first. For this, you can use new media outlets, I think I advertise it almost on all my presentations. But it is a really very useful tool, because they have all the technologists gathered in one place. And you can actually see different TMS for different purposes. And you can pick those which suit yours, the best. Of course, there are other market surveys which you can use, you can also participate in industry events like this one, because there you will see some boosts with the people from different technology companies, and they can answer your questions right away. And you will get all the information. And that's the thing which can be useful for you is so called Magic Quadrant. Gartner reports. These are Gartner is an IT consultant company from the United States and they prepare this Magic Quadrant reports for different technologies. And not long ago, they started also doing this report for localization in the industry as well. And it can be very useful. So now, let's talk about the first stage request for information or RFI. And let's quickly look at this chain of building up requirements or matrix of requirements. So first of all, you need to analyze your ecosystem. Look at what CMS is you have, how and where you store and manage your terminology, what BI systems you use, what CMS is your LSPs use and so on so forth. Just have a look at the whole ecosystem and decide which CMS should be included or which tools should be included in this ecosystem and in the process and should be taken into account why while choosing a TMS. After that, you look at your workflows and try to analyze pain points that you have. You should probably answer some questions like, if you have manual steps which you would like to automate how many of them where they are they are in the workflow? Where do you waste most of your time? What tasks require most of the efforts of your team or of LSPs? Are there any special requirements for your type of content that you log wise for example, ra, which is regulatory affairs review, if it is needed? And if yes, what requirements they have? Do you use subject matter experts reviews if he has, what needs they have? How do you communicate with your LSPs translators requestors what reports you do? Do you use machine translation and so on, so forth. So an overall analysis of your workflow including pain points, you can also research market to see what is out there and what you would like probably to have in your TMS and what would suit your workflow the best. And after you do this first three steps, you will have a matrix with all the requirements. And the next step would be working on prioritizing them because believe me, in your metrics, you will have a very, very, very long list of requirements. And I cannot even emphasize how big it can make it can become and you will be really overloaded was was the information you put there. That's why it's important to prioritize which specific requirements you want to leave in your metrics and which can be left out. So, in the last step, in this stage would be a two rounds of RFI and saying two rounds, because you will have the your initial request for information and then and then there will be some follow up questions after you you receive information from your candidates. So, now, let me give you some examples of of metrics and how it can look like. So for example, you can build a matrix like this, you may have some big sections, like this ones, for example, big section connectors and the integration, project creation, translation, inquiry management, business reporting, machine translation support and so on, so forth, that can be main categories of your matrix and then in each category, you will have some subcategories for example in connectors in the integrations, you may have content management, and then the list of all CMS as you have for example, Oracle web center services or Adobe Experience Manager and so on and some other then you may have terminology management management subcategory, and then the tools you use to maintain your terminology and some others also, yeah, you you may have subcategories, where you will have functionalities described right for example, vendor project management, you will see functionalities like this, for example, ability to receive notification via email for new requests and some others. Besides these categories, and subcategories and functionalities listed, you will have other other columns here and the one your participants will have to fill in will be supplier responses, separate supply response, and here you should probably give them some variants of reply right, and they should be the following standard functionality, plant functionality, custom functionality and not available. So basically, these four variants of reply for each of the line of your metrics. And this is needed because you need to somehow categorize your replies which you receive in order to do the RFI scoring in the end, in your scoring in the final score for RFI, you should take into account only standard and planned functionality and actually when you send this request for information to your participants, you should say that plan functionality is next release or maybe next two releases, not more than that, because after that, you cannot be sure that this functionality will be included in next releases, whether it will be developed in the way you want and so on so forth. So basically and not available functionality is obvious, right? Because it's not there so it won't be included in the final result. But custom functionality, I want to just make a small comment here. It's also something very questionable, right, because you do not know how much time it will take to develop this custom functionality. You do not know how it will be done and what additional funding you will be needing to develop it. That's why the most important parts are standard and planned functionality. And on the basis of this replies, you will build your final scoring for RFI. So next stage of the process, which I showed is demos. And, again, this is something you may not understand why you need. But in reality demos is a very good way to save time on POC. For demos, it is a very good idea to prepare some predefined scenarios for the most important parts of your workflow. And ask your participants to show exactly how they go through the scenarios. This is the example on the screen of what you can use of as a as a workflow or as a scenario for for the demo. It is also a good idea to do so because your participants like managers who are working with you and showing you these demos are very familiar with the system and it will take them not very much time to get prepared and show you how it works. Because on the next stage with the hands on testing, you will be doing it yourself but you will be doing it for the first time. So you're not aware of how the system works, there might be some not very conventional ways of doing stuff. And that will may influence your results. So it's a good idea to let people who know their product, show you how it works. And let's now talk move forward and talk about the hands on testing which is the following step after the after the demos and it is also called proof of concept right? In this stage you have you should have only shortlisted candidates, right. So after demos, you will after demos and RFI, you will definitely know who should be in the shortlist. And only those participants should be invited to take part in the POC proof of concept you may invite like everyone and do the testing for for everyone, but you should bear in mind that you will have to test them with your own hands and during your own work hours. And you still will have your regular responsibilities to do and they will take some time for you to actually do this testing. So, the testing process will require test access to the platforms and also several introductory calls with the participants so that they can show you around and show you how to perform some basic basic tasks. After that, you will have to prepare test cases some basic workflows with different maybe types of source files or different conditions or terms for for this project or for these workflows. It can be similar to what you did for demos, but it can be also a good opportunity to check what was not shown during the demo or what was not clear for you how it works during the demo. And you should work on three four scenarios, which will end up into 10 or 12 maybe test projects was in two platforms also it is recommended to work on this testing was the was in the groups and this test group should include all the roles right during the workflow. So it can be a requester project manager, subject matter expert LSP in house translator or whatever other roles you have. And regarding the timeline, it is yeah, from experience it is known that one month of POC will cover to candidate platforms. So it seems to be very easy you you're thinking okay, it's only 10 projects I manage If I don't know, hundreds of them during the week, right? And why can't I just do 10 projects within one day? Well, in reality, you will have to gather test groups, you will have to test each role. And again, you will be doing it in the system, which you don't really know. And it will take approximately two weeks to do one platform. Again, we're talking about testers who are who also have other responsibilities and they have to do their job right. So that is why in the beginning, I said that it's best to to have only shortlisted candidates in the in the POC part, as it is also very time consuming. So now let me quickly talk about this scoring POC scoring because it's a little bit different from from the RFI scoring. In this case, you will have to score each of your stories right here, I gave you an as an example, right? Three different stories, one from it, one from Project Manager and one from reviewer. For each story, you should have a story weight, which will be important in order to distinguish between the results, then you will have an answer whether it is possible, or not possible to do it like that. And as you describe that in your in your story, and then the complexity and then the final result will be calculated. It's just an example right of the formula, how you can calculate your result, but you can add achieved plus complexity and multiply by story weight, and then you will see the result, you will have to do the scoring for each of your participants and then compare the final results. That will give you a numeric result. And that brings us to the final decision actually how you should make your final decision. So final decision will be built on the basis of the numeric scores, which we just saw right after the POC, then it is also a good idea to have a SWOT analysis during the whole project. So basically, you start this strengths, weaknesses, opportunities and threats table in the beginning of your project, and you add their information as you go. So you add some information after RFI, then you add some information after demos after that after POC and you will have some kind of a story for you in front of you to see exactly what's strong strengths and weaknesses your participants have. Also, it can be a good idea to have a comparison of time loss and gain. You can draw a graph of your workflow and then add workflows was your participants. Let's say you have two final candidates, and you have three different workflows existing candidate one, candidate two, and you will mark in which steps you basically lose or gain some time. And that will be a very, very visual representation of which of the participants is the best variant for you the best option for you. In other parts of the final decision is negotiation of contract. It's also a good idea to negotiate contract with several participants, because in the end, you may have a situation where you have two pretty equal candidates and then one of them will not be very easy to negotiate with and another one will be more flexible, and then the decision will be on first right. And last but not least, again, a very important thing is to gather feedback from all the teams localization it content team sourcing management, and LSPs in house translators, everyone who can be actually engaged was in this project. And all of this builds up your final decision. So very quickly about some learnings, and then we will go to q&a if there are any questions. So basically, selecting ATMs will definitely take more of your time than you planned, that's for sure. Because it is from from the very beginning, it seems to be pretty easy project where you with your localization teammates will just decide what you want to have and then select contract on work done. But in reality, it is a cross functional project where you will have to also be pretty diplomatic and take into account all the requirements from different stakeholders and organizing and arranging this process will be challenging, and the more participants you have, the more time will be needed for that. Also, hands on testing is a very informative stage of of the process, and it is a must. So if you think that, for example, you will do the RFI, and then you will see the demos pre recorded by your participants or just shown on the live session, and then you make your decision. While that's not really how it will work, you will definitely see demos which are very nice, but you will still have questions, and you will want to have this hands on testing. Also, as I already mentioned, it is very useful to engage with all stakeholders, because that helps to get this 360 degrees view and not only the view of our localization team, you will take into account needs of all your stakeholders. And that will help to create a more straightforward process from creation of content to publication of localized content. And also, it is very important as well to prioritize your requirements. Because as I have said, you may have a very, very, very long matrix with so many requirements. But in the end of the day, you will have to decide which of these requirements are deal breakers and which are not. So basically, this is it from my side. And I'm open for questions if we have any. Max Morkovkin 27:16 Yeah, we have no data. Thank you very much for the presentation. So let's start with the one which get two votes. The question from Anna, how many providers did you have in the first round when you sent all the advice? Natalia Kurysheva 27:31 In the first well, actually this exercise was? Well, I should say that it didn't result in anything, it was more like a theoretical exercise. And on our side, because we had this huge initiative to rebuild the whole system. But we're still in in in the process of rethinking it. But when we were doing it, we had four participants in the beginning, and then we shortlisted it to two. Max Morkovkin 28:00 And another question from Anna, what is the difference between a standard and planned functionality, Natalia Kurysheva 28:05 standard functionalities, which is already in the system in the platform. So you basically can go and check it, for example, let's say, request or portal standard functionality, the portal is there, you can go and request a project. And then plan functionality can be something the platform or the company plans to release in the next releases. For example, they don't have, let's say, chat within the project, right where, I don't know LSB can communicate with a localization project manager. They don't have this functionality at the moment, but it is in the roadmap, and it is planned to be delivered within next two releases. Max Morkovkin 28:51 Okay, thank you. The next question from Carol Soloviev. Hello, Carol, thank you for choosing this conference, what were the main one two drivers for Agilent decision to replace your TMS. Natalia Kurysheva 29:07 Again, this is the overall initiative in the company which is ongoing and it is not like final decision yet. But we are kind of rebuilding the whole architecture. And we're looking into most optimal ways for us to connect our CMSs was our translation process localization process, and that's why we were looking into this issue into this question. Max Morkovkin 29:44 Okay, the question from David Chandler. What would you recommend someone who is the sole localization member in the company and need to convince all departments we need a TMS instead of XML and what list of TMS you recommend? Natalia Kurysheva 29:59 So I'm not going I'm going to recommend any list of Team TMS. Again, you can go to mimic the website and they have this atlas where they have all the TMS is listed and you can check which specific TMS will suit your requirements because it depends on so many factors, right. And for a solo localization team member, I would say it's for for management, it's necessary to see the numbers right how implementing this TMS will help them save money or gain some some money, right. And it is very useful to build this SWOT analysis where you can say, Okay, this is the existing situation, we have Excel, we manually download upload files, we communicate through emails, we lose this amount of time on all of that, and that is my time time of our colleagues and it is this amount of hours per i don't know one project or per one week or one month and so on, and calculate the cost of this right and then you can show but here is buying TMS it will cost this amount, but we will do a we will decrease this time loss here and we will make a smoother process, time to market will be faster, it will be there will be less miscommunications and stuff like this, just try to show what the difference will be. And, again, what I mentioned in the slide about final decision, whenever you have, let's say two workflows, compared one to another, and where you see that, okay, we have a lot of time loss here, here and here. And implementing a new TMS will help us make it faster. That is a very visual way to show why you need a new TMS. And, of course, it is also scary for management sometimes to see how much TMS may cost, right? Because Excel is for free. It's already in your computer. But you can also prove that if you guys want to have this amount of content to be localized, I need this amount of headcount, I cannot do it myself alone, right? This, this number of headcount will cost us this. So basically buying one TMS can save this amount of money within this timeline. So it's all about numbers and showing the difference, I would say. Max Morkovkin 32:42 Okay, I think we are almost running out of time. Anna and Renard, asking something that you have already answered, I guess, there was a question from rove. But I think we already have like, four people asking the question, so we can choose the winner who will get the book so it was unlucky real David? Yeah, actually three of them. Okay, Renard. Natalia Kurysheva 33:08 Do I have to choose right now? Max Morkovkin 33:11 Do you want to take some time? Yes. No, no, I Natalia Kurysheva 33:13 have. I think I want to give this book to this last question. Also. Because if you have something doing in Excel, obviously, this book about automating boring stuff with the help of Python will be a very helpful thing for you. Maybe you can do some automation yourself without buying a TMS or, or something like that. Max Morkovkin 33:36 Okay, very good. Thank you very much, David. You're the winner. So we'll share the book with you. And Natalia. Thank you for joining us today. Very nice.