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

Продолжаю записывать последние оставшиеся в голове мысли по теме автоматизации документооборота. Первоначально была идея оформить материал в как бы эссе, разбитое на несколько частей: основные понятия, необходимость автоматизации, процесс выбора решения, особенности проекта внедрения, разные нюансы и рекомендации. Но современная клипообразная жизнь диктует свои условия — на днях наткнулся на статью Джилиана Бичанича «Семь вопросов, которые стоит задать, чтобы выбрать правильное ECM решение» (Jillian Bichanich, 7 Questions to Ask to Ensure You’re Choosing the Right ECM Solution) и, под впечатлением от прочитанного, решил забежать немного вперед лошади, сразу к теме выбора правильной ECM системы. Поскольку в последнее время занимаюсь внедрением решений электронного документооборота, то и примеры будут из соответствующей предметной области; но, вне сомнения, всё рассмотренное относится и к любой другой информационной системе.

Программка для секретарши

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

Наименее нагруженный айтишник получает задание и с  энтузиазмом принимается за работу. «Обзвони всех, скачай демо-версию. Покажешь, когда будет готово!» Ну и начинается.

По шагам:

• Первым делом программист (или сисадмин, или начальник отдела разработки, или вообще специалист техподдержки) лезет в гугл, практически сразу находится множество решений и контор, их предлагающих. Не очень понятно, чем одно решение отличается от другого, но это не важно, так как всё равно никто не знает, что в итоге должно получится.
• Неделя-другая на звонки и письма с просьбой «дайте посмотреть». Несколько вендоров откликнулись, уже хорошо. Вступают в переписку, некоторые даже предлагают демо-версию.
• Потянулись караваны продавцов. Консультанты танцуют на столе, нахваливая самые лучшие в мире программы и технологии. Месяц-другой программист и (да неужели?) кто-то из отдела делопроизводства обсуждают варианты. Снова приходят продавцы, снова обсуждение.
• Тут вдруг приятель из соседнего отдела с горящими глазами рассказывает, что его знакомая из другой компании рассказывала другому его знакомому, что они все теперь работают в SharePoint. «Крутая штука, сейчас все его устанавливают, умеет всё на свете, прост и легок в освоении, да еще и бесплатный!» Снова переговоры с поставщиками на тему «почему бы нам не приобрести SharePoint».  Поговорили. «Да зачем вам этот полуфабрикат на все руки? Выбросьте дурное из головы. Фу.» Подумали, согласились, полуфабрикат никак не нужен. SharePoint вычеркиваем.
• Друг одного из акционеров компании уверяет, что надо брать Documentum. Это круто. Это солидно. Это много денег и большой проект. Не хуже, чем SAP. Перед друзьями стыдно не будет. Бюджет проекта в сотни… сотни тысяч. Ух ты! Добавляем в список. Нет, всё-таки не добавляем; продукт по цене, сравнимой с годовым оборотом фирмы, кажется плохим выбором. Нашему программисту, разумеется, всё равно, но пятой точкой чувствует: что-то не так с количеством нулей.
• Откуда ни возьмись на горизонте появляется решение на основе Lotus Notes! Один из юристов где-то когда-то работал в этой среде, отличная программа! Почему бы и нет… но только заикнулся, как коллеги покрутили у виска: «Еще одна платформа на нашу голову?!» Но ведь это, как его… «Да убирай из списка, ты что, тупой?» Хорошо, хорошо, долой Лотус, извините, черт попутал.
• «Как достало-то! Сколько можно выбирать!»
• В итоге выбирается самый дешевый вариант из тех, которые приглянулись интерфейсом девчонкам из канцелярии. С чувством глубокого удовлетворения программист отправляет отчет наверх. Название продукта, сумма за лицензии и внедрение. Работа сделана! Начальство, бегло пробежавшись взглядом по тексту, уперлось в строчку с итоговой суммой и обалдело. «Столько денег потратить на программку для секретарши??? Ты в своем уме, болван?»

Не бросайтесь камнями, если в вашей организации процесс проходит не совсем так, рад за вас, честное слово!

Кто виноват

Активная деятельность налицо, но ясно же, что уже с самого начала были упущены несколько важных шагов. Во-первых, нет явного обоснования необходимости подобной системы, и, как следствие, никто не озаботился составлением требований. Собираемся внедрить то, не знаем что, да и надо ли, тоже не знаем, но чтоб не хуже, чем у конкурентов в офисе напротив! Вы не поверите, но так происходит сплошь да рядом.

