Логіко-структурна матриця (LSM / Logframe)

Логіко-структурна матриця – таблиця, у якій проєкт описано так, щоб його логіку можна було перевірити, а не просто прочитати. Донор дивиться на неї як на конспект усієї заявки: якщо матриця не сходиться, решта тексту вже не рятує.

Європейська Комісія розрізняє дві речі, які в побуті звуть однаково. LFA (logical framework approach) – це аналітичний процес: аналіз стейкхолдерів, потім проблем, потім цілей, потім вибір стратегії. Матриця – документ, у якому підсумовано результат цього процесу. У методичних вказівках сказано просто: матриця має бути «допоміжним інструментом мислення». Якщо її заповнюють в останню ніч перед подачею, вона не виконує своєї функції – і це видно.

Чотири рядки: рівні проєкту

Рядки утворюють причинно-наслідковий ланцюг знизу вгору. Кожен наступний рівень є наслідком попереднього, а не його переказом іншими словами.

Заходи (Activities) – завдання, які треба виконати, щоб отримати заплановані продукти.

Результати-продукти (Results) – прямі відчутні результати: товари й послуги, які проєкт постачає і які «значною мірою перебувають під контролем керівництва проєкту».

Мета проєкту (Purpose) – зміна на момент завершення проєкту, конкретно: очікувані вигоди для цільових груп.

Загальна мета (Overall objective) – ширший вплив на національному чи секторальному рівні, у який проєкт лише робить внесок.

Різницю між рівнями результатів детально розібрано в статті Outputs vs Outcomes vs Impact. Ступінь вашого контролю падає з кожним рівнем: заходами й продуктами ви керуєте, на мету впливаєте лише через продукти, а на загальну мету – ніяк, її тільки моніторять.

Чотири колонки – і виняток, про який забувають

Логіка втручання – формулювання самого рівня. Індикатори – за чим буде видно, що рівня досягнуто. Джерела перевірки – звідки візьметься значення індикатора. Припущення – зовнішні умови, потрібні для переходу на наступний рівень.

Виняток у рядку «Заходи». У схемі Європейської Комісії цей рядок не має ані індикаторів, ані джерел перевірки – там подають ресурси (means) і витрати (costs). Багато підручників малюють у цьому рядку індикатори – це помилка, а не спрощення. Зверніть увагу: в USAID і UNDP, навпаки, рядок заходів має власні показники або віхи – тобто «правильної» відповіді поза межами конкретного шаблону не існує.

Більше того, методичка 2004 року радить винести з матриці і заходи, і ресурси з витратами – і прямо називає це «відходом від попередньої практики ЄК»: формат таблиці погано підходить для опису бюджету, а заходам місце в окремому графіку. Пояснення там же: важлива не форма, а «якість мислення й аналізу», а не дотримання якогось одного формату.

Під рядком заходів є ще один блок – передумови (pre-conditions): те, що має справдитися до виділення ресурсів і початку робіт.

Порядок заповнення: не зліва направо

Це те, що найбільше економить час, і майже ніколи не потрапляє в популярні пояснення. Комісія задає чітку послідовність із 13 кроків:

Спершу вся перша колонка згори вниз – загальна мета, мета проєкту, продукти, заходи (кроки 1–4). Далі припущення знизу вгору – від рівня заходів до рівня мети (кроки 5–7). І лише потім індикатори та джерела перевірки, згори вниз (кроки 8–13).

Логіка проста: не можна придумати індикатор для формулювання, яке ще змінюватиметься. Хто починає з індикаторів, переписує їх двічі.

Дві логіки, які перевіряє оцінювач

Вертикальна читається як ланцюг «якщо – то»: якщо надано ресурси, то можна виконати заходи; якщо заходи виконано, то зʼявляться продукти; якщо є продукти, то буде досягнуто мету; якщо мету досягнуто, то це зробить внесок у загальну мету. На кожному стику додається умова «і справдилися припущення цього рівня» – саме тому логіка називається зиґзаґоподібною.

