"We find that in productive use, visualization is less important than it seems". (Max Pucher).
"In an automobile, you have a fuel gauge to tell you how much gas is in the tank. We know that there is a cycle or process that goes like this: car is filled -> car is driven -> fuel gets low -> car is refilled, etc.
Do we need a depiction of that cycle? Not really. Everyone knows that when the fuel level gets close to "empty" you need to fill it back up again. But you do need the display of the fuel level.
Same with the speedometer: when you try to maintain a particular speed, if the gauge shows you going a little too fast, you let off of the gas, if too slow, you press down a little. Do we need a diagram of showing this response pattern? Of course not, every driver knows this. However, it is critical that you have visualization of the speed.
This same thing works in more complex examples: a sales team will display the sales won for the month against the budgeted/forecast sales figures. A support team will display the current call wait times. A doctor might get a display of the patent's current vital signs, and history of recent treatments. A teacher may get a display of the all the student current scores and who is behind on work. This is nothing new; we know these as Key Performance Indicators (KPIs).
A KPI may be related directly or indirectly to a goal. So I guess in some sense you ARE displaying the goals and whether they are being achieved or not. However, it does not look like a process map. What is needed is really just a dashboard showing how the organization is measuring up ... so that the knowledge workers can respond according to their skill and experience". (Keith Swenson)
"With a mix of structured/unstructured work, what needs to be tracked is progress toward meeting Case pre-defined objectives, not work itself.
If Case objectives are set such that they are at all times supportive of strategic objectives, the organization is doing the right things.
If they are using best practices then they are doing the right things the right way.
If they use automated resource allocation, levelling and balancing, they are doing the right things, the right way, at the right time
If guidelines and boundaries are working, the organization has compliance.
If the organization has interoperability, then it has collaboration (customers, suppliers, regulatory authorities, local/remote systems and applications)
If the organization does all of these things, data collected at Cases as progress is being measured toward meeting such objectives will give dashboard information that allows knowledge workers to "respond according to their skill and experience"" (Karl Walter Keirstead)
Генерация приложения по семантической модели как пример какой-то визуализации кейсов -- http://www.beinformed.com/BeInformed/we
И последний гвоздь в крышку визуализационного гроба: "Intensive knowledge management processes are evil to analyse . The best you can discover are some patterns . It's almost impossible to discover most used paths. It's very unlikely to spot most used paths once people change execution based on the needs and wants and objectives to be accomplished. Based on the patterns you can try understand why people make decisions that way or another and how knowledge flows. If the exception is the norm, there is no language to model it" (Alberto Manuel).
А в конце треда рекламируют книжку "Empowering Knowledge Workers" (только что вышедший очередной сборник работ по adaptive case management): http://www.amazon.com/Empowering-Knowle
Моя собственная позиция по вопросу визуализации? Она такая же, как и для языков программирования: простые учебные случаи, конечно, хорошо визуализировать картинками -- они в явном виде показывают топологию. Но при росте сложности и выходе от учебных случаев к серьёзным реальным приложениям нас спасут только текстовые представления, дополняемые генерируемыми из этих текстов справочными табличками. Блок схемы померли ещё во времена Фортрана.