Best practices for implementing and rolling out a memoQ server in an organization
•Download as PPTX, PDF•
0 likes•868 views
In this joint presentation, Miklos Urbán from Kilgray and Daniel Zielinski from Loctimize will share some best practice advice on how to successfully implement and roll out a memoQ server in an organization. The presentation covers both initial implementation and rollout as well as the rollout of updates. The focus of the presentation will be on enterprises and language service providers. Miklos and Daniel will give an overview of the different stages in the implementation and rollout process from planning and preparation to the go live. The different challenges in each stage will be outlined and solutions to overcome these will be presented. During their presentation, different examples from the presenters’ daily work and from some of their case studies will be shown. At the end, the audience will take away a checklist with valuable best practice advice for each phase of the implementation and rollout process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Best practices for implementing and rolling out a memoQ server in an organization
Similar to Best practices for implementing and rolling out a memoQ server in an organization (20)
Recently uploaded
Recently uploaded (20)
Best practices for implementing and rolling out a memoQ server in an organization
- 1. Best practices for implementing and rolling out a memoQ server in an organization Daniel Zielinski Loctimize GmbH Miklós Urbán Kilgray Translation Technologies
- 2. Topics • The challenges • How to tackle them • Typical problems and pitfalls • Best practice
- 3. What does successfully mean? • In a timely manner • Within the planned budget • Happy users ;-) How to SUCCESSFULLY implement and roll out memoQ server in an organization
- 4. Kick-off and planning Custom develop- ment System setup Implementation and rollout project: Standard steps Testing Go Live Follow-up meeting Impl. sign-off Migration Training
- 6. Scenarios Brand new tool, no CAT before Changing from a different system to memoQ Upgrading from the previous memoQ
- 7. LSP • Translation is main process • Many different clients • Many workflows, some unique to a project/client • More dynamic list of users and language pairs • Flexibility of memoQ is a requirement • Other CAT tools Enterprise • Translation is supporting process • Not too many (internal) clients • Small number of well defined workflows • Static list of users and language pairs • Standardized source files • Automated preparation steps • Integration flexibility General comparison
- 8. LSP • Often manual assignments of linguists • Project change management • Slicing files • Overlapping workflows Enterprise • Using subvendors • Static translators and/or teams • Use of FirstAccept • Internal reviews by non- linguists • Package workflows General comparison
- 9. • Analyze & define workflows and processes Preparation Ordering Project creation Preparation Quoting Task assignment Monitoring Translation Review Quality assurance Project completion Archiving Resource management Invoicing Automation Integration
- 10. • memoQ server vs. cloud server • In-house vs. hosted • IT environment (hardware, software, network, login, licensing) • Separation of database, application and web server • Redundancy of systems • Data security • Backup strategy System setup and configuration
- 11. LSP • Less complex IT environment • External or small IT department • Often less focused on information and data security Enterprise • More complex IT environment (Active Directory Forest, network security) • Large IT department • Often heavily focused on information and data security System setup and configuration
- 13. • Users, groups, rights • Translation Memories, termbases including meta data • Leverage loss due to different segmentation and tagging • Other resources: file filters, segmentation rules, TM settings, non-translatables, reference documents... Migration
- 14. LSP • More likely to have linguistic assets (TM, TB, file filters) • Linguistic assets from multiple legacy systems • Linguistic assets are often diverse • Many users Enterprise • If any, often single tool to migrate or files to align • Less resources and users • Higher expectations in terms of lowering leverage loss • In some cases files for structural alignment are available for 100% leverage Migration
- 15. • Linguistic configurations • translation memories, termbases, auto-translation, non- translatables • User interface • software options, how the software behaves • API based tools, plugins and sponsored development Customization
- 16. LSP • Linguistic resources to be customized for a lot of clients and many languages • Set up of effective usage of the diverse linguistic resources Enterprise • Linguistic resources customized only for one (or a few) usecases and limited number of languages • Often client specific development is needed, e.g. automated QA Customization
- 17. • Systems managing/storing content • Systems managing workflows, projects, financial information • Content connectors, API Integration
- 18. LSP • Excel • Project management systems • MT systems • QA tools • Other memoQ server Enterprise • Content management systems • Product information management systems • Document management systems • Marketing automation systems • Workflow management systems • Accounting systems Integration
- 19. • System testing • Performance testing • Functional testing • Usability testing • User acceptance tests (UAT) Testing
- 20. LSP • Often only usability and functional testing • Only partial testing (not entire workflow or business logic) Enterprise • Testing and test protocols part of implementation projects (IT requirement) • More used to systematic testing • Tests often done by IT people that do not test functions Testing
- 21. • Standard training • Customized training • for different user groups • with specific content to the needs of those users • Continuous training Training
- 22. LSP • Often just kick-off training • We can figure it out ourselves • Training on the job • Learning by doing Enterprise • Used to software training (no solution rolled out without training) Training ⚡ Generic “marketing” resources such as webinars ⚡ Training in addition to daily workload ⚡ Too little time for training planned ⚡ Training outcome often not evaluated ⚡ Often ineffective training
- 23. Go Live • IT and support on stand-by • Party & prey!
- 24. • Change management • How to manage change in software projects: information of affected user groups, include users in evaluation of changes e.g. software updates, process changes Communication
- 25. • IT infrastructure • Processes • Standard operating procedures • QA manual Documentation
- 26. • Implementation of a feedback process • Regular assessment of current practice • Evaluation of new functionality • Alignment with market needs and business strategy Continuous improvement
- 27. Conclusion • Plan wisely • Communicate • Involve all stakeholders • Test • Train • Continuously improve
- 28. ThanQ!
Editor's Notes
- What we are going to talk about
- Daniel: memoQ has become an increasingly complex solution Also IT infrastructure and other software solutions have become more complex This is in alignment with differing requirements on the clients‘ side and some general industry trends This means that implemetation and rollout projects have become more complex than maybe 10 years ago. Transition to next slide: But how do we get there? IT > PM > engineers > TR (int, ext), subvendor > RV > QA > Accounting > Clients Everybody involved in the project should be happy when the solution is implemented and rolled out!
- Miklós: Perspective of a software company Project starts when the client hopefully has selected the right solution to be implemented or at least trialed, e.g. components, interfaces, automation etc. (plenty of stories where implementations went wrong because client thought he had the right solution, e.g. when at an enterprise client being asked during a training where the translatables will come from or where it needs to go back…) Some companies have more awareness on software implementation, whereas other companies may lack of such knowledge and experience. Many has a very „clear” view of what they want in terms of implementation, and hence the first major challenge is to align client’s implementation process vision with the standard steps of the implementation process. No insight into data, clients, prices. No intention to moe eway traditional workflows. Want to have everything the same way as it used to be. Many people tend to use software anyway the default way as they are downloaded, installed. For a complex and flexible system like memoQ server and all its extension points it is of uttermost importance that the system is customized to the particular environment. Steps that normally cannot be avoided are as on the slide. One thing we really want to convey with this presentation is that a software implementation is a process that needs planning and has certain inevitable steps. And its never late to rethink the implementation.
- Daniel: In order to be successful when implementing and rolling out a software solution all layers need to be aligned. The goals need to be clearly defined. Data: does the client have linguistic data, if so what kind of data, in which format, do we need to migrate data, convert it…? People: difference between users with different background, different experience with CAT tools, software or IT in general, Implementing a new software or even upgrading an existing one presents some risks. Clients and software providers are often talking a different language Strategy (What does a client want to achieve with memoQ? What do the different stakeholders fear? How to get broad acceptance for the solution?) Processes (Current vs. future situation) Technologies / Tools (HW/SW systems involved and their dependencies, how does memoQ fit in?) Data (existing vs. new data) People (current stakeholders, their currents tasks and responsabilities vs. future, what changes, reluctance to change or even fear) Transition to next slide: Let‘s dive in and see what challenges each implementation and roll-out step might present
- Miklos: For each areas we go through the major considerations one needs to think of during the implementation. Some of these will be common for most types of companies using memoQ server, but there are also aspects that substantially differ in an LSP environment and an enterprise environment.
- Daniel starts: Before the implementation starts and even before a software solution is selected, all relevant processes and workflows in a company need to be defined and/or analyzed. Both sides, the client including all affected stakeholders and the software implmentation specialists need to understand how processes should work, what should come out of each process and what the tasks and responsabilities are/will be. Here also secondary processes such as resource management need to be taken into account. It is important that all stakeholders affected by the implementation and rollout project are taken into account as everybody contributes with his/her experience. Often and quite naturally the new system is expected to be more flexible to accomodate special requests in terms of the workflow. Workflow diagramm with some table to define differences, options and so on
- Daniel starts: Before the implementation starts and even before a software solution is selected, all relevant processes and workflows in a company need to be defined and/or analyzed. Both sides, the client including all affected stakeholders and the software implmentation specialists need to understand how processes should work, what should come out of each process and what the tasks and responsabilities are/will be. Here also secondary processes such as resource management need to be taken into account. It is important that all stakeholders affected by the implementation and rollout project are taken into account as everybody contributes with his/her experience. Often and quite naturally the new system is expected to be more flexible to accomodate special requests in terms of the workflow. Workflow diagramm with some table to define differences, options and so on
- Daniel starts: Before the implementation starts and even before a software solution is selected, all relevant processes and workflows in a company need to be defined and/or analyzed. Both sides, the client including all affected stakeholders and the software implmentation specialists need to understand how processes should work, what should come out of each process and what the tasks and responsabilities are/will be. Here also secondary processes such as resource management need to be taken into account. It is important that all stakeholders affected by the implementation and rollout project are taken into account as everybody contributes with his/her experience. Often and quite naturally the new system is expected to be more flexible to accomodate special requests in terms of the workflow. Workflow diagramm with some table to define ifferences, options and so on
- Miklos starts: What exactly does the system setup comprise? Preparation of the IT infrastructure, hardware (servers), software (SQL Server, Web Server, Application server, Virtualization), network configuration, planning redundancies, data security, backup strategies Installation and configuration of the different system components (memoQ server, memoQ web, qTerm, content connectors, licensing system etc.) System testing
- LSP anecdote: A few weeks back an LSP implemented a memoQ server. Client relevant data such as TMs, terminology and first projects have been uploaded and shared on the server. The server was immediately made accessible from the internet. Everything worked fine. Also the login credentials admin:password. Enterprise anecdote: Once upon a time there was an enterprise that implemented memoQ server with Plunet. After starting to use the solution internally, the enterprise wanted to roll out the solution to their LSPs and integrate them into the process. This was about a year ago. The enterprise is still not working with the external LSPs as all systems are well hidden behind a firewall. To access the internal network a complex process using grid cards is needed. Initiall tests revealed that the login procedure was taking around 10 to 15 minutes. Direct access via the secure connection to the memoQ server is still not possible. Opening the communication ports to the memoQ server was impossible due to IT security policy. And the story goes on...
- One important step during an implementation and rollout project is to locate any existing data to be used in memoQ. While some people only think of the obvious translation memories and termbases there can be much more data such as Information on users and groups, pricing information, system settings such as TM settings, file naming conventions, lists of product names, abbreviations, reference documents, style guides that can be translated into QA rules etc.) These days it happens quite seldomly that you can implement a software solution in an isolated environment or on the green-field
- One important step during an implementation and rollout project is to locate any existing data to be used in memoQ. While some people only think of the obvious translation memories and termbases there can be much more data such as Information on users and groups, pricing information, system settings such as TM settings, file naming conventions, lists of product names, abbreviations, reference documents, style guides that can be translated into QA rules etc.) These days it happens quite seldomly that you can implement a software solution in an isolated environment or on the green-field
- When it comes to customization we can say that memoQ is working very well out of the box but it is performing much better when customized to a client‘s specific needs and requirements. To give you some examples of customizations: Add users, define access rights for resources (?) Translation Memories: Define number of TMs to be used per client / language pair, how to use project meta data to structure a TM Termbases (qTerm): Customize the entry structure of the termbase to fullfil client‘s requirements for specific information to be stored, different workflows etc. Abbreviation lists: Add client-specific abbreviations to the relevant segmentation rules right from the beginning in order to improve segmentation and leverage from the TM. And in order to avoid any complaints from users that spot segmentation differences and reduced leverage compare to a previous system. Non-translatable lists: Add proper names and product names as non-translatables in order to signal these for translators and reviewers. Nothing worse than a client complaining about translated or misspelled product names. QA rules: Translate the QA requirements of a client into QA settings profiles. E.g. to check for common mistakes or custom patterns. Auto-translation rules: Add rules to show to translators and reviewers how client-specific textual patterns need to be translated, and help them save some time when typing. Templates: Setup templates for ccustom auto-translation ommon project types Setup connections to content sources Define archiving processes through automated exports and/or API scripts „Scriptify” the file preparation and postprocessing steps and integrate into memoQ
- When it comes to customization we can say that memoQ is working very well out of the box but it is performing much better when customized to a client‘s specific needs and requirements. To give you some examples of customizations: Add users, define access rights for resources (?) Translation Memories: Define number of TMs to be used per client / language pair, how to use project meta data to structure a TM Termbases (qTerm): Customize the entry structure of the termbase to fullfil client‘s requirements for specific information to be stored, different workflows etc. Abbreviation lists: Add client-specific abbreviations to the relevant segmentation rules right from the beginning in order to improve segmentation and leverage from the TM. And in order to avoid any complaints from users that spot segmentation differences and reduced leverage compare to a previous system. Non-translatable lists: Add proper names and product names as non-translatables in order to signal these for translators and reviewers. Nothing worse than a client complaining about translated or misspelled product names. QA rules: Translate the QA requirements of a client into QA settings profiles. E.g. to check for common mistakes or custom patterns. Auto-translation rules: Add rules to show to translators and reviewers how client-specific textual patterns need to be translated, and help them save some time when typing. Templates: Setup templates for ccustom auto-translation ommon project types Setup connections to content sources Define archiving processes through automated exports and/or API scripts „Scriptify” the file preparation and postprocessing steps and integrate into memoQ
- Integrate memoQ with content sources via content connectors or API in order to monitor content sources and automate project management tasks such as project creation or project modification upon a change of project files. Integrate memoQ with language terminal to generate quotes, convert InDesign files etc. Integrate memoQ with any workflow or project management system such as Plunet, XTRF or custom systems at client side.
- Integrate memoQ with content sources via content connectors or API in order to monitor content sources and automate project management tasks such as project creation or project modification upon a change of project files. Integrate memoQ with language terminal to generate quotes, convert InDesign files etc. Integrate memoQ with any workflow or project management system such as Plunet, XTRF or custom systems at client side.
- Testing is very often underestimated. Often software solutions are implemented before being thouroughly tested (sometimes even at the software company‘s side ;-) There are different types of tests that should be done at different stages of an implementation project: System testing: Usually done during and after system setup. It ensures that the software solution works correctly in the environment. Functional testing: Usually done after system setup and during the evaluation. Functional tests should ensure that all software functions defined in the client‘s specification work (as expected). Then the documentation of this test should be maintained and carried out before each update of the system to ensure problemfree operation. Usability testing: Often done together with functional testing. Usability tests focus on how easy it is to do do something in a software product, e.g. to create a project in memoQ, to assign users to tasks, to complete a project etc. User acceptance tests: Usually done after the user training. UAT should ensure that the software solution works fine for every stakeholder in the process. One important thing is to define all tests in a way that is repesentative and clear result will be obtained from the tests. Test cases should be not too loosely defined. They should cover the most important areas a users touches in the software. For all tests it is important to leave room for feedback from participants. Corresponding test templates can be found online. Also testing needs preparation, documentation, execution, evaluation, and thus TIME!
- Testing is very often underestimated. Often software solutions are implemented before being thouroughly tested (sometimes even at the software company‘s side ;-) There are different types of tests that should be done at different stages of an implementation project: System testing: Usually done during and after system setup. It ensures that the software solution works correctly in the environment. Functional testing: Usually done after system setup and during the evaluation. Functional tests should ensure that all software functions defined in the client‘s specification work (as expected). Then the documentation of this test should be maintained and carried out before each update of the system to ensure problemfree operation. Usability testing: Often done together with functional testing. Usability tests focus on how easy it is to do do something in a software product, e.g. to create a project in memoQ, to assign users to tasks, to complete a project etc. User acceptance tests: Usually done after the user training. UAT should ensure that the software solution works fine for every stakeholder in the process. One important thing is to define all tests in a way that is repesentative and clear result will be obtained from the tests. Test cases should be not too loosely defined. They should cover the most important areas a users touches in the software. For all tests it is important to leave room for feedback from participants. Corresponding test templates can be found online. Also testing needs preparation, documentation, execution, evaluation, and thus TIME!
- The challenge in training is that depending on the client, the knowledge on technologies, tools, processes can be quite different ranging from absoulute beginners to experienced users. And all these different people can be in the same training group. The training needs to address these differences. Training should be customized for each client in order to address the specific learning needs of the different user groups. The training plan should reflect what exactly every user group should know about and to be able to do with memoQ. Instead of having a 3 days training for all users, training could be divided into different modules for each user group. Depending on the work schedule, there could be parts for the whole audience, parts for specific user groups while others do exercises etc. Training should also reflect the client‘s workflows, use relevant training sample files etc. As for the testing, training needs time: Time for participants to learn, reflect about what they have learnt and to put it into practice. Unfortunately, very often too little time is planned for training. And very often there is no evaluation of the training outcome, e.g. if project managers can now create projects with advanced settings, manage more projects in the same time etc. So the ROI of training in general is often not calculated at all or it is considered to be a „savings” from the cost of the tool, as „inhouse people are able to learn the tool by themselves”. The effectiveness of a well-planned custom training is shown by many examples.
- The challenge in training is that depending on the client, the knowledge on technologies, tools, processes can be quite different ranging from absoulute beginners to experienced users. And all these different people can be in the same training group. The training needs to address these differences. Training should be customized for each client in order to address the specific learning needs of the different user groups. The training plan should reflect what exactly every user group should know about and to be able to do with memoQ. Instead of having a 3 days training for all users, training could be divided into different modules for each user group. Depending on the work schedule, there could be parts for the whole audience, parts for specific user groups while others do exercises etc. Training should also reflect the client‘s workflows, use relevant training sample files etc. As for the testing, training needs time: Time for participants to learn, reflect about what they have learnt and to put it into practice. Unfortunately, very often to little time is planned for training. And very often there is no evaluation of the training outcome, e.g. if project managers can now create projects with advanced settings, manage more projects in the same time etc. So the ROI of training in general is often not calculated at all or it is considered to be a „savings” from the cost of the tool, as „inhouse people are able to learn the tool by themselves”. The effectiveness of a well-planned custom training is shown by many examples. Anecdote: LSP or enterprise client not knowing that there is something like cascading filters or not knowing the difference between master, working and project TM and how to use them.
- Documentation assures that different stakeholders understand how to use a software, what the standard operating procedures are, why things are done the way they are done etc. Documentation of processes and data is a requirement of many industry standards. Documentation allows faster onbording of new users, reduces calls to the support hotline. The challenge with documentation is often who is responsible and how detailed / nice should the documentation be? There are many different solutions available to document – from simple Word documents to WIKIs, blogs, support systems etc.
- Documentation assures that different stakeholders understand how to use a software, what the standard operating procedures are, why things are done the way they are done etc. Documentation of processes and data is a requirement of many industry standards. Documentation allows faster onbording of new users, reduces calls to the support hotline. The challenge with documentation is often who is responsible and how detailed / nice should the documentation be? There are many different solutions available to document – from simple Word documents to WIKIs, blogs, support systems etc.
- Reality: Often no assessment on how a software is used after a certain time. Often users only use a fraction of what the software offers. Sometimes users are not even aware that things could work much easier. New functions in a software and the new possibilities are often not evaluated buiness-wise.