Перевіряти зв'язність варто тестом «необхідно і достатньо», і тут Комісія формулює асиметрію, яку варто запамʼятати: заходи мають бути необхідними й достатніми для отримання продуктів, а от продукти для досягнення мети – лише необхідними, але, можливо, недостатніми; так само мета для загальної мети. Якщо ви стверджуєте, що ваші продукти достатні для досягнення мети, ви або перебільшуєте, або неправильно визначили рівень.

Горизонтальна читається в межах одного рядка: рівень – індикатор – джерело – припущення. Вона відповідає на питання «чи зможемо ми довести, що це сталося».

Індикатори: QQT і те, що ЄК називає SMART

Власна формула Комісії – QQT: індикатор описує ціль у вимірюваних термінах кількості, якості й часу. Приклад із методички: «концентрація сполук важких металів і неочищених стоків» + «зменшена на 25% порівняно з рівнем 2003 року» + «і відповідає національним нормам» + «до кінця 2007 року».

Обережно з абревіатурою SMART. Комісія розшифровує її не так, як у більшості тренінгів: Specific, Measurable, Available at an acceptable cost (а не Achievable), Relevant to the information needs of managers (а не просто Relevant), Time-bound. Різниця не косметична: у версії ЄК два з пʼяти критеріїв стосуються не цілі, а вартості й корисності вимірювання. Якщо індикатор надто дорого міряти – його треба замінити на непрямий (proxy), і це не компроміс, а вимога.

І ще одне, що рятує від суперечок на воркшопах: SMART використовують не всі донори. У ADS 201 і ADS 303 USAID цього акроніма немає взагалі, як немає його і в посібнику з управління за результатами UNDG – там натомість свої чек-листи критеріїв індикатора. У UNDP «A» означає Achievable для результатів і Attainable для індикаторів. Тобто SMART – корисна рамка, а не універсальний стандарт.

Кілька правил, які Комісія називає прямо: індикатори мають бути незалежними один від одного, кожен стосується рівно одного рівня; індикатор рівня продукту не повинен бути переказом заходу; «обʼєктивно верифікований» означає, що різні люди, вимірявши, отримають той самий результат; і – окремо – «слід уникати пастки надто великої кількості індикаторів».

Джерело перевірки має вказувати три речі: як інформація збирається, хто її збирає і як часто. Записати «звіти проєкту» без цих деталей – помилка, названа в методичці прямо.

Припущення: алгоритм, а не інтуїція

Припущення – зовнішні чинники, здатні вплинути на успіх проєкту або навіть визначити його, але поза прямим контролем керівництва. Формулюють їх як позитивне твердження про бажаний стан, а не як ризик: не «партнер може вийти з проєкту», а «партнер зберігає участь протягом усього періоду».

Комісія дає готовий алгоритм відбору. Спитайте, чи припущення важливе: якщо ні – не вносьте його в матрицю. Якщо важливе, спитайте, чи воно справдиться. Майже напевно справдиться – не вносити. Можливо справдиться – вносити, це і є ті припущення, яким місце в матриці. Дуже малоймовірно – тоді останнє питання: чи можна перепроєктувати проєкт так, щоб вплинути на цей чинник. Якщо так – додайте заходи або продукти й за потреби переформулюйте мету. Якщо ні – методичка формулює висновок без евфемізмів: проєкт, імовірно, нездійсненний.

Термін «killer assumption», який часто вживають у тренінгах, в офіційних документах Комісії та в глосарії OECD-DAC не зустрічається. Це практичний жаргон для останньої гілки цього алгоритму, а не термін методології – варто знати, якщо пишете для оцінювача.

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

Найчастіша помилка у формулюваннях

Комісія називає її прямо: мету проєкту формулюють як переказ суми продуктів, а не як досягнення вищого рівня.

Погано: «Покращено очищення води і зменшено обсяг прямих скидів у річку» – це просто перелік продуктів.
Добре: «Покращено якість води в річці» – це стан, заради якого продукти й робилися.

