Система основных характеристик типового решения

Проблемы выбора типового решения (ТР) с ходом времени не упрощаются, а скорее нарастают. Назначение данной статьи — рассмотреть систему основных характеристических свойств современных ТР в сфере прикладных средств информатизации предприятий. Цель — на основе этой системы упорядоченно учитывать свойства типовых решений как при их выборе, внедрении, сопровождении и развитии, так и при разработке и распространении.

Классические принципы и новые требования

Классические принципы создания информационных систем для поддержки управления на предприятиях, в том числе определяющие требования к типовым решениям, были определены более 25 лет назад (впервые во многом В. М. Глушковым). Однако они вполне актуальны и для современных ТР, причём важны как при формулировании обобщенного набора их свойств, так и при оценке конкретных типовых решений для выбора потребителем.

В первую очередь выделим то, что можно назвать «принципом типизации» для прикладных решений, в том числе с поддержкой так называемых функциональных прикладных ИТ-решений: «...исполнитель обязан стремиться к тому, чтобы предлагаемые им решения подходили возможно более широкому кругу заказчиков. Необходимо в каждом случае определять разумную степень типизации, при которой стремление к широкому охвату потребителей не приведёт к существенному усложнению типовых решений. <...> Структура функциональной части автоматизированной системы управления зависит от схемы процедур управления (на современном жаргоне — схем бизнес-процессов и т. п. — Примеч. автора), определяющей взаимосвязь всех элементов управления и охватывающей автоматизированные, частично механизированные и ручные процедуры. Функциональная часть более мобильна, чем основа, и допускает изменение состава и постановки задач при условии обеспечения стандартного сопряжения с базовыми элементами системы» (БСЭ, статья «Управления автоматизированная система»).

К другим важным классическим принципам относятся: принцип непрерывного развития системы, принцип единства информационной базы, принцип новых задач и ряд других, включая весьма важные положения об относительности разделения автоматизированной системы на подсистемы и об адаптации систем управления: «Исследование технологических процессов <...> даёт возможность шире использовать методы адаптации систем управления для получения наилучших технико-экономических показателей». Важно также, что наряду с типовыми изделиями давно выделен такой вид ТР, как типовое проектное решение. Конечно, за прошедшие четверть века к классическим принципам многое добавилось. Произошли радикальные изменения как в ИТ, так и в организации деятельности предприятий. Они, в частности, привели к существенному изменению архитектуры ТР, к изменению потребности предприятий в них, и эти изменения продолжаются. В их числе:

• рост изменчивости, мобильности и инновационности бизнеса, рост сегментации отраслевых рынков, рост информационной нагрузки на менеджеров и работников всех уровней;
• сосуществование двух противоположных процессов — с одной стороны, консолидации бизнеса и с другой — распространения плоских организационных структур, виртуальных предприятий и «атомизации» предприятий;
• развитие компонентно-сервисных архитектур, бурный и далеко не завершенный процесс стандартизации в областях представления и взаимодействия ИТ-компонентов разных типов.

Требования, вытекающие из этих и других изменений, вносят важные дополнения в основные свойства ТР и в их оценку при выборе ТР потребителем. Таким образом, система основных характеристик современного типового решения должна быть структурированным отображением классических принципов и новых требований.

Характеристики и критерии выбора ТР

Правила и процедуры выбора и адаптации типового решения здесь не рассматриваются, однако должны постоянно подразумеваться, поскольку имеет смысл только такая система основных характеристик ТР, которая была бы практичным инструментом при выборе потребителем. В связи с этим важно разделять характеристики ТР, характеристики предприятия-потребителя и критерии выбора.

Характеристики ТР часто смешивают с критериями их выбора, например, представляя в качестве таковых просто список функций. Распространены и случаи смешения потребностей предприятия с критериями выбора. И то и другое мешает ясному пониманию конкретных ТР, процедур их оценки и выбора. Поэтому полезно исходить из следующего:

• характеристики ТР, выбранные для удовлетворения широкого круга потребителей, существуют независимо от потребностей конкретного предприятия;
• потребности предприятия в информационной поддерж­ке также существуют и должны определяться независимо от ТР, их наличия или отсутствия;
• критерии выбора формируются индивидуально при каждом выполнении процедур выбора установлением связи между характеристиками ТР и потребностями предприятия.

В число параметров этой связи, определяющей каждый критерий, обычно включают обязательность или желательность конкретной характеристики ТР (например, наличия той или иной функции), а для желательных характеристик — также «степень желательности».

