- Lights-out Project Management
- Accounts Payable Automation
- The Blockchain Illusion
- A Final Remark
Another abuse of language is an affected obscurity; by either applying old words to new and unusual significations; or introducing new and ambiguous terms, without defining either; or else putting them so together, as may confound their ordinary meaning.
LSPs are typically intermediaries whose primary role is task coordination, which they pompously label as ‘translation project management’ as if it had anything in common with real project management. If it were so, most LSPs would have been following ISO 21500:2012 and hiring PMPs for years to cover project management positions. No one? Oops!
Anyway, this coordination function is supposed to add value to business translation work, although significantly increasing its cost. It should also smoothen processes while it often creates bottlenecks and clogs, conflicts, and disputes, especially between the team members, typically freelancing linguists.
Indeed, the fundamental reason for a company to outsource is to address tasks–and problems–they cannot or will not address directly as being outside the scope of their core business. For most companies, largely SMEs, translation is not part of their core business, and the need only arises in periodic but isolated circumstances. To these companies, outsourcing offers greater budget flexibility and control by allowing them to pay for the services and business functions they need, when they need them, while reducing capital, operating expenses, and risk.
For this reason, outsourcing the translations effort helps companies avoid an heavy burden of human resources, from recruitment to assignment and management of talents, as well as worrying about any plans for the career of in-house linguists. All they need is a manager to monitor milestones and take critical decisions related to the outsourced translation jobs. This is especially true when dealing with multiple languages and looking for scalability. In fact, localization follows a typical exponential growth path, with any new language doubling the task’s complexity.
Lights-out Project Management
Just like project management, CSA has been twisting the ‘lights-out’ attribute to suggest something completely different from the original meaning.
‘Lights-out’ is primarily associated with a manufacturing methodology involving full automation with no human presence on-site. The concept applies to factories where raw materials enter, and finished products leave with little or no human intervention, thus being able to run “with the lights off”. Companies implementing lights-out methodology only employ robotic workers, leaving human workers for tasks such as quality assurance. Assurance, not just control. Is it still necessary to highlight this distinction? Regrettably, it is, at least when dealing with translation and the translation industry.
Although today many factories are capable of lights-out production, still very few run exclusively lights-out.
Using historical data and machine learning applications to analyze content and route jobs is not running translation project management (whatever it is) with the lights off. Maybe it is ‘augmenting’ vendor management, which is or at least should be preliminary to project management, but it leaves all other tasks untouched.
This is where the typical narrative about the translation industry comes in, that translation project management is the lifeblood of every LSP, and the source of the value added to the basic service coming from freelancers, who ultimately do the actual work. Being LSPs heavily dependent on freelancers to outsource the jobs they receive from clients, they should have a large vendor base to draw on, as necessary. This vendor base should be painstakingly curated, with all information relating to each vendor constantly and accurately vetted and always updated. This should not be the responsibility of project managers, generally overburdened, who should however provide vendor managers with fresh information gathered post-mortem to update the vendor base. This project-related information will make up the historical data to fuel machine learning applications with. Unfortunately, we are still far from having a standard for this kind of data. On the other side, we have collected a long string of missed opportunities, wasting time and resource to develop a ‘universal API’ that is likely going to be forgotten rather than developing a model for project data (does TAPICC ring a bell?). But that is another story.
Like vendor management, also administrative tasks like managing invoicing and payments do not pertain to project management, and accounts payable automation can greatly help.
For all this, an all-encompassing, full-fledged TMS is necessary, which could handle all the tasks currently assigned to humans and make the service available automatically to customers.
If ‘lights-out project management’ were anything more than a knockout term to use at industry events, in flimsy articles and reports, or in small talks with colleagues to sound smart and brilliant, and it were even only a vague, remote, but an actual possibility for it, we would already be on the road of full disintermediation, when we are still far from this.
Accounts Payable Automation
Management of suppliers or trade payables is just as important as managing debtors or trade receivables. Slow or delayed payments may impact a business’s cash flow and credibility. Also, manual invoice processing carries a significant overhead cost.
Compared to manual handling, AP automation can help cut invoice processing costs dramatically (over fifty percent) while also removing errors, driving compliance, and ensuring timely and accurate data for the financial statements.
AP automation software extracts invoice data and populates it in the system, then processes invoice data for accounts payable, all running from a single dashboard.
AP automation workflow allows for processing vendor invoices without any human intervention up to electronic funds transfers, thus going a step further than the typical “ok-to-pay” once invoices are received and processed.
Obviously, an accounts payable automation system costs money. However, there are now SaaS solutions that allows for keeping implementation and operating costs extremely low, with starting prices as low as $20 per month.
Yet, no LSPs are in fact adopting these solutions, and the poor AP management is at the root of payment delays–when they are not part of fancy financing strategies in which vendors are treated as primary lenders–and originating a widespread perception of general unreliability, not just at vendors.
The Blockchain Illusion
Whereas simply reiterating an argument does not make it any stronger per se, no use case has shown blockchain’s potential for translation so far. Advocates insist on blockchain’s capacity of solving a long series of issues such as the lack of transparency, accountability, verifiable identity, and control of data, but they do not explain how. Maybe because they cannot.
For example, Bob Kuhns’s “very simple model [to] enable an ongoing, robust, and trusted Buyer-to-Translator business connection that could quite possibly reduce the role of LSP middlemen” is only a rough sketch.
In fact, to move from potential to viable, something more is necessary than listing what blockchain is expected to do, in a purely ideal perspective. For example, how would blockchain be implemented in a TMS? And to do what exactly? How? Which issues would smart contracts solve? How would smart contracts outperform current ways and technology of running a translation business?
Also, is any use case available even remotely related to the translation business? All current, rare implementations of blockchain outside the cryptocurrency field are quite expensive and typically pertain to corporations that can afford to invest (even in the dark) into complex technologies, possibly with the help of some expensive consulting company. Would it be surprising to know that IBM is the top blockchain developing company?
Tracking a container and its content is much more complicated and far more costly on an everyday base than managing a translation/localization project, however large this may be, sporadic anyway. Wouldn’t blockchain be a bit of an overkill, at least in a financial perspective? Wouldn’t it be like using scud missiles against thrushes?
In his recent post, Bob Kuhns does not show how blockchain would actually bring equity to translators while streamlining the translation workflow. Indeed, all the fundamental questions about blockchain in the translation industry asked before in the same space have been left unanswered.
Also, as Bob Kuhns himself admits, “the technical obstacles are huge,” and the translation industry is certainly not at ease with changes especially when involving huge technical obstacles. And if it is true that “the overhead of LSPs drives up translation costs”, maybe there are less expensive and readily available technologies that could help solve this problem. See the section above.
Finally, always quoting Bob Kuhns himself, “despite all the hype and predictions, blockchain technology is in its infancy and its future remains uncertain”.
At this point, one more question must follow the ten questions in What’s Cooking?: What is the cost of developing a blockchain application?
There are several blockchain development platforms like Ethereum, HyperLedger Fabric or Hydrachain, but the most significant expense is for blockchain developers as the highly specialized nature of blockchain requires highly qualified people to work with it.
So, blockchain app-building requires a considerable investment, substantially larger than standard development. In general, a blockchain project can cost from $ 20,000 for a public blockchain to over $ 125,000 for an enterprise blockchain. A public blockchain project might cost less because the platform does not have to be built from scratch.
Can an average LSP afford such an investment? Perhaps, some willing LSPs could form a consortium of companies, possibly through a trade body, to entrust with the development of a public blockchain that would later become a common platform. However, given the outcome of TAPICC, is it realistic to think that such a scenario could materialize?
So, the answer to the question of whether blockchain in the translation is really possible or it is just a pipe dream that will never materialize cannot but be “no, it is only gibberish”. And if asking what it might accomplish, it would hardly solve even only one of the chronic issues of the industry, let alone helping the development of new capabilities.
A Final Remark
It is not wrong to try and imagine the future, nor it is wrong to try and do it with the available technology. However, to make this effort not a sterile exercise and an end in itself, it is necessary to be specific and honest, without manipulating the language to fake ingenuity while having little or no idea. So, it is necessary to present use cases that, if not realistic, are at least consistent with a vision.