アイディエーション・インターナショナル社のＩＷＢ（Innovation WorkBench）というソフトウェアが採用している思考プロセスを「アイディエーション・プロセス」と呼んでいます。
その内容は、Ⅰ．問題の情報把握→Ⅱ．プロブレムフォーミュレーションとブレーンストーミング→Ⅲ．方策案のまとめ→Ⅳ．結果の評価といった４つの大項目からなっています。
Ⅰ．問題の情報把握は、１．状況の要約→２．システムアプローチ→３．資源、制約、制限の３つの中項目からなっています。
状況の要約では、専門用語を使わずに中学生にもわかるように問題状況を詳細に記録します。これは、状況をより一般化することで、解決策を探すうえで幅広いアプローチを可能にするためです。
システムアプローチでは、２．１．上位システム－システム－下位システム、２．２．インプット－プロセス－アウトプット、２．３．原因－問題－結果、２．４．過去－現在－未来、といった４つの観点から問題状況を体系的に分析します。
資源、制約、制限では、システムあるいはその周囲に存在する何らかの特性で、システムを改良するために利用できる「３．１．利用可能な資源」、問題を解決するに当てってシステムをどこまで変化させることが許されるかという「３．２．システムの変化の許容範囲」、システムを変化させる上での「３．３．制約と制限」、問題解決の成功と不成功とを評価する基準である「３．４．解決策の評価基準」、といったことを検討することで、採用できない方策案を検討することによる時間と労力の無駄を避けようとします。
Ⅱ．プロブレムフォーミュレーションとブレーンストーミングでは、まず、複雑に絡み合った結果として生じている好ましくない状況の構造を明らかにしたダイヤグラムを作成し、それぞれの問題について複数の解決するアプローチまたは可能性を指し示す手がかり（これを指針という。）を手に入れます。
次に、指針のリストの中から、検討する必要があると思う指針を選び、選んだ指針それぞれについて、指針が示唆するヒント（これを、オペレータという。）を使ってブレーンストーミングでアイデア発想します。
Ⅲ．方策案のまとめでは、事前の準備として複数のアイデアを同一の機能および／または同一の構成要素に分類する「１．アイデアの分類」と、同一の機能をねらったアイデア同士を組み合わせたり、アイデアと既存のシステムを組み合わせて方策案作り、その方策案の単純化を試みることで、問題の様々な側面に対処でき状況を大きく改善する最終的な方策案をまとめあげるための「２．方策案のまとめ」を行います。
Ⅳ．結果の評価では、方策案に付随する顕在的・潜在的な欠点そのものを二次的な問題ととらえて、その二次的な問題を解決することで実行可能な方策案に仕上げます。
そのために、Ⅳ．結果の評価では、二次的問題を定義してその解決策を案出する「１．方策案と評価基準との照合」、潜在的不具合を事前に予測しその不具合の予防案を案出する「２．不具合の予測と予防」、二次的問題を解決した方策案が基本的な技術システム進化パターンのどの段階にあるか特定してその後どのように変化していくか予測し、方策案をどのように変化させるべきかを検討する「３．進化のパターン／ラインの適用」を行います。
また、方策案を実行に移す前に、その効果を確認するために必要な調査／研究／実験の計画と、その結果を受けて方策案を実行に移すための具体的な計画を検討する「４．実行計画の策定」を行います。
ＩＷＢには記載されていませんが、アイディエーション・プロセスを実行する上で重要なことが２つあります。
一つは、実際のプロジェクトを行うに当たっては、Ⅰ．問題の情報把握→Ⅱ．プロブレムフォーミュレーションとブレーンストーミング→Ⅲ．方策案のまとめ→Ⅳ．結果の評価といった順序にこだわらないことです。
私たちが取り組む実際の問題は、改善改良のレベルから新規事業の立ち上げのレベルのように、数日で解決する問題から数年かけて解決する問題まで、幅広いものです。
したがって、オペレータに頼らずとも、プロブレムフォーミュレーションやシステムアプローチだけで問題が解決してしまうものもあれば、一通り全工程を実行した後で、システムアプローチからやり直さなければならないものもあります。
問題の難易度に応じて、アイディエーション・プロセスのうちの特定の項目だけ使用したり、項目を入れ替えたりして使用するこが必要になります。
もう一つは、アイディエーション・プロセスの前に位置付けられている、プロジェクトの内容を確認するための「プロジェクト開始」の項目をしっかりと検討することです。
「プロジェクト開始」の項目は、Ｉ－ＴＲＩＺに特有のものということではありませんが、プロジェクトが成功するか否かを決める重要な要素であるといえます。
「プロジェクトの開始」は、プロジェクトで検討対象としているシステム、プロセスの対象の本来の目的を確認する「１．目的・目標」と、プロジェクトが対処している状況が、ビジネスの観点から、組織の観点から、どのような事情と関連しているのかを理解するための「２．状況の持つ意味」とからなります。
「１．目的・目標」に関連していえば、例えば車の修理に関連して問題が発生しているとしても、車の本来の目的は「修理される」ことではなく、「人や貨物を輸送する」ことであることを認識しなければなりません。また、目的を実現するための目標が現実的なものか否かの見極めも重要です。
「２．状況の持つ意味」では、プロジェクトによって可能性が切り開かれること、あるいは、問題が解決されることによって、誰が有利になるか（誰のためのプロジェクトか）、その状況を本当に改善しなければいけないのか、その状況を改善するとどのような影響が生じるか、などプロジェクトを開始する前に考えておくべきことが記載されています。
「プロジェクトの開始」では、場合によっては、プロジェクト