Компанія готується до угоди, змінює підрядника, виходить на новий ринок або відновлює сайт після збою. У кожному з цих сценаріїв виникає одне й те саме питання: з чого складається цифрова система компанії, хто її контролює і чи продовжить вона працювати після зміни людей. Відповідь визначає, скільки коштує сайт в угоді і скільки коштуватиме його розвиток далі; діагностика продажів і присутність бренду в AI-відповідях лишаються за межами цієї статті.
Цифровий актив має п’ять рівнів складу: права, інфраструктура, програмна частина, дані з контентом і накопичена комерційна видимість. Для цілей цієї статті керований цифровий актив — це сукупність компонентів сайту і пов’язаних систем, для яких компанія може підтвердити право використання, адміністративний контроль, резервну копію і порядок передачі.
Стаття дає спосіб перевірити кожен рівень і зібрати результат у реєстр. Бухгалтерське та юридичне трактування компонентів визначають профільні фахівці за застосовними нормами; стаття показує, які питання їм поставити.
Цифровий актив має кілька рівнів
П’ять рівнів складу відповідають на питання «з чого складається система». Друга вісь відповідає на питання «як компанія цим володіє», і тут теж п’ять типів контролю.
Власність компанії: компонент, майнові права на який належать компанії за договором або законом. Приклад: вихідний код, написаний на замовлення, або тексти сайту. Адміністративний контроль: компонент належить сторонньому сервісу, а компанія контролює обліковий запис. Приклад: аналітика, Search Console, рекламні кабінети. Ліцензований компонент: право використання обмежене умовами ліцензії. Приклад: CMS, тема, плагіни, шрифти, стокові зображення, SaaS-сервіси. Зовнішній ресурс: компонент існує поза контролем компанії. Приклад: відгуки на сторонніх майданчиках, зовнішні посилання, згадки. Накопичений результат: стан, який змінюється ринком і пошуковими системами. Приклад: позиції та видимість.
Домен займає окреме місце: компанія має право користування за договором з реєстратором і контролює обліковий запис, тому для нього підтверджуються обидві речі: договір і доступ.
Матриця «рівень складу × тип контролю» показує, що саме потрібно підтвердити в кожній клітинці. Для коду це договір із переходом майнових прав і доступ до репозиторію. Для аналітики це обліковий запис на ім’я компанії з правами адміністратора. Для теми CMS це ліцензія з правом використання на цьому домені. Для позицій це історія в Search Console, яка залишається в компанії, тоді як сам результат може змінитися.
Бухгалтерське визнання нематеріального активу визначається застосовними стандартами обліку, і відповідь на нього дає бухгалтер компанії.
Інфраструктура забезпечує безперервність
Домен і DNS
Домен реєструється на компанію, а обліковий запис у реєстратора містить контактні дані компанії; контакти підрядника або окремого співробітника в записі домену створюють залежність. Перевіряються: назва реєстранта в записі домену, доступ до облікового запису реєстратора, двофакторна автентифікація, резервний доступ у другого адміністратора, дата продовження і платник. Той, хто контролює обліковий запис реєстратора, може змінити DNS або ініціювати перенесення домену. Правила перенесення залежать від реєстратора і зони, тому конкретні строки уточнюються в умовах реєстратора.
Хостинг і сервери
Договір на хостинг або сервер укладено на компанію, платежі проходять від компанії. Резервні копії існують, зберігаються окремо від сервера, і хтось перевіряв відновлення з них. Журнал змін на сервері дозволяє зрозуміти, що і коли змінилося. Перевірка проста: зробити відновлення тестового екземпляра з останньої копії і зафіксувати час і результат.
Репозиторій і розгортання
Вихідний код зберігається в репозиторії, де компанія має права власника; статус запрошеного учасника для компанії означає, що власником є хтось інший. Історія змін збережена, права учасників переглянуті, порядок випуску версії описаний, і попередню версію можна повернути. У моделі Inward Labs для послуги розробка та інтеграції клієнт отримує доступ до репозиторію і сервера, щомісячний звіт і документацію після завершення робіт.
Три питання дають відповідь про безперервність: чи зможе компанія завтра продовжити домен, відновити сайт із копії і випустити виправлення без участі попереднього виконавця.
Права визначають можливість використання
Технічний доступ і правова підстава — різні речі. Доступ до репозиторію дозволяє змінювати код; право використовувати і передавати цей код визначає договір і закон. Об’єкти, для яких підстава перевіряється: вихідний код, дизайн, тексти, зображення, відео, бази даних. Окремо перевіряються сторонні компоненти: CMS та її ліцензія, теми і плагіни, бібліотеки, шрифти, стокові матеріали, SaaS-сервіси і умови підрядників.
Для українського права підстава така. Комп’ютерні програми входять до переліку об’єктів авторського права. Майнові права на твір, створений за замовленням, переходять до замовника з моменту створення, якщо інше не передбачено договором. Майнові права на службовий твір переходять до роботодавця з моменту створення, якщо інше не передбачено. Особисті немайнові права залишаються в автора. Положення наведено для українського права; умови договору мають пріоритет у межах закону, а застосовність до конкретної ситуації перевіряє юрист.
Документи, які підтверджують право використання і передачі: договір з виконавцем із розділом про перехід майнових прав і акт передачі; службові завдання для штатних співробітників; ліцензії на шрифти, зображення, плагіни; умови SaaS з правилами експорту даних при припиненні підписки.
Перелік питань для юридичної перевірки: чи містить договір з виконавцем перехід майнових прав на код і дизайн; чи є підстави для використання кожного зображення і шрифту на сайті; чи дозволяють ліцензії CMS і плагінів передачу сайту іншому власнику; на кого зареєстровані SaaS-облікові записи і хто має право їх передати; чи оформлені службові твори штатних співробітників; який порядок передачі результатів при розірванні договору з виконавцем.
Власник забирає з цього розділу перелік правових питань для профільної перевірки; оцінку умов конкретних ліцензій стаття не дає.
Дані накопичують цінність
Дані розглядаються тут як історія, яку компанія зберігає і передає. Використання даних для діагностики продажів розібрано в статті про шлях від пошуку до продажу.
Аналітичні дані
Історія трафіку, подій, ключових подій і сегментів зберігається в обліковому записі сервісу аналітики. Перевіряються: власник облікового запису, наявність експорту, глибина збереженої історії. Обліковий запис на ім’я співробітника, який звільнився, або підрядника, з яким припинено роботу, означає втрату історії разом із доступом.
Комерційні дані
Товари, категорії, ціни, залишки, звернення, замовлення і транзакції мають єдине джерело істини: облікова система, CMS або CRM. Якщо джерел два і вони розходяться, історія стає ненадійною. Як зберегти керованість каталогу на тисячі позицій, описано в окремому матеріалі.
Дані про взаємодію
Внутрішній пошук, записи користувацьких сценаріїв, причини відмов і історія тестів накопичуються повільно і відновленню не підлягають. Компанія, яка втратила два роки історії тестів, починає перевірку гіпотез з нуля.
Для всіх трьох груп перевіряються якість, повнота, доступ, резервування, експорт і документування. Керівник отримує відповідь на два питання: яка історія буде втрачена при зміні облікового запису або системи і скільки коштує накопичити її заново.
Автоматизації зберігають виробничу логіку
Інтеграції з CRM, ERP, оплатою, доставкою і сповіщеннями є правилами роботи компанії, записаними в коді; окремий скрипт лише реалізує одне з таких правил. Розклад вивантаження залишків, правило створення угоди із заявки, обробка помилки оплати, винятки для окремих категорій — усе це виробнича логіка, яка продовжує працювати, поки хтось пам’ятає, як вона влаштована.
Інвентаризація автоматизацій фіксує для кожної: вхідні дані, вихідні дані, розклад, правила обробки, контроль помилок, винятки, власника і порядок відновлення після збою. У моделі Inward Labs інтеграції, налаштування і дані залишаються в інфраструктурі замовника, а документація передається після завершення робіт. Така інвентаризація показує, які процеси відтворювані після зміни людей і систем, а які тримаються на одній людині.
Пошукова видимість підсилює цифровий актив
Накопичена пошукова видимість, яку формують технічне SEO разом із розробкою, дає бізнесу доступ до наявного попиту, і в цьому її комерційна цінність. Водночас позиції та видимість відображають поточний стан і змінюються: Google прямо вказує, що відповідність вимогам, рекомендаціям і політикам не означає, що сторінка буде просканована, проіндексована або показана.
Тому розділяються дві речі. Структура сайту, сторінки, контент, технічні рішення, дані та історія розвитку залишаються в інфраструктурі компанії за умовами договору; це компоненти, які передаються. Позиції та видимість є результатом роботи цих компонентів на ринку; вони спостерігаються і не передаються. Зовнішні посилання і згадки не є власністю компанії: вони розміщені на чужих ресурсах і можуть зникнути без участі компанії; як ці публічні дані впливають на присутність бренду в AI-пошуку, розібрано в окремій статті.
Позиції та видимість не оголошуються власністю клієнта. Клієнту належать або передаються код, структура, контент, налаштування, дані, облікові записи, документація й автоматизації в межах договору. Видимість і позиції залишаються змінюваним результатом ринку і пошукових систем.
Так власник розрізняє компоненти, які належать компанії, і ринкові результати, які змінюються.
Передаваність показує якість активу
Передаваність перевіряється одним сценарієм: систему приймає новий співробітник, новий виконавець, внутрішній ІТ-відділ, покупець бізнесу або інвестор. Система передавана, якщо новий відповідальний за узгоджений строк отримує права, доступи, документацію та резервні копії і може випустити зміну без участі попереднього виконавця.
Умовний приклад. Нова команда в перший день запитує доступ до репозиторію, сервера, домену, аналітики і CRM, а також документацію інтеграцій. Вона знаходить репозиторій на особистому обліковому записі попереднього розробника, домен на реєстратора з контактом бухгалтера, який звільнився, і не знаходить опису, як залишки потрапляють із облікової системи на сайт. Кожна така знахідка перетворюється на задачу з власником і строком.
Критичні залежності від особистих облікових записів і конкретних спеціалістів фіксуються окремим списком. Документування знижує залежність, повністю її не усуває: документ описує систему на дату написання, а система змінюється.
Критерій передаваності і список залежностей — два перевірювані інструменти, з якими власник іде на переговори про угоду або передачу.
Інвестор перевіряє керованість і ризик
Технологічна перевірка перед угодою дивиться на ті самі компоненти під кутом ризику і вартості розвитку. Консалтингове керівництво Roland Berger з due diligence цифрових цілей поглинання, опубліковане у серпні 2023 року, виділяє зони перевірки: архітектура і масштабованість, безпека, процеси розробки і стан коду, дані та аналітика, команда, інтелектуальна власність, постачальники, відповідність вимогам і технічний борг. Керівництво дає структуру зон, статистики з нього стаття не наводить.
| Зона перевірки | Бізнес-наслідок | Хто перевіряє |
|---|---|---|
| Права і договори | Неможливість передати або використовувати компонент після угоди | Юрист |
| Архітектура і масштабування | Вартість зростання: чи витримає система подвоєння каталогу або трафіку | Технічний аудитор |
| Безпека | Ризик зупинки і витоку даних; регуляторні наслідки | Фахівець з безпеки |
| Якість даних | Ненадійна історія для рішень і звітності | Аналітик, фінансовий аудитор |
| Технічний борг | Кожна нова функція коштує дорожче за попередню | Технічний аудитор |
| Критичні залежності | Зупинка при звільненні однієї людини або відключенні одного сервісу | Технічний аудитор, керівник |
| Вартість розвитку | Бюджет на рік після угоди | Фінансовий аудитор разом із технічним |
| Безперервність роботи | Час відновлення після збою | Технічний аудитор |
Ця таблиця дає інвестору карту питань, які впливають на ризик угоди і вартість розвитку; юридичну, бухгалтерську і безпекову експертизу проводять профільні фахівці.
Реєстр фіксує склад цифрового активу
Реєстр зводить усі рівні в один документ. Обов’язкові рядки: домен, DNS/CDN, сервер, CMS, репозиторій, дизайн, контент, аналітика, Search Console, рекламні кабінети, CRM, інтеграції, резервні копії, документація. Для кожного рядка заповнюються вісім колонок.
| Актив | Розташування | Власник | Адміністратор | Підстава | Резерв | Передаваність | Критичність | Наступна перевірка |
|---|---|---|---|---|---|---|---|---|
| Домен | Реєстратор | Компанія (роль: фінансовий директор) | ІТ | Договір з реєстратором, обліковий запис на компанію | Резервний доступ у другого адміністратора | Зміна контактів облікового запису | Висока | Щокварталу |
| DNS / CDN | DNS-провайдер, CDN-провайдер | Компанія | ІТ | Договір, обліковий запис на компанію | Експорт налаштувань | Зміна адміністратора | Висока | Щокварталу |
| Сервер | Хостинг-провайдер | Компанія | Розробка | Договір, платник компанія | Копії поза сервером, перевірене відновлення | Передача доступу і документації | Висока | Щокварталу |
| CMS | Сервер компанії | Компанія | Розробка | Ліцензія CMS, ліцензії теми і плагінів | У складі копії сервера | Перевірити умови ліцензій | Висока | Раз на пів року |
| Репозиторій | Git-платформа | Компанія (роль: технічний лід) | Розробка | Договір із переходом майнових прав | Дзеркало або резервна копія | Передача прав власника | Висока | Щокварталу |
| Дизайн | Файли дизайн-системи | Компанія | Дизайнер | Договір, ліцензії на шрифти | Копія в сховищі компанії | Передача файлів і ліцензій | Середня | Раз на рік |
| Контент | CMS, сховище | Компанія | Редактор | Договори з авторами, ліцензії на зображення | У складі копії | Передача разом із CMS | Середня | Раз на рік |
| Аналітика | Сервіс аналітики | Компанія | Аналітик | Обліковий запис на компанію | Експорт історії | Зміна власника облікового запису | Висока | Щокварталу |
| Search Console | Сервіс Google | Компанія | SEO-фахівець | Обліковий запис на компанію, підтвердження домену | Експорт звітів | Додавання власника | Середня | Щокварталу |
| Рекламні кабінети | Рекламні платформи | Компанія | Маркетинг | Обліковий запис на компанію, платник компанія | Історія кампаній | Зміна адміністратора | Середня | Щокварталу |
| CRM | Сервіс CRM | Компанія | Sales Ops | Підписка на компанію | Експорт бази | Умови експорту при припиненні | Висока | Щокварталу |
| Інтеграції | Сервер, iPaaS | Компанія (власник процесу) | Розробка | Код за договором, ліцензії сервісів | Документація і копія коду | Документація входів, виходів, розкладів | Висока | Щокварталу |
| Резервні копії | Окреме сховище | Компанія | ІТ | Політика резервування | Перевірене відновлення | Передача доступу до сховища | Висока | Щомісяця |
| Документація | Сховище компанії | Компанія | Технічний лід | Внутрішній документ | Копія | Передається як є | Середня | Раз на пів року |
Рядки з порожніми клітинками або з відповіддю «невідомо» стають задачами. Реєстр переглядається у зазначені дати і додається до документів угоди або передачі.
Результат залишається в інфраструктурі клієнта
Договірна модель Inward Labs побудована на тому, що результат роботи належить компанії-замовнику. Код, тексти, налаштування, аналітичні матеріали, облікові записи та накопичені дані залишаються в інфраструктурі клієнта. Облікові записи створюються на компанію або переводяться під її контроль, якщо це передбачено роботою. Продовження використання результату від нового замовлення не залежить. Точний обсяг прав і порядок передачі визначає чинний договір, і саме з нього починається інвентаризація для клієнтів Inward Labs.
Що зробити власнику
- Призначити власника реєстру цифрового активу і заповнити чотирнадцять рядків; принципи роботи Inward Labs розглядають архітектуру, код, дані та пошукову видимість як взаємопов’язані активи бізнесу, і реєстр відображає саме цей склад. Відповідальний: керівник компанії або фінансовий директор. Документ: реєстр із цієї статті. Строк: два тижні.
- Перевірити адміністративний контроль над доменом, репозиторієм і аналітикою: обліковий запис на компанію, права власника, резервний доступ. Відповідальний: ІТ або технічний лід. Строк: тиждень.
- Передати юристу перелік із шести правових питань разом із договорами і ліцензіями. Відповідальний: юрист компанії. Строк: місяць.
- Провести тестове відновлення сайту з резервної копії і зафіксувати час. Відповідальний: розробка. Строк: два тижні.
- Зафіксувати дату наступної перевірки реєстру і включити реєстр у документи угоди або передачі. Відповідальний: власник реєстру. Строк: після заповнення.
ПРОВЕСТИ ІНВЕНТАРИЗАЦІЮ ЦИФРОВОГО АКТИВУ
Inward Labs зафіксує склад системи, власників, доступи, залежності та порядок передачі результатів.