Во-вторых, руководить процессом внедрения должны всё-таки не «программисты», а именно менеджеры, ответственные за процессы управления всей компанией. Люди из ИТ-отдела, несомненно, примут самое активное участие в составлении требований, но конечный выбор не за ними, да и командовать парадом — также не им.

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

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

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

Что делать

Люди

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

Здесь необходимо пояснение именно по документообороту. Понятно, что чаще всего с официальными документами работает отдел делопроизводства (канцелярия, административный отдел или как там он еще называется). Однако управление документами — намного более широкое понятие, чем только обработка корреспонденции и отслеживание исполнения резолюций по входящим документам. Большинство бизнес-процессов компании, проектов и кейсов (case management) также сопровождается потоками соответствующей, зачастую специфичной для конкретной области менеджмента документации. В общем, практически любые управленческие процессы подразумевают работу менеджеров с документами. В итоге, отдать выбор системы корпоративного в руки делопроизводителей представляется не совсем правильным решением.

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

Далее, кто отвечает за организацию процесса выбора решения?  Хорошо, если в компании есть CIO, он понимает толк в автоматизации и сможет наладить связь ИТ с бизнес-менеджерами (вот, кстати, здравые мысли про CIO и их роль в компании). Если такового нет, то, можно вручить бразды правления менеджерам с похожими компетенциями и полномочиями (например, бизнес-аналитикам). Или, если собственных ресурсов (людей, компетенций, опыта) не хватает, можно пригласить внешних консультантов. Консалтинговые фирмы и независимые эксперты обычно имеют опыт внедрения самых разных систем и обладают солидным багажом информации о преимуществах и недостатках имеющихся на рынке продуктов. Кроме того, консультанты сделают анализ существующих бизнес-процессов, дадут советы по автоматизации и помогут составить требования к системе.

Маленький нюанс: мир тесен. Не бывает совсем уж независимых экспертов, все так или иначе связаны с одним или несколькими продуктами — или сотрудничают с компаниями-производителями и их партнерами, или находятся под давлением собственного же опыта (зачастую, негативного) внедрения конкретных систем; об этом надо помнить.

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

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

Зачем и почему

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

Интересно, что на практике вопрос «зачем компании нужна автоматизация документооборота» моментально вырождается в вопрос «почему руководитель N уверен в необходимости системы Y для компании». Спросите у него, запишите ответ. Он вам не понравится, ведь никакого объективного обоснования вы, скорее всего, не услышите.

Определите обоснование необходимости внедрения системы. Насколько важно, срочно и вообще оправдано? Проведите общее обследование бизнес-процессов, которые предполагается автоматизировать. По-возможности, подготовьте экономическое обоснование, хотя, конечно, не всегда финансовые выгоды от внедрения новой информационной системы лежат на поверхности. Прямой финансовый эффект в виде возврата инвестиций (ROI, Return Of Investments) далеко не всегда может быть просчитан, или же рассчитывается с огромным числом всевозможных допущений и предположений. Помимо прямой экономической целесообразности, существуют и другие цели внедрения (извини, Голдратт!): разрешение структурных или технологических проблем, необходимость модернизации (старое оборудование больше не держит нагрузку), экстенсивное развитие компании (филиал за филиалом), внешние факторы (государство ввело новые регуляции) и т.д. Да, не забываем также и про бзики топ-менеджеров или, что еще хуже, акционеров, такое тоже случается: «А давайте-ка внедрим CRM! Зачем? Потому что мы — крутая компания!» В идеале такого быть не должно, но если всё-таки столкнулись — подтяните цели под капризы. Звучит дико, но что поделать.

Обоснование — документально изложенные доказательства правильности осознания проблематики бизнес-ситуации, целей и задач автоматизации, а также экономической и проч. целесообразности реализации проекта внедрения.

Целеполагание только тогда имеет смысл, если оно максимально конкретизировано. Расплывчатые фразы типа «повышение эффективности» и прочая «вода» здесь неуместны. Вот несколько правил постановки целей:

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

Если есть несколько возможных путей достижения целей, можно воспользоваться инструментами типа SWOT-матриц и т.п. для определения наилучшей стратегии. В итоге всех исследований должны быть сформированы ясные и однозначно интерпретируемые цели автоматизации управления. Именно исходя из поставленных целей формируются требования к решению.

Хочу Луну

Все пожелания к решению разбиваем на группы:

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

Конечно, на этом этапе — только общие требования и наиболее важные функции; детали будем уточнять в проекте на этапе анализа и составления спецификации требований. Сейчас — выделите самое важное, что необходимо для достижения поставленных целей!

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