Стоит существенно ограничивать количество рассматриваемых критериев небольшим числом главных критериев, например семью (во всяком случае не более десяти) обязательными и столькими же желательными. В противном случае часто наблюдается такое сочетание недостатков и достоинств ТР, что картина оценки становится смазанной, а решение о выборе (особенно в глазах инвестора) — плохо обоснованным и затруднительным.

Кроме того, важно, чтобы критерии оценки и выбора были практически ортогональны, то есть оценка по одному критерию не зависела от оценок по другим критериям или этой зависимостью можно было бы пренебречь. Это важно для исключения дублирования работ при выборе, да и просто для получения более ясной картины в целом.

Однако требования, справедливые по отношению к критериям выбора, мало применимы к характеристикам ТР:

• только в конкретном акте оценки и выбора будут выделяться главные именно для этого случая характеристики;
• одна и та же характеристика в разных случаях может иметь совершенно разную значимость, например, в одном случае наличие у ТР конкретной функции будет определено как обязательное, в другом, даже у практически однотипного потребителя, — как желательное, причем значение других характеристик, скажем удобства, открытости или производительности, может перевесить отсутствие этой функции;
• многие характеристики разных типов могут сильно зависеть от других характеристик, что определяется реализованной архитектурой ТР, и только при формулировании критериев выбора возможны действия по достижению ортогональности критериев этого вы­бора.

С учетом всего изложенного необходимо трактовать и предлагаемую далее систему основных характеристик современного ТР, которая:

• определяет области, подобласти и группы/виды характеристик «как они есть у ТР»;
• в то же время представляет собой такие группы/виды характеристик, из которых могут быть выбраны немногие нужные для формирования ограниченного числа главных критериев выбора ТР.

Конечно же предложенная ниже система характеристик ТР должна иметь обобщенный характер (framework) для того, чтобы можно было не только применять ее «впрямую», но и разрабатывать специализированные варианты для различных классов ТР и предприятий-потребителей.

Схема свойств типового решения

В систему описания свойств ТР входят также принципы заполнения и применения схемы свойств ТР, порядок определения конкретных характеристик и показателей с метриками определения их значений, другие методические компоненты. Однако рамки статьи позволяют показать только часть этой системы, а именно схему областей, подобластей и групп характеристик ТР, и то в весьма сжатом виде.

Все характеристики разбиты на шесть областей:

• характеристики расчетной или рекомендуемой сферы применения типового решения;
• свойства видов обеспечения типового решения и будущей ИС;
• экономические и организационно-экономические параметры типового решения;
• место типового решения в организационной архитектуре и ИТ-архитектуре предприятия;
• свойства типового решения и создаваемых на его основе ИС как открытых систем;
• характеристики адаптируемости типового решения к особенностям предприятия и возможности развития созданной на его основе ИС.

В каждой из этих областей выделены три подобласти. В результате получается схема-«снежинка» (см. рисунок), в центре которой помещаются такие характеристики, как «назначение типового решения» и «цели создания ИС на основе типового решения» (их можно считать еще одной, по сути — первой областью характеристик).

Представление свойств ТР в виде именно шестилучевой схемы выбрано в значительной степени из соображений удобства. При этом области характеристик (лучи «снежинки») не являются абсолютно ортогональными, так как задача формирования строго формальной классификации характеристик, во-первых, не ставится, а во-вторых, по ряду причин практически невыполнима. Ставится другая задача: всестороннее представление типового решения с нескольких точек зрения. Проявляющиеся частичные перекрытия и другие связи между характеристиками разных областей могут на практике использоваться для верификации правильности описания ТР. Заметим также, что:

• порядок описания областей и входящих в их состав характеристик не является существенным;
• характеристики одной группы дополнительно могут группироваться по подсистемам ТР, поскольку для разных подсистем могут иметься разные значения характеристик или даже разные их виды.

Безусловно, описанная ниже схема рассматривается как обобщенная. То есть для этих областей, подобластей и групп/видов характеристик потребитель и поставщик типового решения могут и должны формировать свои конкретные показатели оценки ТР и даже требования к их составу и значениям (пример см. в таблице). На это важно указать и в связи с тем, что в разных отраслях или у разных поставщиков характеристики могут быть сформулированы в различных терминах.