Серед інших помилок із офіційного переліку: зведення цілей до спрощеного лінійного ланцюга; нереалістичні цільові значення, встановлені надто рано; використання матриці як інструменту жорсткого контролю згори; і – дослівно – заповнення матриці «механістично, як бюрократичної вимоги заповнити клітинки», у відриві від аналізу проблем і вибору стратегії. Там же зафіксовано наслідок: матриця «стає фетишем, а не допомогою».

Сім типових помилок із розбором на живому прикладі – у повному гіді GetGrant.

«4×4» – формулювання USAID, а не ЄК

Це варто знати, бо саме звідси береться половина плутанини. Європейська Комісія ніколи не називала матрицю «4×4». У методичці сказано: «чотири колонки і певна кількість рядків – зазвичай три або чотири», а у виносці прямо заохочується додавати рівні, якщо в користувача є для цього підстави. «Базовою матрицею 4×4» свою версію називає USAID.

Чинний шаблон ЄС має сім колонок: ланцюг результатів, індикатор, базове значення, цільове значення, поточне значення, джерело й спосіб перевірки, припущення. Рівні з 2015 року називаються Impact – Outcome – Output (замість Overall objective – Purpose – Results), а з 2016-го додано проміжні результати. Заходи винесені в окрему Activity Matrix із колонками «Заходи – Ресурси й витрати – Припущення».

Дві деталі чинного шаблону, які легко пропустити. На рівні Impact у колонці припущень стоїть «не застосовується» – припущень там немає за задумом. І зміна назв Results → Outputs була не косметичною: раніше в цей рядок клали і output-, і outcome-індикатори, тепер очікуються лише output-індикатори.

Ще одна асиметрія, про яку варто знати: методологія лишається зразка 2004 року (опублікованого наступника Комісія так і не випустила), а шаблон заявки – 2019-го. Тому беріть шаблон із документів свого конкурсу, а методичку читайте як пояснення логіки, не як опис форми.

Хто вимагає матрицю

Зовнішня діяльність ЄС – вимагає. Логфрейм є в переліку додатків до заявки (Annex C) і потім входить в опис дії у самому контракті; оновлену матрицю подають з кожним звітом.

FCDO (колишній DFID) – найжорсткіша вимога серед великих донорів: з січня 2011 логфрейм є невідʼємною частиною Business Case для кожного проєкту незалежно від суми. Формат свій: Excel, рівні Impact/Outcome/Output, індикатор розкладений на базове значення, віхи й ціль, а на рівні Output кожен результат має вагу впливу (сума ваг – 100%).

Horizon Europe – логфрейму не вимагає: у стандартному шаблоні заявки цього слова немає жодного разу. Замість нього – impact pathway і Impact canvas у частині B. Поширена помилка – вважати, що PIC і логфрейм ідуть у комплекті; це різні режими фінансування ЄС.

USAID – і тут найпоширеніша хибна теза в україномовних матеріалах. У чинній політиці агентства (ADS 201 і ADS 303) слово «logical framework» не зустрічається жодного разу: обовʼязковим є Results Framework у страновій стратегії, а логфрейм згадано лише як один із дозволених видів логічної моделі. Якщо конкретний конкурс просив матрицю – це було рішення місії, а не вимога агентства. Додаткове застереження: USAID як самостійне агентство припинило роботу 1 липня 2025 року, тож усе це сьогодні методологічна довідка, а не чинна вимога донора.

Агенції ООН працюють радше з results frameworks: у UNDP обовʼязковим є розділ Results Framework у шаблоні проєктного документа плюс теорія змін, а не класична матриця.

Матриця і теорія змін

Матриця фіксує, що зміниться і як це перевірити. Теорія змін пояснює, чому одне веде до іншого. У глосарії OECD-DAC теорія змін подається не як альтернатива логфрейму, а як термін тієї самої сімʼї – поряд із логікою втручання та рамкою результатів.

Поширене протиставлення – логфрейм лінійний і статичний, теорія змін нелінійна й пояснювальна – походить з академічної та тренінгової літератури, а не з нормативних вимог донорів. Офіційного порівняння «пліч-о-пліч» від ЄК, OECD чи ООН не існує. Практично донори дедалі частіше просять обидва документи: теорію змін – у змістовій частині, матрицю – у додатках.