Проводим анализ make or buy: исходя из поставленных целей и сформированных требований к решению, определяемся с возможностью реализации технического решения: создаем сами или отдаем на откуп компании-интегратору. Для компаний среднего по размерам бизнеса в большинстве случаев предпочтительнее последний вариант, хотя могут быть и исключения.

Не забываем про ключевые требования к самому проекту внедрения и добавляем их к списку:

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

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

Цена вопроса

Да, без денег никуда. Должны быть определены и согласованы с руководством рамки по бюджету, срокам и человеческим ресурсам. Общее понимание предстоящих затрат необходимо, компания должна быть готова к затратам — финансовым, трудовым, временным; идея быстренько сваять программку, что называется, «на коленке», силами одного программиста — не самая лучшая. Еще раз: программка для секретарши стоит 100 евро и называется Microsoft Word. Система управления стоит дорого и потребует много времени ваших сотрудников, а время, как известно — тоже деньги. Придется раскошелится.

Важно! Цена вопроса — не только в деньгах. Будьте готовы к изменениям в схемах управления компанией, в процессах и процедурах, к структурным преобразованиям. Согласиться с этим, быть готовыми к изменениям для большинства менеджеров не так-то просто. Более того, автоматизация бизнеса может быть связана с организационными изменениями, с необходимостью менеджеров повышать квалификацию, менять стиль работы, принять новые методы управления и т.п. Кто-то в силу отсутствия компетенций окажется перед выбором — учиться или перейти в другой отдел. Кто-то получит дополнительную нагрузка (да, да, автоматизация вовсе не всегда означает ничего не делание, пока роботы пашут в поте лица). Вполне возможно, что ответственный менеджер уже на этапе выбора решения встретит вполне естественной сопротивление со стороны сотрудников компании, как управленцев, так и исполнителей. Такая цена — готовность к переменам — должна быть заранее оговорена с высшим менеджментом, чьей поддержкой не мешало бы заручиться с самого начала процесса. Причем, документально; это пригодится и на этапе инициации проекта при подготовке меморандума проекта и, впоследствии, его устава.

План

План нужен, и не спорьте. Даже перед походом в магазин наличие в кармане вчетверо сложенного тетрадного листка с наименованиями продуктов гарантирует, что вы ничего не забудете купить. Планирование необходимо не столько для того, чтобы жестко следовать пунктам плана, сколько чтобы не упустить важные моменты процесса выбора. Начертайте основные пункты на салфетке во время обеденного перерыва. Обдумайте много-много раз, затем обсудите с рабочей группой, зафиксируйте план документально. Как уже отмечал выше, выбор системы управления — ответственный процесс, лучше сразу же подойти к нему основательно и определить шаги заранее.

В больших компаниях процесс выбора будет определен процедурами и инструкциями. Если же вы не обременены работой в транснациональной корпорации, вот пример неформального плана действий:

1. Анализ целей, проблематика, обоснование необходимости автоматизации.
2. Определение и согласование требований. В результате получается общий список требований к решению и его составных частей: бизнес-решение, организационное решение, техническое решение — в нашем случае информационная система. Заносим список в матрицу сравнения — электронную таблицу, в которой все требования сгруппированы и снабжены весами (оценкой важности или приоритетности требования); подробнее см. дальше.
3. Поиск решений и поставщиков. Первоначальный запрос информации о продукте. Презентации, переписка, встречи с представителями, установка демонстрационных версий, внутренние обсуждения и т.д. При необходимости поиск поставщиков организуется в виде тендера, в таком случае составляем и согласовываем график встреч и презентаций, отправки конкурсных документов и контрольных дат. Ведем конкурсную документацию строго в соответствии с процедурами и правилами компании. Отчитываемся о ходе тендера руководству.
4. Составляем предварительный краткий список (short-list ) — 3-4 поставщика наиболее подходящих продуктов, удовлетворяющих ключевым требованиям.
5. Запрос предложения поставщикам из этого списка. Укажите, в какой форме вы хотите получить предложение. Предложение должно быть составлено с учетом критериев, по которым будет оцениваться решение — вот вам в помощь матрица сравнения! Разумеется, вы ожидаете и ценовое предложение; приготовьте отдельную таблицу со следующими позициями: анализ и спецификация требований к системе, стоимость лицензий, стоимость разработки и работ по установке, интеграции, апробации, обучению и т.д., а также отдельно предусмотрите позиции по техподдержке и администрированию, затраты на консультации, ставка дополнительных работ, затраты на администрирование проекта со стороны поставщика.
6. Получив предложения, приводим их в божеский вид (то есть, загоняем параметры предложений в матрицу сравнения). Если есть особо выгодные предложения (скидки, акции, выражения всемерной любви), учитываем их, а вот на предложения откатов и прочих сомнительных действий рекомендую не отвечать, но это, как вы понимаете, дело совести конкретного менеджера, его лояльности работодателю, отношения к жизни и т.д..
7. Сравнение основных претендентов может быть неформальным (согласовали матрице сравнения, обсудили, бросили монетку и выбрали!) и формальным (собирается комиссия по тендеру и выносит решение). В любом случае в результате определяем победителя — информационную систему и ее поставщика (интегратора). Кстати, в заметке «Сделать правильный выбор — пять шагов» я как-то рассматривал процесс принятия решения с точки зрения психологии, загляните, может пригодиться.
8. Готовим отчет для руководства, в котором приводим краткую информацию о выбранном решении и соответствие его ключевых параметров выдвинутым требованием (без погружения в детали; их можно дать отдельным приложением). Тут же (опять-таки кратко) прописываем цифры: стоимость системы и проекта внедрения, затраты на поддержку и администрирование (не забываем о возможных структурных изменениях), предполагаемые сроки внедрения. Показываем, почему и каким образом именно эта информационная система позволит достичь целей автоматизации бизнеса, указанных в обосновании. Четко, с чувством, с расстановкой презентуем отчет начальству.
9. Если руководство дает добро, оповещаем удачливого претендента и приступаем к переговорам с интегратором и инициации проекта внедрения. Но это уже тема для другого разговора, сейчас же главное — выбор сделан, поздравляю! Если добра не получено… Что ж, возвращаемся к пункту 4 нашего плана, я вам сочувствую.

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