Далее даются краткие описания областей, подобластей и выбранных для этой статьи групп и/или видов характеристик ТР. Не ставится задача исчерпывающего описания, что является предметом полной методики, более подробно прокомментирована небольшая часть аспектов, в том числе те, которые чаще упускаются из виду.

Область «Расчетная или рекомендуемая сфера применения»

Подобласть 1: характеристики отраслевой ориентации. Группы показателей:

• характеристика применимости в организациях — органах власти (определенного уровня), производственной/коммерческой деятельности, некоммерческой негосударственной деятельности;
• ориентация на отраслевую специфику — одну, несколько или любую отрасль и подотрасль.

Наиболее дробной характеристикой в этой подобласти является словесное описание узкой подотрасли или наименьшего сегмента рынка, представляющего группу однородных в определенном отношении целевых предприятий, на которую ориентировано описываемое ТР. Нужно учитывать, однако, что для отражения отраслевой специфики требуется работать с дроблением не на три-четыре десятка, а на несколько сотен подотраслей. При этом целесообразно описывать отрасли и подотрасли не только (и не столько) с точки зрения производимой продукции, что чаще используется в классификаторах, ориентированных на отражение экономических характеристик народного хозяйства, но и с позиций способов деятельности и методов управления на целевых предприятиях, поддерживаемых в ТР.

В связи с этим целесообразно описывать отраслевую ориентацию в первую очередь словесно и содержательно, но опираясь на все полезное, что можно почерпнуть из разных классификаторов (в том числе из ОКОНХ, ОКВЭД и других).

Подобласть 2: функционал типового решения. В эту подобласть входят характеристики охвата части дерева функциональных областей, процесс­ных цепочек и/или отдельных функций с показом одной или нескольких автоматизируемых областей — в том числе расположенных на разных уровнях управления компанией. Группы показателей:

• функциональные области (в рамках предприятия в целом), их подобласти (в иерархической функциональной модели);
• бизнес-процессы (административные, производственные, другие профессиональные процессы) в целом, части процессов или подпроцессы (желательно в процессной модели предприятия);
• отдельные функции, бизнес-процедуры или операции, поддерживаемые типовым решением.

Здесь наиболее дробной характеристикой является словесное описание самой «мелкой» операции или бизнес-процедуры, поддерживаемой ТР, или выполняемой им информационно-вычислительной функции. «Функционал типового решения» является самой популярной областью признаков. Именно первые уровни дерева функций часто служат для наименования и даже классификации ТР. Однако качественное описание функционала требует более детальной, чем первые два-три уровня дерева, структуризации поддерживаемых типовым решением бизнес-процессов и функций и часто распространяется еще на несколько уровней функциональной иерархии. Более того, одна иерархическая модель функций дает недостаточное представление. Она должна быть дополнена описанием характера связывания функций нижнего уровня в цельные процессы и подпроцессы.

Отметим, что часто объединения функций, покрываемые распространенными ТР, используют как название условного «класса» ТР, например ERP-система или HRM. В этих условных «главных классах» приложений отражаются естественные и устойчивые связи между функциями предприятия и приложениями, как условными ими можно и пользоваться. Однако считать группировку, отражаемую именно такими трехбуквенными сочетаниями, главной нельзя. Дело не только в том, что слишком обширная интеграция функций в рамках одного решения (например, ERP-системы) имеет как преимущества, так и недостатки. А и в том, что границы между этими «главными» классами и их функциональное наполнение подвижны и зависят от отрасли. Постоянно возникают новые вертикальные и горизонтальные объединения приложений, варианты интеграции компонентов бэк-офисного и фронт-офисного характера и т. д., и процесс изменения границ между типовыми решениями и вариантов «пакетирования» функций в прикладных пакетах неизбежно будет продолжаться.

Поэтому главным остается содержательное описание функций. Для осмысленной и устойчивой структуризации функционала рекомендуется привязывать его к модернизированным описаниям цепочек создания добавленной стоимости М. Портера (например, отталкиваясь от «универсального языка описания бизнес-процессов» PwC). Для отражения функций, связанных с распределенными между разными предприятиями бизнес-процессами целесообразно опираться на привязку функций к множеству взаимодействующих цепочек создания добавленной стоимости (например, к схеме, предложенной еще в 90-х годах Линдой Хикман). Этот же подход позволяет показывать привязку функции к тому или иному уровню управления, производства или проекта, в том числе в случае поддержки эшелонированной корпоративной организационной структуры. Одновременно он позволяет практически никак не связывать функции ТР и поддерживаемые ими бизнес-процессы с организационной структурой предприятия-потребителя.

