Nearshoring Finalization
Internalize External Knowledge
Nearshoring work done, final milestones closely ahead, market entry within reach. And of course, a lot of Nearshoring data on file. But data does not equal knowledge.
Companies frequently hit that wall, trying to change minor details, trying to respond to client requests or trying to deal with regulatory agencies. The data on file is insufficient and the full knowledge remains exclusively with the external partner. Smart companies internalize third party knowledge when approaching the Nearshoring finish line.
Your Data under Your Control
Data and reports supplied by manufacturers do not contain all the knowledge generated during a Nearshoring process. Reports are rather a brief synopsis of all that happened, of all that was observed, of all that was decided and so on. In short - companies receive just a small subset of the entire knowledge. The majority remains with a third party.
Not a desirable situation because it limits the company in future decisions like changing partners. Not a desirable situation because the company payed for a task like "Manufacturing Transfer" but receives far less in terms of knowledge and data.
Internalizing external knowledge is an important step and should happen during finalization of the Nearshoring work at the latest. The challenge is to figure out the gap between supplied and retained knowledge. We support companies with knowledge internalization.
Data under Control
- All knowledge collected and internalized
- All knowledge organized, stored and readily available
- Knowledge and capability warehouse
Knowledge is Value
The analytical method for API release testing had been reported some weeks ago. Quite a convincing report, lots of tables, all validation parameters compliant with guidelines, nice executive summary, compliance statement and quadruple signature on the front page. Report´s PDF stored on the client company´s internal server - one more box of the Nearshoring project ticked.
Until the report was forwarded to the analytical team of another service provider and that team tried to reproduce the method. Two different column types stated to be used, column parameters not reported anyway, chromatographic plots in the wrong scale, dilution cascade not reproducible with reported information, confusing information on reference standards, unclear batch numbers of API batches used for validation and so on.
Hard to believe? Maybe, but an example taken from real life. The client company was not to blame, since they had no internal analytical expertise and many mistakes were far too specific to be easily identified. Nevertheless, the damage would have been at the side of the client.
Problems will appear during any Nearshoring process. Deviations from established routine. Changes from the original plan. Trouble shooting in the middle of a running process. Each of those were probably assessed carefully by the third party. Each corrective action was probably the best to take. However, the process leading to the action, the result of the assessment, the experts involved, the data which lead to problem identification normally remain exclusively at the side of the external service provider.
Looking back at the development process after some years reveals a plethora of seemingly random and pointless swaps, changes or deviations. A company trying to file such a process with e.g. regulatory agencies will just receive a lot of "why" questions. "Why did you change to that critical solvent?", "Why did you change the release specification?", and so on. Good questions and the answers are probably available - they just never made it to the knowledge base of the client company.
Knowledge equals value. Make sure to internalize all your knowledge.