Recommended
Recommended
More Related Content
What's hot
What's hot (16)
Viewers also liked
Similar to TMS Deployment (ALC12)
Similar to TMS Deployment (ALC12) (20)
TMS Deployment (ALC12)
- 2. TMS Deployment A Composite Case Study Bob Donaldson Carson Strategy Group
- 3. Components of a TMS Project/Vendor Management Staff Sales Staff Vendor Management Customer Workflow Management Quote Relationship & Project Reporting System Management Collaborative Customer Job Submission Web Vendors Translation Subsystem Portal s Environment MT Vendor DB TM Management Job DB Customer DB Invoices/AP Financial System Invoices/A R Executive Management & Finance Dept.
- 4. PM/VM HR Fin TMS: R&D Before & After Prod Trans (The Vision) Mktg -lator Edit & PM/VM QA HR Fin Customer R&D Integrated Vendor Portal TMS, TEnT& VMS Portal Prod Trans Collaboration -lator Mktg Platform Edit & QA
- 5. Hidden Dangers Customer Vendor Portal Integrated Portal TMS, TEnT& VMS Collaboration Platform
- 6. How hard can it be? • Custom Development? – Been there; done that Customer • Product Demos? Vendor Portal Integrated Portal TMS, TEnT& VMS Collaboration – Hidden assumptions Platform • Process Improvement? – Limited vision => Limited ROI • Time for Planning? – Are you kidding?
- 7. Common Sense Advisory Data: Average Time to Deployment Source: TMS Users Revealed, Common Sense Advisory, May 2012
- 8. Draining the Swamp • Getting Started – Where are you now? – Where do you want to be? • Counting the Cost – True cost of change – True cost of doing nothing • Evaluating Options • Planning Deployment – Setting Expectations – Configuration – Communication
- 9. Getting Started: You are Here • What do we have? • What do we need? – Current – Future • Gap Analysis • Build vs. Buy
- 10. Counting the Cost: • True cost of change – Training – Process change – Customer/Vendor impact – Migration costs • True cost of not changing – Limited efficiency – Limited flexibility for … • New project types • New business models • New technology opportunities
- 11. Evaluating Options: Vendor Selection • Initial Screening – Visit their booth! – Standard Demo • Product Evaluation – Detailed Demo – “What If” Discussions – References • Vendor Evaluation • Pilot Testing
- 12. Planning for Deployment • Configuration Custome – Data Migration Integrated – Integration Vendor r Portal Portal TMS, TEnT& VMS Collaboratio n Platform – New Capabilities – Training • Communication – Internal Stakeholders – External Stakeholders • Cut-Over – Big Bang vs. Gradual
- 13. To go, or not to go (live)? • Internal staff training? • External expectations managed? • Parallel operations possible? • Gradual cut-over an option? • Deployment support team in place? • Vendor support available? • Emergency fall-back plan?
- 14. Lessons Learned • This is hard – (Especially the deployment) • A thorough pilot is worth months in deployment – Training matters • The devil is in the details – The right set-up saves time – The right set-up is not always obvious – The right set-up requires new processes • It is never a “good time” – Busy-ness is our business – Priority has to come from the top !!
- 15. Good to Keep in Mind “The perfect is the enemy of the good” - Anonymous Do not lose sight of the goal just because you run into a few problems
- 16. PM/V M Customer Integrated Vendor Portal TMS, MT, TEnT& VMS Portal Translator Collaboration Platform Edit & QA Questions or Comments?
- 17. Contact Details BOB DONALDSON +1.512.680.2595 Bob@CarsonStrategy.com 17
Editor's Notes
- Before & After vision
- As with many other small businesses, Language Service Providers (LSPs) often wade into the technology swamp without fully recognizing the difficulties and dangers lurking there. Many LSP’s have already learned this lesson with their own proprietary development efforts, but shouldn’t we be able to avoid the problems if we simply buy a third party tool? How hard can it be? Perhaps this brief case study … or really composite case study covering a number of specific cases … will illustrate some of the pitfalls in a way that will allow you to avoid overestimating or underestimating difficulty when answering that question.
- Among the hidden dangers:Custom Development is more costly than it looks and leaves you with a maintenance headache that will never go awayProduct demonstrations show ease of use in full operations on a limited set of customers/projects/vendors/etc. Real life is more complicated and *nobody* gives you any perspective on the initial configuration and data migration effort required.Process improvement (not process automation) is the goal; without changing processes to match capabilities of new system, ROI will be limited.Nothing happens automatically; deployment planning (and the configuration tasks to be planned for) take time and commitment.
- Time to first live project.
- it is important to remember that technology alone is not going to solve all the problems. As Ben Sargent (Common Sense Advisory) has recently observed, changing technology without addressing the underlying processes will limit the ROI of any technology investment. Be creative in running “what if” scenarios, even if not all of your scenarios end up being supported by the chosen system. Managing expectations is an important part of managing a successful technology transition.In all of this it is important to look at where your business is going, not where it has been when evaluating options. One thing is certain … the way you are operating now will change with the new system.
- The first thing needed when planning a journey is the starting point. This is often more important than the destination, because it is possible to alter your destination en route. An initial assessment of options should include:How well does our current system support day-to-day operations?What is the true cost of ownership of the current system?Which repetitive processes (or tasks) are candidates for automation?What is our budget for investment and our expected ROI?Too often, system “requirements” are simply derived from current processes, forgetting that the processes themselves often have their roots in a possibly inadequate technological environment. The best approach here is to put together a relatively short, high-level description of what is needed to run the business more efficiently. In our “case”, this included requirements for improved financial reporting, improved visibility into costs incurred for various types of projects, improved automation of repetitive tasks, improved ability to integrate with external partners and improved support for collaborative workflows.In all of this it is important to look at where your business is going, not where it has been when evaluating options. One thing is certain … the way you are operating now will change with the new system. Armed with a “wish list”, we are then able to do a “gap analysis” on the current system, identifying areas where a change would provide value. Similarly, we are able to pre-screen potential third-party tools against the same list. This provides a much better starting place than trying to evaluate competing vendor claims. In most cases, the “build/buy decision” is pretty easy to make and comes up “buy”. Typical factors include the recognition that technology is changing the business environment, and that the ability to integrate with external systems and to support collaborative approaches to delivering language services is becoming essential. Sharing the cost of that capability set with other customers is (usually) the obvious financial choice.
- Whether you choose to build or buy, vendor selection is the next step. Even in a “build” situation, it is rare that you will want to rely totally on internal staff for the initial development effort. In the typical “buy” case, though, this is especially important.All demos look good; the key at this point is to look beyond the demo at the details that will affect your deployment costs and ultimate satisfaction. Demos will typically focus on one or two “standard” processes and amaze you with how easy it is to use the system for those processes. There are three ways this can be misleading.The language services business is a lot more diverse than is commonly recognized. Processes that make sense for one segment of the market may not be appropriate for another. Most or all of the tools on the market focus on “traditional” localization projects. As non-traditional workflows associated with agile localization, user-generated content, collaborative work environments, multi-media localization, etc. are introduced, this can challenge the flexibility of the system. It is not obvious how much time and effort went into setting up the “master data” in order to make the demo project management go so smoothly. How is it organized? How easy is it to change if needed? How are more complex situations handled?Evaluate the vendor, not the toolOne of the key advantages of doing a detailed pilot on your own equipment is that it provides an opportunity to evaluate the vendor’s support system as well as the tool. In most cases, a detailed pilot will also identify feature gaps. How does the vendor respond? One of the key advantages of a third party solution is (or should be) the ability of the vendor to aggregate demand from multiple sources and provide new features and functionality at a rate that would not be possible with an internal development team, so having a “voice” with the vendor is an important aspect of the evaluation.In order to run an effective pilot test, all areas of the system need to be exercised within the context of your range of projects. This will require substantial investment in training, system set-up and configuration, and actual staff time running different scenarios. As such, it is best to start with the “leading candidate” from the first round of screening. Do not be surprised, though, if first impressions turn out to suffer from closer inspection. Do not consider this as “lost time”, but as “disaster avoided.” Then use the lessons learned to streamline the next pilot and (eventually) the processes to be implemented.
- The actual deployment of the selected tool is where the success or failure of the whole project is determined. A successful deployment cannot happen apart from the commitment of time, energy and emotional support on the part of key management and project management staff. It will not “just happen”, and being too busy to make it happen right will just ensure the project’s failure. Unfortunately, there are too many stories circulating about third party tools that never worked and too little time spent asking how better deployment planning might have made a difference. There are at least three (and often four) areas touched on by this planning effort. Data migration and system configuration Integration with other systems (usually) Training and communication Final cutoverData migration and system configuration are handled together, because it is typical that “data” in one system becomes a “setting” in another. Some of the effort here becomes evident during the pilot phase, but there are a huge number of details to work out. Furthermore, the new system will probably enforce certain data integrity rules that will cause problems if the legacy system has duplicate or obsolete data. Often there needs to be a balance between the time savings of bulk transfer and the opportunity to clean up legacy data and establishing correct relationships in the new system by entering data by hand.During the pilot phase, it is not feasible to involve all staff. Once the decision is made to proceed with a particular solution, though, staff training and communication becomes a higher priority. In our composite “case study”, we communicated regularly with project and vendor management staff and held a series of hands-on training sessions as part of enlisting their support in the data migration efforts. This has the added benefit of enlisting the collective wisdom and creativity of the group in revamping processes and working around any system shortcomings.Effective communication with external stakeholders is also essential. In our “case”, we involved a handful of key customers in the final stages of deployment planning. Similarly, the new system provides substantial benefits to our vendors, especially in the area of managing the business communications (purchase orders, invoices, etc.). Including them in the run-up period is crucial to a successful final deployment. If vendors are confused by the changes, it will be very difficult to manage our customers’ expectations properly.
- At some point the decision has to be made … to go or not to go (live)? And there is a related question, of whether to go “all at once” or gradually. It is important to minimize the risk when making the final decision to put the new system into production, but it is also important to acknowledge that there will always be some problems associated with using the new system. In an effort to minimize both the risk and the number of problems, consideration needs to be given to the following questions: Have the internal staff been trained on the new system well enough to accomplish their daily tasks? Is it possible to run the old and new systems in parallel? Often this is not feasible, but it at least has to be considered. Is it possible to move to the new system gradually (by customer or project or project manager)? Again, in many cases this is problematic. Is there a deployment support team assembled with both the authority and skills to solve problems that arise? Is there vendor support available should something unexpected turn up at the last minute?
- The good news is that when care is taken with the business requirements, vendor selection, expectation management and deployment planning, there is a strong probability that you will also see the hoped-for ROI. This can come from decreased operating costs, lower true cost of ownership, increased ability to serve current and new customers and increased ability to take advantage of new technologies.From: Daniel Rejtö <Daniel.Rejtoe@plunet.com>Date: April 2, 2012 12:09:07 PMHere are some points from our Implementation Specialist Laura Cortés. BR, Daniel - A typical issue is that the client expectations are not clear, weather it is because they were not made clear during the sales process or because the client did not take the time to investigate/test that what they were expecting is what they were getting. A big issue is how much detail is explained during the sales process or how little the client wants to go into detail about a certain aspect. An example, if tracking and calculating commissions is very important to the client, they need to make sure to know how this works and that it works for them considering the different ways of doing this, not just ask if commissions can be handled or not. At the same time, on the sales side there are things that are used as selling points that don’t really work or work only in special scenarios, and the client believes they are getting something different than what they are told. In this case, it would be better to make sure these special things will work well for the client before selling it.- The problems you mention: no Plunet administrator or not doing their homework is very common and leads to a lot of issues, specially the first one. Another problem I encounter is that people on the client side, sometimes even the implementation managers think that all softwares are easy to use and you will get the hang of it when you start using it, so they don’t pay much attention on the meetings, work on something else (you can hear them typing or find yourself asking a question and not getting an answer) or put pressure on their teams to do simulations, practice and prepare before they go live. I tell all my clients that Plunet is not an iPod, because they need to understand how it works and practice in order to learn it and use it effectively. I tell them that the trainings are like classes where you pay attention, take notes, and go back to it after the meetings to review. A lot of people don’t realize the amount of work and effort that is involved in implementing a system like this.- There is only so much you can do in terms of helping other people learn something (you cannot think or learn for others). When you send them homework you know if they have done it in the next session or even before if they have already started sending questions. Reviewing what you did the previous sessions helps but when they haven’t done anything then you have to continue, sometimes for example even if you have insisted on them doing their templates they don’t do them until they go live. A lot of times this comes from management and how they are making this happen on the company side. By the second software training I expect people to already know their way around the system and I can tell if they are not taking it seriously, so I mention that they need to practice and I give them ideas on how to practice and run simulations (like recreating real projects in Plunet simultaneously while they are doing them the traditional way).On May 8, 2012, at 1:49 PM, AndrzejNedoma wrote:list the main success factors for a successful implementation. So the points you asked me for are:One internal implementation leader on the customer sideCentralising all communication on that person (from inside of the company, and from XTRF team). In that way client employees are not asking the same questions many times and they get the best answer speed - from their internal leader.Technical background of the internal leader - we have several cases showing that if this person understand technical aspects at least to some minimal extent, that all implementation process goes smootherKeeping to predefined implementation calendar - better to meet for shorter time but regularly, without too long brakes between meetings / training / sessionsPrioritisation of issues - there are many questions to be answered or solved during the implementation process. If all is urgent then nothing is urgent. So a good prioritisation help sort all things much quicker, without mixing general issues with very details and minor ones.Understanding that implementation is a process, that takes time and requires resources, i.e. people time and involvementMaking it clear by the managing team to all employees what are the goals that the company wants to achieve with implementation of the new system. So that all people see the big picture and do not focus only on minor details
- We will display this at the end and during the early part of the break.