Наконец, несмотря на важность подобласти «функционал» без знания остальных характеристик ТР признаки этой подобласти имеют мало значения.

Подобласть 3: характеристики национальной и локальной ориентации. Группы показателей:

• законодательная база (в том числе рассчитанная на мультинациональное или международное использование);
• языки интерфейса с пользователем и эксплуатационным персоналом (языки интерфейса с конечным пользователем, системы единиц, языки эксплуатационной и технической документации и др.);
• распространение на открытом рынке или среди филиалов корпорации организаций партнеров, органов государственного управления и т. п.

Область «Свойства видов обеспечения ТР и будущей ИС»

Подобласть 1: показатели степени готовности ТР (его «продвинутости» к законченному решению). Показа­тели дополнительно могут группироваться по подсисте­мам типового решения, поскольку разные подсистемы целенаправленно могут поставляться с разной степенью готовности. Тем не менее можно предложить общие шкалы:

• степень готовности концепции решения, архитектурно-логической структуры и методики работы пользователя (например, обобщенная и предусматривающая обязательную разработку конкретного варианта у потребителя или унифицированная, одинаковая для всех);
• степень готовности проектного решения (открытые заготовки, шаблоны, типовой проектный продукт с возможной привязкой в предусмотренных частях или унифицированный проектный продукт);
• степень готовности программно-методического или программно-технического и методического решения (например, тиражируемый «конструктор» для проектирования конкретных программ на основе работающих элементов, тиражируемый прикладной продукт с предусматриваемой доработкой — кастомизацией или образец для тиражирования без предусматриваемой доработки).

Подобласть 2: виды обеспечения типового решения (в классификации, аналогичной ГОСТ 34). Здесь описывается состав и содержание включаемого в типовое решение при его поставке такого обеспечения, как ПО, ИО, ТО, правовое, организационно-методическое обеспечение, техническая документация, эксплуатационная документация, документация для технологической подготовки производства и выпуска экземпляров ТР как изделий и др.

Подобласть 3: показатели потребительского качества реализации компонентов. Здесь описывается состав и содержание таких показателей качества, как полнота, понятность, надежность, производительность, требуемые для эксплуатации ресурсы, удобство, эргономичность и другие. Точно определить значения многих из этих показателей трудно, по этой или иной причине показатели данной подобласти редко описываются разработчиком в достаточном объеме и с желательной достоверностью.

Область «Экономические и организационно-экономические параметры типового решения»

Подобласть 1: TCO, ее компоненты и их обеспечение. Группы показателей:

• затраты на оценку ТР (включая сравнение ТР с его аналогами, доступ к опыту реального использования и др.);
• стоимость непосредственного приобретения (лицензии и сопутствующие расходы);
• стоимость внедрения с разной степенью адаптации (в том числе стоимость и степень доступности услуг поставщиков и внешних консультантов, полная стоимость базовой программно-технической платформы для установки ТР, стоимость помещений и вспомогательного оборудования, стоимость дополнительной сертификации специалистов);
• стоимость эксплуатации (в том числе обучения и самообучения, сопровождения и технической поддержки разных уровней, расходных материалов, поддержки НСИ и др.);
• оценка рисков применения ТР и возможности управления ими (в том числе предлагаемые возможности их страхования).

Подобласть 2: способность обеспечивать итоговый положительный эффект. Группы показателей:

• показатели способности обеспечивать явный (tangible) ROI, кривая ROI в тех или иных типовых условиях;
• показатели способности обеспечивать неявные (intangible) эффекты, положительные социальные эффекты, PROI;
• характеристики способности обеспечивать кратковременные жизненно важные для потребителя цели;
• характеристики способности обеспечивать долговременные стратегические цели предприятий-потребителей (заметим, что эта способность не совпадает с функциями стратегического управления предприятием!).

Подобласть 3: требования к организационным аспектам среды предприятия-потребителя. Группы показателей:

• требования к организационной структуре, уровню зрелости бизнес-процессов и масштабу предприятия-пользователя;
• требования к организационной и кадровой структуре ИТ-службы предприятия;
• требования к организационной и кадровой структуре поставщика ИТ-услуг, поддерживающего ТР (включая регламент обслуживания, квалификацию сотрудников, число сотрудников и / или человеко-часов поставщика ИТ-услуг при обслуживании по установленному регламенту и др.);
• требования к уровню зрелости ИТ-процессов (например, по CobIT и т. п.) предприятия-пользователя;
• требования к корпоративной (профессиональной) культуре предприятия-пользователя.

