I think that actually is exactly what Kanban was devised for and largely the context of the David Anderson quote in your article: Kanban is not for software development, it is a technique for seeing, organizing, and improving the end-to-end process of how an organization accomplishes stuff. It is not a complete software process: it says nothing about QA/testing for example. Nor is it a complete marketing process: it doesn't say anything about how you determine market values.

It's about making all these sub-processes flow together, and identifying where the bottlenecks are.

There's a presentation from DJA on where Kanban is not appropriate here: http://www.slideshare.net/AGILEMinds/david-anderson-kanban-w...

Not an easy read. That said, it aligns to what you've been saying in your article (I think): the WHAT and WHY is irrelevant to Kanban, it can't help you there. The HOW, sure: but even there it is more of an overlay on existing process, not a catch all "one method to rule them all".

Where we get into trouble is that I think your article is saying "Kanban doesn't work, do this process instead". But the process you sketch out probably would fail too in many organizations that lack a good handle on what they're doing and why. Any process will, even goal-driven ones (which IME tend to work only in small scales with few cross-department interactions)