As stated, this is really an X/Y problem because you're asking for validation of your approach. This simply leads to confirmation bias.
What you are really trying to accomplish is business process reengineering, which requires your organization to invest time, money, and resources in changing essential workflows. Enumerating and understanding your current workflows is a prerequisite to changing them.
Part of the problem is that your premise and conclusion contain a logical fallacy, insofar as you have created a false equivalence. When restated as part of a logical argument, your underlying question appears to be:
Is increasing the visibility of someone's work an effective means of knowledge transfer?
In other words, you have started from the premise that task visibility and knowledge transfer are roughly equivalent. This may or may not be true; in this particular case, assuming that they are equivalent leads to an anchoring that will bias your options and obfuscate the real issues.
Define Terms and Measurements
I'm wondering how we can start helping her without completely destroying her productivity.
I'm wondering how you're currently measuring her productivity, how you plan to measure the effectiveness of any knowledge transfer, and how you expect to measure the overhead or drag of adding task visibility.
I'm also wondering how you plan to get something for nothing. In other words, you want to transfer knowledge, which requires people and time, but you don't want your projects to pay for that transfer with any reduction in velocity. The Theory of Constraints basically says you can't have your cake and eat it, too.
What to Do Next
Having said all of the foregoing, raising the visibility of the person's tasks and creating some sort of information radiator is actually a good first step, but not for any of the reasons you've presupposed. It isn't a substitute for real knowledge transfer (or delegation either), but is a necessary first step in getting your arms around the scope of work that needs to be documented and delegated.
So, making tasks and procedures visible is a good first step, but it's only a step on the path to process documentation. As an organization, you need to get your arms around:
- The person's scope of responsibility.
- The processes that the person routinely performs.
- The step-by-step procedures that the person follows to successfully execute the process.
Once you've enumerated the person's functions, and documented how those functions are carried out, you will then be ready to measure those functions and determine what changes (if any) will add the most value for the least cost. This is obviously not a quick fix, but is usually the correct approach to this kind of systemic bottleneck.