Уровень зрелости процессов здесь рассматривается формально — как степень их соответствия тому или иному отраслевому стандарту. При этом не предполагается, что чем выше уровень зрелости, требуемый для ТР, тем оно «лучше», зависимость может быть и обратной.

Область «Место ТР в организационной и ИТ-архитектуре»

Подобласть 1: степень близости выходов типового решения к функциям конечного пользователя. Здесь выделим такие группы показателей.

1. Группа показателей близости выходов к конкретным видам пользователей для ТР, рассчитанных на непосредственную работу с ними конечных пользователей («бизнес-пользователей»).

2. Группа показателей близости выходов к конкретным видам пользователей для ТР, рассчитанных на непосредственное использование сотрудниками отдела сопровождения прикладных систем, консультантами в сфере ИТ или бизнес-процессов и сотрудниками ИТ-службы (возможно — в некоторых режимах и случаях — и «продвинутыми» конечными бизнес-пользователями).

3. Группа показателей близости выходов к конкретным видам пользователей для ТР, рассчитанных на непосредственное использование сотрудниками-разработчиками ИТ-службы, внешними разработчиками и консуль­тантами.

Подобласть 2: степень инновационности типового решения, связанная с его привязкой к перспективной архитектуре предприятия. При этом показатели разделяются на следующие группы.

1. Показатели, отражающие тот факт, что ТР (или входящий в его состав отдельный компонент или решение) реализует бизнес-процессы и функции во многом устарелыми методами (outdated methods), от которых многие потребители уже отказались (например, клавиатурный ввод данных).

2. Показатели, отражающие факт, что ТР (или входящее в его состав отдельное решение) реализует классические, стандартизированные бизнес-процессы и функции традиционными методами (standardized methods), широко используемыми в течение значительного времени (например, работу со штрихкодами).

3. Показатели, отражающие, что ТР (или входящее в его состав отдельное решение) реализует бизнес-процессы и функции методами, еще не ставшими повсеместно традиционными, но постоянно расширяющими свое распространение (escalating methods) и, возможно, претендующими на стандартизацию (например, технику пассивной RFID в сочетании с синхронным изменением состояния корпоративного хранилища данных).

4. Показатели, отражающие, что ТР (или входящее в его состав отдельное решение) реализует бизнес-процессы и функции новыми методами (emerging methods), перспективными в том или ином отношении, но еще не получившими заметного распространения (например, технику активной RFID).

Показатели этой подобласти отражают две важные стороны типового решения:

• ориентацию на ту или иную архитектуру целевых для ТР предприятий;
• претензии на «отработанность» или же на «перспективность» поддерживаемых способов деятельности предприятия (и, как правило, на отработанность или перспективность самого ТР).

Для ориентации на ту или иную бизнес-архитектуру предприятий в описании ТР должны быть отражены модель управления предприятием и модель организации и технологий производства, поддерживаемые типовым решением. Описание таких моделей можно почерпнуть и из подобласти «Функционал типового решения». Вместе с тем указанные там модели, так же как и их «трехбуквенные названия», часто оказываются условными и могут быстро устаревать. В связи с этим рекомендуется опираться на прямое содержательное соотнесение ТР с широко принятыми и известными архитектурными решениями в части бизнес- и ИТ-архитектуры.

Желательно в явном виде описывать не только соответствия, но и различия, причем именно с точки зрения поддержки перспективных или новых моделей, схем, решений.

Кроме того, желательно отражать возможность потребителя получать относительные конкурентные преимущества с помощью ТР. По этим причинам поддерживаемые данным ТР архитектуры целевых предприятий (в том числе модели управления, ведения операционной деятельности, организации информационных ресурсов и др.) рекомендуется описывать через призму инновационности типового решения. В конце концов на первом этапе знакомства с ТР (до его опробования «вживую») потребителю о называющихся одинаково функциях разных типовых решений полезно знать именно это, ведь чаще всего инвестиции в ТР делаются не на год и даже не на три года!

В качестве идеологической «подложки» такого описания можно использовать идею и схему разделения компаний по инновационности Росса Перо (Ross Perot) и ее последующие аналоги (создававшиеся в компании Gartner и т. п.).

Подобласть 3: характеристики архитектуры типового решения. Группы показателей:

