Doable? Sure. As we know, Remedy is super flexible. But is it really adding a lot of value in doing this? Please remember that customizations can also have a negative impact during upgrade.
First: does it hurt to have the PKE records in there, if they are not used?
Second: in my view, PKE records have some advantage from a process perspective.
The life cycle and the relationships of the PKE represent when the known error was first detected, when it was resolved, how it was resolved, etc.
Knowledge articles from my perspective are a user-friendly description of the "known error". That user-friendly description may change frequently and thus follow a different life cycle. The visibility rules are typically different. etc.
The separation into PBI and PKE is based on the classic ITIL Version 2 view. This was not proven and already ITIL version 3 did not provide this processual any more. I don't think that's the only reason why BMC added the solution information in PBI afterwards.
Also with us nobody has the fun/time to fill out another ticket PKE, if one can document the solution also completely comfortably in the PKI. We, too, cannot explain the difference between the corresponding type of knowledge article and PKE sufficiently. I think Remedy has been hanging on to the v2 story for a little too long. Less Problem tickets could be more and a cleaner implementation.
chris sapikowski, I agree with Peter on this topic.
Known Errors are a key element of the Problem Management process, they are ultimately a concise description of the issue, the cause and potentially a solution. They are created and managed within the Problem Management process and can be highly technical.
When a Known Error record is created, it is likely that it can contain highly technical, niche and advanced troubleshooting, analysis and root cause summary which wouldn't be appropriate to expose to the Service Desk and even higher level SME's for reference in responding to Incidents.
For that reason, you should create Knowledge Articles from the Known Error (a few simple clicks to automate the creation of that article), this gives you the opportunity to interpret the content of the Known Error (because it is unlikely that all of the content is even relevant to Service Desk and beyond) to the simpler audience, to write it in a way that is quickly referenced by a Service Agent with a customer on the phone, and also to consider creating a secondary Knowledge Article for exposing into Self-Service portals such as Digital Workplace.
If you're creating Knowledge Articles straight from a PBI which has a root cause identified then I'd suggest that you're not following ITIL but more importantly you're not following best practice.
I hope that this helps, I am happy to assist with further advice!