Матрица сравнения

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

Для сравнения альтернатив существует много инструментов. Взять хотя бы всем известный SWOT, который позволяет рассмотреть потенциальное решение через призму сильных/слабых сторон и в перспективе возможностей/проблем, или, например, деревья решений. Простейшим, но удобным инструментом является экспертная оценка и суммирование оценок соответствия системы требованиям в соответствии с весом (приоритетом) требований. Матрица сравнения позволяет достаточно быстро сравнить альтернативные продукты с учетом важности тех или иных требований для заказчика, хотя и имеет недостатки, как то: излишняя субъективность в назначении весов для качественных (не количественных) требований, в некоторых случаях несопоставимость параметров сравнения для разных решений и т.д. Я несколько раз применял матрицу сравнения на практике, в целом это работает.

Ок, значит, делаем так. Поместим список требований в электронную таблицу, разобьем требования на группы. Выделяем ключевые, отсеиваем противоречащие друг другу и повторяющиеся требования. Присваиваем каждому требованию вес (от 1 до 10). После чего на собрании рабочей группы приступаем к оценке (опять-таки от 1 до 10); для обсуждаемого решения выставляем оценку соответствия системы каждому требованию. Понятно, что список будет уникален для каждого конкретного случая автоматизации, я лишь приведу какой-то общий, вырванный из контекста пример (список групп):

• Бизнес-решение
  • Бизнес-модель и ключевые параметры
  • Методологии и стандарты
• Организационные преобразования
  • Структурные изменения
  • Персонал и компетенции
  • Обучение
• Техническое решение (система)
  • Функциональное наполнение
  • Модель информационных объектов
  • Интерфейс, мобильность
  • Интеграция с другими системами
  • Архитектура, технические требования
  • Вопросы безопасности и аудита
  • Администрирование системы
  • Возможности развития
• Проект автоматизации
  • Финансирование
  • Сроки и внешние ограничения
  • Жизненный цикл проекта
  • Требования к команде управления
  • Требования к отчетности и документированию
• Поставщик системы
  • Опыт и компетенции
  • Положение на рынке, наличие партнерского статуса
  • Требования к поддержке

Не следует путать общие требования к решению с детальной спецификацией требований к информационной системе (SRS, System Requirement Specification). Спецификация требований к ИС обычно составляется уже в ходе проекта силами компании-интегратора.

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

Не стоит также сводить выбор альтернатив к формальному заполнению матрицы выбора и выставлению баллов. Вполне возможно, что в ходе поиска решений появятся какие-то плохо формализуемые критерии, которые повлияют на конечный выбор; однако здесь таится опасность скатывания в субъективизм и дать поверхностную или даже предвзятую оценку.

На десерт предлагаю шаблон-заготовку для матрицы оценок (в формате таблицы Excel), пользуйтесь на здоровье. Версия на рус.яз: pmt Solution Evaluation Matrix — Template (rus), версия на лат.яз.: pmt Solution Evaluation Matrix — Template (lat).

Заранее благодарен за критику, буду рад, если поделитесь и своим опытом.