• регламенты и графики взаимодействия подсистем и процессов;
• компонентная организация бизнес-сервисов и программных модулей;
• организация информационной базы ТР;
• варианты потенциального соответствия архитектуры типового решения ИТ-архитектуре целевого предприятия (в том числе предусмотренные варианты размещения на технической платформе, организация взаимодействия со смежными ИТ-системами — помимо интероперабельности, описываемой отдельно);
• доступность детального описания логической и физической архитектуры ТР.

Другие группы показателей, связанные, например, с местом в бизнес-архитектуре, могут быть перекрыты характеристиками иных областей.

Область «Свойства ТР и создаваемых на его основе ИС как открытых систем»

Важнейшая, методически проработанная, но развивающаяся область здесь представляется предельно кратко.

Подобласть 1: свойства интероперабельности, масштабируемости и переносимости типового решения в бизнес-аспекте.

Подобласть 2: свойства интероперабельности, масштабируемости и переносимости в системно-логическом архитектурном аспекте.

Подобласть 3: свойства интероперабельности, масштабируемости и переносимости на программно-техническом уровне.

Существенно, что свойства этой области — в соответствии с современными требованиями и разработками — распространяются не только на ИТ, но и на организационные представления, что достойно отдельной статьи. Они весьма тесно связаны со стандартами как бизнес-, так и ИТ-характера, причем одним из центральных моментов является вычленение и описание ключевых интерфейсов.

Область «Адаптируемость ТР к особенностям предприятия и возможности развития ИС»

Важнейшая область, представленная здесь предельно кратко, хорошо известна профессионалам. Представляемые ее характеристиками свойства ТР, возможно, развиваются наиболее быстрыми темпами и также достойны отдельной статьи.

Подобласть 1: характеристики адаптируемости типового решения на уровне задания значений предусмотренных параметров.

Подобласть 2: возможности модификации состава и самих компонентов типового решения. Несмотря на встречающиеся мнения о том, что ТР, позволяющее модифицировать свои компоненты, — это «плохое ТР», такой способ регулярно применяется и в мировой практике учитывается, в том числе в методиках оценки и сравнения COTS-продуктов.

Подобласть 3: характеристики возможностей типового решения как инструмента конечного пользо­вателя.

Заключение

ТР могут быть весьма разными. В связи с этим целесообразно применять двух- или трехэтапный подход.

1. Использовать представленную в этой статье обобщенную систему описания и структурную схему характеристик ТР как общую основу. Соответственно применять общие для разных заинтересованных лиц принципы описания и использования характеристик, области, подобласти, группы, а в некоторых случаях и виды характеристик ТР.

2. При необходимости, например, в случае излишней громоздкости или, напротив, существенных пробелов обобщенной схемы для обладающего заметной спецификой класса ТР формировать специализированную схему характеристик, более приспособленную для описания именного такого специфического класса.

3. Для каждого конкретного ТР определять конкретные показатели и описатели характеристик в каждой их области, подобласти, группы и вида, вводя по возможности однозначные описательные характеристики (например, функций) или измеримые индикаторы (например, затрат или положительных эффектов).

Обобщенная система характеристик ТР обеспечивает преимущества того же характера, что и методики и схемы архитектурного подхода. Потребители при выборе ТР, а также при обмене опытом их применения получают возможность общаться между собой и с поставщиками на одном языке, а значит, существенно повышать эффективность этого взаимодействия. Структурированное описание характеристик ТР, а также некоторых связей между характеристиками разных областей дает основу для упорядоченной по способу выполнения и более надежной по результату оценки ТР в каждом конкретном случае.

Так, обобщенная схема ориентирует на описание типовых решений не в привязке к быстро меняющимся оргструктурам или группированию функций в популярные сегодня пакеты, а с опорой на более стабильные формы организации деятельности потребителей. Эта схема позволяет целенаправленно отделять ТР, рассчитанные на инноваторов, от решений, воплощающих консервативные схемы и методы работы предприятий. Потребитель получает систему регулярных «подсказок» о том, какие характеристики типового решения не следует упускать из виду для всесторонней оценки сегодня и какие запланировать для анализа и обеспечения «на завтра». Кроме того, она помогает накапливать опыт оценки различных ТР в единообразно структурированном виде и затем использовать его как непосредственно и легко употребляемое знание. Все это весьма полезно, даже если для окончательного выбора придется проводить реальный «тест-драйв».