ЛАБОРАТОРНЫЕ РАБОТЫ № 6–7

Тема: «Практика выбора и управления ИТ-решениями: оценка, контракты и жизненный цикл»

Предприятие: ООО «ТехноСервис»

Ниже подготовлен единый отчёт по обеим лабораторным работам. Я буду придерживаться стиля студенческой работы: академическое изложение, понятные объяснения, таблицы, расчёты, обоснованные выводы и практические рекомендации.

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

Принятые исходные условия

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

Параметр Принятое значение
Количество сотрудников 150
Количество пользователей новой ИС 60
Количество офисов 3
Годовая выручка 800 млн руб.
Бюджет на внедрение 10 млн руб.
Бюджет на поддержку в год 3 млн руб.
Горизонт финансовой оценки 3 года
Ставка дисконтирования 12%
Планируемый срок внедрения 6 месяцев

Выбранная концепция решения: создание единой информационной системы на основе CRM, складского учёта и интеграции с существующей бухгалтерской системой 1С.

В качестве трёх альтернатив будут рассматриваться:

  • Вариант А — SaaS: облачная CRM и складская система с оплатой подписки.
  • Вариант Б — On-premise: локальная система на базе продуктов 1С с размещением на собственном сервере.
  • Вариант В — гибридный: локальная система 1С для складского учёта и интеграций, облачная CRM и сервис обработки обращений клиентов.

Гибридный вариант выбран в качестве предварительного фаворита. Окончательное решение будет принято после финансового сравнения.

ЧАСТЬ 1. ЛАБОРАТОРНАЯ РАБОТА № 6

Тема: Финансовая оценка и выбор ИТ-решения

1.1. Анализ требований и выбор типа решения

1.1.1. Анализ бизнес-проблем компании

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

Основные проблемы и возможные способы их решения представлены в таблице.

Бизнес-проблема Влияние на бизнес Возможное ИТ-решение Тип решения
Потеря заявок клиентов Потеря потенциальных продаж, снижение удовлетворённости клиентов Внедрение CRM и системы регистрации обращений Готовое ПО
Учёт клиентов в разных Excel-файлах Дублирование информации, ошибки, отсутствие единой базы клиентов Централизованная CRM с разграничением доступа Готовое ПО
Устаревшая Access-база склада Риск потери данных, ошибки в остатках, зависимость от старой технологии Миграция на современную систему складского учёта Гибридное
Отсутствие оперативной отчётности Руководство не получает актуальную информацию о продажах и остатках Внедрение аналитического модуля и BI-отчётности Готовое ПО
Ручной перенос данных между системами Потеря времени сотрудников, увеличение количества ошибок Интеграция CRM, склада и бухгалтерии через API Гибридное
Отсутствие единой истории взаимодействия с клиентом Сложность контроля качества обслуживания Единая карточка клиента с историей обращений и сделок Готовое ПО
Отсутствие централизованной поддержки клиентов Длительное время обработки заявок, отсутствие контроля сроков Внедрение Service Desk и системы тикетов Готовое ПО
Недостаточная защита персональных данных Риск утечки информации и нарушения требований законодательства Разграничение доступа, журналирование, резервное копирование и организационные меры защиты Гибридное

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

1.1.2. Функциональные и нефункциональные требования

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

Функциональные требования описывают, что должна делать система. Нефункциональные требования определяют, насколько качественно и безопасно она должна работать.

Категория Требование
Функциональные (CRM) Система должна обеспечивать создание и ведение единой базы клиентов
Функциональные (CRM) Необходимо хранение истории взаимодействия с каждым клиентом
Функциональные (CRM) Система должна поддерживать регистрацию сделок, контроль этапов продаж и назначение ответственных менеджеров
Функциональные (CRM) Должна обеспечиваться автоматическая регистрация обращений клиентов из электронной почты и сайта
Функциональные (склад) Система должна обеспечивать учёт поступления, перемещения и списания товаров
Функциональные (склад) Необходимо отображение актуальных складских остатков в режиме, близком к реальному времени
Функциональные (склад) Система должна поддерживать формирование отчётов по остаткам и движению товаров
Функциональные (интеграция) Необходимо обеспечить обмен данными с существующей 1С:Бухгалтерией
Функциональные (интеграция) Должна быть реализована интеграция с корпоративным сайтом WordPress
Функциональные (интеграция) Необходимо обеспечить автоматическую передачу информации между CRM и складской системой
Нефункциональные (производительность) Время открытия основных страниц системы не должно превышать 3 секунд при штатной нагрузке
Нефункциональные (производительность) Система должна поддерживать одновременную работу не менее 60 пользователей
Нефункциональные (безопасность) Должно быть реализовано разграничение прав доступа по ролям
Нефункциональные (безопасность) Должны вестись журналы действий пользователей и системных событий
Нефункциональные (безопасность) Необходимо обеспечить защиту персональных данных в соответствии с требованиями 152-ФЗ
Нефункциональные (безопасность) Должно выполняться регулярное резервное копирование данных
Нефункциональные (масштабируемость) Архитектура должна позволять увеличение количества пользователей минимум до 100 без полной замены системы
Нефункциональные (масштабируемость) Должна существовать возможность подключения дополнительных офисов и новых функциональных модулей

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

1.1.3. Выбор трёх альтернативных ИТ-решений

Для сравнения выбраны три архитектурных варианта. Они отличаются способом размещения, моделью лицензирования, затратами и ответственностью за техническое обслуживание.

Вариант А. Облачное SaaS-решение

Облачная CRM и складской сервис

CloudCRM: CRM-Software für KMU | Digitalwerk Oberland

digitalwerk-oberland.de

Предполагается использование готовой облачной CRM с модулем складского учёта и обработки обращений клиентов.

Преимущества:

  • Быстрое внедрение.
  • Отсутствие необходимости приобретать собственные серверы.
  • Обновление программного обеспечения выполняется поставщиком.
  • Возможность доступа из разных офисов.
  • Относительно низкие первоначальные затраты.

Недостатки:

  • Постоянные расходы на подписку.
  • Зависимость от интернет-соединения и поставщика.
  • Ограничения по индивидуальным доработкам.
  • Необходимость тщательно проверять условия обработки и хранения персональных данных.

Вариант Б. Локальное On-premise-решение

Система на базе продуктов 1С

Datacore Solutions

datacore.com.sa

Предполагается приобретение лицензий и развёртывание CRM и складского учёта на собственных серверах компании.

Возможная технологическая основа — 1С:Управление торговлей с дополнительными CRM-функциями и интеграцией с 1С:Бухгалтерией.

Преимущества:

  • Полный контроль над инфраструктурой.
  • Возможность индивидуальной настройки.
  • Контроль над размещением и хранением данных.
  • Независимость от постоянной облачной подписки.

Недостатки:

  • Значительные первоначальные затраты.
  • Необходимость самостоятельного администрирования.
  • Ответственность за обновление и резервное копирование.
  • Повышенные требования к квалификации ИТ-отдела.

Вариант В. Гибридное решение

Локальный складской учёт и облачная CRM

Hybrid Cloud: Balancing Security and Scalability | ziani rachid posted on the topic | LinkedIn

linkedin.com

Предполагается использование локальной системы 1С для складского учёта и интеграции с бухгалтерией, а облачной CRM и Service Desk — для работы с клиентами и обращениями.

Преимущества:

  • Сохранение контроля над критически важными учётными данными.
  • Удобная работа менеджеров через облачную CRM.
  • Возможность постепенно модернизировать инфраструктуру.
  • Снижение затрат на собственные серверы по сравнению с полностью локальной архитектурой.
  • Гибкость интеграции между компонентами.

Недостатки:

  • Необходимость настройки обмена данными.
  • Зависимость от двух поставщиков.
  • Более сложное управление интеграциями.
  • Необходимость согласования требований безопасности для облачных компонентов.

Предварительный вывод: для компании «ТехноСервис» наиболее перспективным выглядит гибридный вариант. Он позволяет сохранить существующую 1С:Бухгалтерию, модернизировать складской учёт и одновременно внедрить современную CRM.

1.2. Расчёт совокупной стоимости владения (TCO)

1.2.1. Исходные данные и допущения

Для сравнения вариантов используется показатель TCO (Total Cost of Ownership) — совокупная стоимость владения информационной системой за определённый период.

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

Расчёт выполняется на горизонте трёх лет.

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

В качестве ориентира для SaaS-модели можно использовать публичную тарифную сетку Битрикс24: облачные тарифы предусматривают оплату за организацию, а не за каждого пользователя отдельно. При этом окончательная стоимость проекта зависит от состава функций, интеграций и выбранного поставщика.

image

Bitrix24+1

Приняты следующие допущения:

  1. В системе работают 60 сотрудников.
  2. Все три варианта обеспечивают одинаковый базовый набор бизнес-функций.
  3. Расходы на поддержку и доработки учитываются ежегодно.
  4. Затраты на оборудование включаются только в варианты, где требуется собственная инфраструктура.
  5. Затраты на персонал включают дополнительную нагрузку на администрирование системы.
  6. Налоги и инфляция в расчёте не учитываются.
  7. Варианты сравниваются в одинаковых денежных условиях.

1.2.2. Расчёт TCO для трёх вариантов

Вариант А — SaaS

Статья затрат Сумма, млн руб.
CAPEX (год 0)
Лицензии и первоначальные настройки 0,00
Оборудование 0,00
Внедрение (услуги) 1,80
Обучение 0,30
Итого CAPEX 2,10
OPEX (ежегодно)
Подписка и поддержка 2,40
Зарплата администратора 0,30
Электроэнергия / хостинг 0,00
Доработки 0,40
Итого OPEX за год 3,10
OPEX за 3 года 9,30
ИТОГО TCO за 3 года 11,40

Вариант Б — On-premise

Статья затрат Сумма, млн руб.
CAPEX (год 0)
Лицензии 2,20
Оборудование 1,50
Внедрение (услуги) 3,00
Обучение 0,50
Итого CAPEX 7,20
OPEX (ежегодно)
Подписка / поддержка 0,90
Зарплата администратора 0,75
Электроэнергия / хостинг 0,18
Доработки 0,60
Итого OPEX за год 2,43
OPEX за 3 года 7,29
ИТОГО TCO за 3 года 14,49

Вариант В — гибридный

Статья затрат Сумма, млн руб.
CAPEX (год 0)
Лицензии 1,40
Оборудование 0,80
Внедрение (услуги) 2,40
Обучение 0,40
Итого CAPEX 5,00
OPEX (ежегодно)
Подписка / поддержка 1,20
Зарплата администратора 0,45
Электроэнергия / хостинг 0,18
Доработки 0,45
Итого OPEX за год 2,28
OPEX за 3 года 6,84
ИТОГО TCO за 3 года 11,84

Общая сравнительная таблица

Показатель Вариант А Вариант Б Вариант В
CAPEX 2,10 7,20 5,00
OPEX за 3 года 9,30 7,29 6,84
TCO за 3 года 11,40 14,49 11,84

1.2.3. Анализ структуры TCO

Рассмотрим долю капитальных и операционных расходов в общей стоимости владения.

Показатель SaaS On-premise Гибрид
CAPEX, % 18,4% 49,7% 42,2%
OPEX, % 81,6% 50,3% 57,8%

Вариант А — SaaS.

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

Вариант Б — On-premise.

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

Вариант В — гибридный.

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

Скрытые затраты, не включённые в расчёт:

  • Время сотрудников на освоение нового программного обеспечения.
  • Временное снижение производительности во время перехода на новую систему.
  • Очистка и устранение дубликатов в старых Excel-файлах.
  • Исправление ошибок и несоответствий в Access-базе.
  • Возможные расходы на дополнительную защиту информации.
  • Простой системы при обновлении или технических сбоях.
  • Дополнительные расходы на расширение лицензий.
  • Юридические и организационные мероприятия по соблюдению требований 152-ФЗ.

Вывод: по трёхлетнему TCO наиболее экономичным является облачный вариант. Гибридное решение дороже всего на 0,44 млн руб., однако предоставляет компании больше контроля над складскими и учётными данными. Полностью локальный вариант является наиболее дорогим.

1.2.4. Формулы для Excel

Для автоматизации расчётов можно использовать следующие формулы.

Показатель Формула Excel
CAPEX =SUM(B2:B5)
OPEX за год =SUM(B8:B11)
OPEX за 3 года =B12*3
TCO за 3 года =B6+B13
Доля CAPEX =B6/B14*100
Доля OPEX =B13/B14*100

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

1.3. Оценка выгод и расчёт ROI

1.3.1. Определение выгод от внедрения

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

Выгоды делятся на измеримые и качественные.

Выгода Тип Способ измерения Оценка, руб./год
Сокращение времени обработки заявок Измеримая Экономия рабочего времени сотрудников 1 200 000
Рост клиентской базы Измеримая Дополнительная маржинальная прибыль от новых клиентов 2 000 000
Снижение потерь от ошибок Измеримая Уменьшение затрат на исправление ошибок и потерь товара 800 000
Сокращение ручных операций Измеримая Снижение трудозатрат бухгалтерии, менеджеров и склада 1 000 000
Улучшение контроля складских остатков Измеримая Снижение потерь из-за неточных данных и ошибок учёта 600 000
Повышение лояльности клиентов Качественная Оценка NPS и количества повторных обращений Не включается
Улучшение управленческой отчётности Качественная Сокращение времени подготовки отчётов Не включается
Повышение информационной безопасности Качественная Результаты аудита безопасности Не включается

Суммарный ожидаемый измеримый эффект:

\[ 1\,200\,000+2\,000\,000+800\,000+ 1\,000\,000+600\,000=5\,600\,000 \]

Таким образом, ожидаемая ежегодная экономическая выгода составляет 5,6 млн руб.

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

Для сравнения архитектурных вариантов принимаются следующие прогнозы:

Вариант Экономическая выгода в год Обоснование
А — SaaS 5,6 млн руб. Быстрое внедрение стандартных процессов, но ограничения индивидуальной настройки
Б — On-premise 5,8 млн руб. Глубокая настройка процессов и интеграция с внутренними системами
В — гибрид 6,0 млн руб. Сочетание гибкости CRM и контроля складского учёта

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

1.3.2. Расчёт ROI, NPV и срока окупаемости

Для финансовой оценки используются три основных показателя.

1. ROI — рентабельность инвестиций.

Показывает, насколько полученные выгоды превышают затраты.

\[ ROI=\frac{\text{Выгода}-TCO}{TCO}\times100\% \]

2. NPV — чистая приведённая стоимость.

Позволяет оценить будущие денежные потоки с учётом стоимости денег во времени.

\[ NPV=\sum_{t=1}^{3}\frac{CF_t}{(1+r)^t}-I_0 \]

Где:

  • \(CF_t\) — чистый денежный поток за год;
  • \(r=0,12\) — ставка дисконтирования;
  • \(I_0\) — первоначальные инвестиции.

3. Payback Period — срок окупаемости.

\[ PP=\frac{\text{Первоначальные инвестиции}}{\text{Среднегодовой чистый эффект}} \]

Для расчёта NPV чистый денежный поток определяется как годовая выгода минус ежегодные расходы OPEX.

Расчёт варианта А — SaaS.

  • CAPEX = 2,10 млн руб.
  • OPEX = 3,10 млн руб./год.
  • Выгода = 5,60 млн руб./год.
  • Чистый денежный поток = 2,50 млн руб./год.

\[ ROI_A=\frac{16,8-11,4}{11,4}\times100 =47,37\% \]

\[ NPV_A=\frac{2,5}{1,12}+ \frac{2,5}{1,12^2}+ \frac{2,5}{1,12^3}-2,1 \]

\[ NPV_A=3,91\text{ млн руб.} \]

\[ PP_A=\frac{2,1}{2,5}=0,84\text{ года} \]

Расчёт варианта Б — On-premise.

  • CAPEX = 7,20 млн руб.
  • OPEX = 2,43 млн руб./год.
  • Выгода = 5,80 млн руб./год.
  • Чистый денежный поток = 3,37 млн руб./год.

\[ ROI_B=\frac{17,4-14,49}{14,49}\times100 =20,08\% \]

\[ NPV_B=\frac{3,37}{1,12}+ \frac{3,37}{1,12^2}+ \frac{3,37}{1,12^3}-7,2 \]

\[ NPV_B=0,87\text{ млн руб.} \]

\[ PP_B=\frac{7,2}{3,37}=2,14\text{ года} \]

Расчёт варианта В — гибрид.

  • CAPEX = 5,00 млн руб.
  • OPEX = 2,28 млн руб./год.
  • Выгода = 6,00 млн руб./год.
  • Чистый денежный поток = 3,72 млн руб./год.

\[ ROI_V=\frac{18-11,84}{11,84}\times100 =52,03\% \]

\[ NPV_V=\frac{3,72}{1,12}+ \frac{3,72}{1,12^2}+ \frac{3,72}{1,12^3}-5 \]

\[ NPV_V=3,94\text{ млн руб.} \]

\[ PP_V=\frac{5}{3,72}=1,34\text{ года} \]

Все показатели округлены до двух знаков после запятой.

1.3.3. Сводная таблица результатов

Показатель Вариант А Вариант Б Вариант В
TCO за 3 года 11,40 млн 14,49 млн 11,84 млн
Суммарная выгода за 3 года 16,80 млн 17,40 млн 18,00 млн
ROI 47,37% 20,08% 52,03%
NPV 3,90 млн 0,90 млн 3,93 млн
Payback Period 0,84 года 2,14 года 1,34 года

NPV в таблице округлён. Расчёт варианта Б составляет приблизительно 0,90 млн руб., варианта В — 3,93 млн руб.

Для наглядного сравнения рассмотрим рентабельность инвестиций.

Сравнение ROI

Рентабельность инвестиций за три года, %.

0%15%30%45%60%SaaSOn-premiseГибрид

1.3.4. Вывод по финансовой оценке

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

Он имеет следующие преимущества:

  • Наибольшая рентабельность инвестиций — 52,03%.
  • Наибольшая чистая приведённая стоимость — около 3,93 млн руб.
  • Более высокая ожидаемая экономическая выгода.
  • Относительно небольшой срок окупаемости — 1,34 года.
  • Возможность сохранить контроль над складскими данными и интеграцией с бухгалтерией.

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

On-premise-вариант обеспечивает максимальный контроль над инфраструктурой, но требует наиболее значительных первоначальных вложений.

Окончательный выбор — вариант В, гибридное решение.

Финансовый выбор совпадает с функциональным, поскольку гибридная архитектура лучше соответствует текущей инфраструктуре предприятия. Она позволяет не отказываться от 1С:Бухгалтерии, модернизировать складской учёт и централизовать работу с клиентами.

Следует отметить, что разница NPV между SaaS и гибридным вариантом невелика. Поэтому окончательное решение необходимо подтвердить результатами PoC, проверкой требований 152-ФЗ и коммерческими предложениями поставщиков.

1.4. Разработка процесса выбора и подготовка RFP

1.4.1. Фрагмент запроса предложений (RFP)

Запрос предложений на внедрение комплексной информационной системы для ООО «ТехноСервис».

1. Общая информация о заказчике

ООО «ТехноСервис» является региональной компанией, предоставляющей ИТ-услуги и поставляющей компьютерное оборудование для предприятий малого и среднего бизнеса.

Основные характеристики:

  • 150 сотрудников.
  • 3 офиса в разных городах.
  • Годовая выручка — 800 млн рублей.
  • Существующая бухгалтерская система — 1С:Бухгалтерия.
  • Складской учёт ведётся в устаревшей Access-базе.
  • Клиентская информация хранится в отдельных Excel-файлах.
  • Обращения клиентов принимаются через электронную почту и телефон.

2. Цели проекта

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

Ожидаемые результаты:

  1. Увеличение клиентской базы на 30% за два года.
  2. Сокращение времени обработки заявок с 4 часов до 30 минут.
  3. Снижение операционных затрат на 15%.
  4. Исключение потери клиентских обращений.
  5. Повышение точности складского учёта.
  6. Обеспечение выполнения требований законодательства о персональных данных.

3. Основные функциональные требования

№ Требование Приоритет
1 Создание единой базы клиентов Высокий
2 Ведение истории сделок и взаимодействия Высокий
3 Автоматическая регистрация заявок Высокий
4 Назначение ответственных менеджеров Высокий
5 Учёт поступления и списания товаров Высокий
6 Просмотр текущих складских остатков Высокий
7 Интеграция с 1С:Бухгалтерией Высокий
8 Интеграция с сайтом WordPress Средний
9 Формирование аналитических отчётов Средний
10 Контроль сроков обработки обращений Высокий

4. Нефункциональные требования

  • Время отклика основных операций — не более 3 секунд при штатной нагрузке.
  • Поддержка минимум 60 одновременных пользователей.
  • Возможность масштабирования до 100 пользователей.
  • Разграничение доступа на основе ролей.
  • Журналирование действий пользователей.
  • Защищённое соединение с использованием современных криптографических протоколов.
  • Регулярное резервное копирование.
  • Возможность восстановления данных после сбоя.
  • Выполнение требований 152-ФЗ.
  • Документированное API для интеграции с другими системами.

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

5. Бюджет проекта

Максимальный бюджет первоначального внедрения — 10 млн рублей.

Максимальный ежегодный бюджет сопровождения — 3 млн рублей.

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

6. Критерии оценки предложений

Для объективного сравнения предложений устанавливаются следующие критерии:

Критерий Вес
Соответствие функциональным требованиям 25%
Стоимость внедрения и владения 20%
Информационная безопасность 20%
Опыт и квалификация команды 10%
Возможности интеграции 10%
Условия поддержки и SLA 10%
Масштабируемость 5%
Итого 100%

Оценка каждого критерия производится по пятибалльной шкале.

Итоговый рейтинг рассчитывается по формуле:

\[ R=\sum_{i=1}^{n}\frac{B_i\times W_i}{5} \]

Где:

  • \(B_i\) — оценка поставщика по критерию;
  • \(W_i\) — вес критерия в процентах.

7. Формат ответа поставщика

Предложение должно содержать:

  • Описание предлагаемой архитектуры.
  • Перечень программных продуктов и лицензий.
  • Детальную смету.
  • План внедрения.
  • Сведения о проектной команде.
  • Описание мер информационной безопасности.
  • Проект SLA.
  • Референсы реализованных проектов.
  • Описание процедуры миграции данных.
  • Условия прекращения сотрудничества и передачи данных.

8. Сроки проведения закупки

Этап Срок
Публикация RFP 1 декабря
Приём предложений До 15 декабря
Анализ предложений 16–20 декабря
Демонстрации и PoC 21 декабря – 15 января
Выбор поставщика До 20 января
Заключение договора До 31 января

Даты являются плановыми и могут быть скорректированы руководством компании.

1.4.2. Чек-лист оценки подрядчиков

Для выбора надёжного поставщика необходимо провести комплексную оценку его возможностей.

№ Критерий Что необходимо проверить Оценка
1 Опыт в отрасли Наличие опыта внедрения CRM и складских систем 1–5
2 Команда проекта Квалификация аналитиков, разработчиков и руководителя проекта 1–5
3 Технологический стек Совместимость технологий с существующей инфраструктурой 1–5
4 Методология внедрения Наличие плана, этапов, тестирования и контроля качества 1–5
5 Бюджет и смета Прозрачность стоимости лицензий, услуг и сопровождения 1–5
6 SLA и поддержка Наличие гарантированных сроков реакции и восстановления 1–5
7 Сертификации Наличие необходимых сертификатов и подтверждений квалификации 1–5
8 Референсы Возможность связаться с предыдущими заказчиками 1–5
9 Информационная безопасность Наличие регламентов защиты информации и резервного копирования 1–5
10 Гарантии Условия устранения ошибок после запуска 1–5

По каждому критерию выставляется оценка от 1 до 5.

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

1.4.3. Критерии проведения PoC

PoC (Proof of Concept) — это проверка работоспособности предлагаемого решения на ограниченном наборе данных и типовых бизнес-сценариев.

Для компании «ТехноСервис» необходимо проверить пять ключевых сценариев.

Сценарий 1. Регистрация и обработка клиентской заявки.

Проверяется возможность поступления обращения с сайта или электронной почты в CRM.

Ожидаемый результат:

  • Заявка автоматически создаётся в системе.
  • Ей присваивается уникальный номер.
  • Назначается ответственный сотрудник.
  • Фиксируется время поступления.
  • Руководитель может контролировать статус заявки.

Критерий успешности: заявка появляется в CRM не позднее одной минуты после поступления.

Сценарий 2. Работа с клиентской базой.

Проверяется создание карточки клиента, поиск существующих записей и предотвращение дублирования.

Ожидаемый результат:

  • Единая карточка клиента.
  • Сохранение истории сделок.
  • Возможность поиска по названию организации и контактным данным.
  • Разграничение доступа сотрудников.

Критерий успешности: информация о клиенте доступна уполномоченному сотруднику и не дублируется при повторном обращении.

Сценарий 3. Складской учёт.

Проверяется регистрация поступления, перемещения и списания товара.

Ожидаемый результат:

  • Отображение актуальных остатков.
  • Сохранение истории операций.
  • Возможность формирования складского отчёта.
  • Отсутствие расхождений при контрольной сверке.

Критерий успешности: данные после выполнения тестовых операций полностью соответствуют контрольному учёту.

Сценарий 4. Интеграция с 1С:Бухгалтерией.

Проверяется обмен необходимыми справочниками и документами между системами.

Ожидаемый результат:

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

Критерий успешности: не менее 99% тестовых операций выполняются без ошибок, остальные корректно фиксируются и доступны для повторной обработки.

Сценарий 5. Информационная безопасность и отказоустойчивость.

Проверяются права доступа, резервное копирование и восстановление тестовой базы.

Ожидаемый результат:

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

Критерий успешности: все проверки доступа пройдены, тестовое восстановление завершено успешно.

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

1.5. Итоговый отчёт и рекомендации

1.5.1. Аналитическая записка для руководства ООО «ТехноСервис»

Тема: Обоснование выбора и внедрения комплексной информационной системы.

В ходе исследования текущего состояния информационной инфраструктуры ООО «ТехноСервис» были выявлены проблемы, связанные с разрозненным хранением информации, использованием устаревшей складской базы Access, отсутствием единой CRM и ручной обработкой обращений клиентов.

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

Для решения выявленных проблем были рассмотрены три альтернативных варианта: облачная SaaS-система, локальная On-premise-система и гибридная архитектура.

По результатам финансового анализа установлено, что трёхлетняя стоимость владения составляет:

  • SaaS — 11,40 млн рублей.
  • On-premise — 14,49 млн рублей.
  • Гибрид — 11,84 млн рублей.

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

Расчётный ROI гибридного решения составляет 52,03%, NPV — около 3,93 млн рублей, срок окупаемости — 1,34 года.

Рекомендуется внедрить гибридную информационную систему, включающую локальный модуль складского учёта, интеграцию с существующей 1С:Бухгалтерией и облачную CRM с системой обработки обращений.

Рекомендуемый бюджет:

Статья Сумма
Лицензии 1,40 млн руб.
Оборудование 0,80 млн руб.
Внедрение 2,40 млн руб.
Обучение 0,40 млн руб.
Первоначальный бюджет 5,00 млн руб.
Ежегодное сопровождение 2,28 млн руб.

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

Срок реализации проекта предлагается установить равным шести месяцам.

Основные риски проекта:

  1. Ошибки при миграции данных из Access и Excel. Для снижения риска необходимо провести предварительную очистку и тестовую миграцию.
  2. Нарушение обмена данными между системами. Необходимо разработать механизм контроля интеграции и регистрации ошибок.
  3. Сопротивление сотрудников изменениям. Предусмотреть обучение и постепенный переход на новую систему.
  4. Утечка персональных данных. Использовать разграничение прав, шифрование, аудит доступа и проверку условий работы облачного поставщика.
  5. Зависимость от поставщика CRM. Предусмотреть возможность экспорта данных и документирование интеграций.

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

Расчётный экономический эффект гибридного варианта составляет 6 млн рублей в год. Данный показатель является плановым и должен быть подтверждён после внедрения системы.

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

1.5.2. Общий вывод по лабораторной работе № 6

В ходе выполнения лабораторной работы были изучены основные методы финансовой оценки ИТ-инвестиций и порядок выбора информационных систем.

Были проанализированы бизнес-проблемы компании «ТехноСервис», сформированы функциональные и нефункциональные требования, рассмотрены три варианта построения информационной системы.

С помощью расчёта TCO, ROI, NPV и срока окупаемости проведено финансовое сравнение альтернатив. Наиболее предпочтительным оказался гибридный вариант, объединяющий преимущества локальной инфраструктуры и облачных сервисов.

Также были разработаны фрагмент RFP, чек-лист оценки подрядчиков и критерии проведения PoC.

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

ЧАСТЬ 2. ЛАБОРАТОРНАЯ РАБОТА № 7

Тема: Контракты, SLA и управление жизненным циклом информационных систем

2.1. Анализ типового ИТ-контракта

2.1.1. Выбор типового договора

Для анализа выбран опубликованный в открытом доступе документ:

«Публичная оферта на предоставление доступа к сервису БИК», разработчик — ООО «368».

Документ опубликован на официальном сайте сервиса БИК, редакция от 22 июля 2026 года.

Сервис БИК предназначен для синхронизации задач, сообщений и файлов между порталами Битрикс24. Доступ предоставляется по модели SaaS.

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

Источник: Публичная оферта на предоставление доступа к сервису БИК.

image

БИК

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

2.1.2. Анализ основных разделов договора

Раздел договора Что написано в договоре Риски для заказчика Как можно улучшить
Предмет договора Исполнитель предоставляет право использования сервиса по модели SaaS на условиях простой неисключительной лицензии Не гарантируется выполнение всех индивидуальных требований заказчика Подробно описать функциональность, технические характеристики и состав услуг
Права на ПО / результат Исключительные права на сервис принадлежат исполнителю. Заказчику предоставляется право использования на оплаченный период Заказчик зависит от правообладателя и не может самостоятельно изменять программный продукт Закрепить право заказчика на собственные данные, интеграции и результаты оплаченных индивидуальных доработок
Финансовые условия Оплата производится по тарифам. Исполнитель может изменять стоимость с уведомлением за 30 дней Увеличение стоимости подписки может привести к незапланированным расходам Зафиксировать стоимость на первый год и установить порядок изменения тарифов
Гарантии и ответственность Ответственность исполнителя ограничена суммой оплаты за три месяца. Сервис предоставляется «как есть» Ограниченная компенсация может не покрыть реальные убытки при серьёзном сбое Установить отдельные гарантии качества, ответственности и компенсации за нарушение SLA
Порядок приёмки Услуги считаются оказанными, если возражения не поступили в течение пяти рабочих дней Заказчик может не успеть обнаружить скрытые недостатки Предусмотреть приёмочные испытания и более длительный период проверки
Конфиденциальность Исполнитель обязуется сохранять конфиденциальность данных и принимать меры защиты Не все технические и организационные меры безопасности подробно раскрыты в основном договоре Добавить отдельное соглашение о конфиденциальности и приложение с требованиями к защите данных
Срок действия и расторжение Заказчик может отказаться от договора в любое время. Исполнитель вправе приостановить доступ при нарушениях Возможна внезапная остановка сервиса при спорной ситуации Предусмотреть обязательное предварительное уведомление и период для устранения нарушения
Условия выхода (Exit) После расторжения данные удаляются в сроки, установленные политикой обработки персональных данных Нет достаточно подробного описания процедуры передачи данных и перехода на другую систему Установить сроки экспорта, форматы файлов, порядок передачи резервных копий и подтверждение удаления данных

Условия договора подтверждаются его разделами 2, 4–9. В частности, договор предусматривает доступность 99% в месяц, ограниченную компенсацию за нарушение SLA и удаление данных после расторжения.

image

БИК

Общий вывод по анализу договора:

Договор содержит основные условия предоставления SaaS-сервиса, однако в нём недостаточно подробно урегулированы вопросы защиты интересов крупного корпоративного заказчика.

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

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

2.1.3. Выбор типа контракта

Существуют три основных типа контрактов на выполнение ИТ-проектов.

1. Fixed Price (фиксированная стоимость).

Исполнитель обязуется выполнить заранее определённый объём работ за установленную цену.

Преимущества:

  • Предсказуемость бюджета.
  • Понятные условия оплаты.
  • Удобство контроля исполнения.

Недостатки:

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

2. Time & Materials (оплата по фактическим затратам).

Заказчик оплачивает фактически затраченное время специалистов и использованные материалы.

Преимущества:

  • Гибкость при изменении требований.
  • Возможность постепенно развивать систему.
  • Удобство для исследовательских и интеграционных задач.

Недостатки:

  • Сложнее прогнозировать итоговую стоимость.
  • Есть риск превышения бюджета.
  • Необходим постоянный контроль трудозатрат.

3. Гибридный контракт.

Объединяет элементы двух предыдущих моделей. Основной объём работ выполняется за фиксированную стоимость, а дополнительные изменения оплачиваются по фактическим затратам.

Сравнение моделей контрактов

Критерий Fixed Price Time & Materials Гибрид
Предсказуемость бюджета Высокая Низкая Высокая для основного объёма
Гибкость Низкая Высокая Высокая
Риск заказчика Изменения требований Рост затрат Контролируемый
Подходит для внедрения Да Частично Да

Рекомендуемый тип контракта для «ТехноСервиса» — гибридный.

Обоснование:

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

В то же время интеграция с существующей 1С, сайтом WordPress и возможные индивидуальные доработки могут потребовать дополнительных работ.

Поэтому рекомендуется:

  • Основные работы по внедрению — Fixed Price.
  • Дополнительные интеграции и доработки — Time & Materials с предварительным согласованием бюджета.
  • Техническая поддержка — отдельный договор с фиксированной ежемесячной оплатой и SLA.

Такая модель позволит контролировать расходы и одновременно сохранять возможность развития системы.

2.1.4. Красные флаги в договоре

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

Красный флаг Возможные последствия Рекомендуемое изменение
Ограничение ответственности тремя месяцами оплаты Недостаточная компенсация при серьёзном инциденте Установить отдельные условия ответственности за нарушение конфиденциальности и требований безопасности
Возможность одностороннего изменения условий Неожиданное изменение правил обслуживания Уведомление минимум за 60 дней и право заказчика отказаться без штрафа
Доступность 99% Суммарное время простоя может быть значительным Повысить целевую доступность до 99,5%
Короткий срок для возражений по приёмке Скрытые ошибки могут остаться незамеченными Установить приёмочный период не менее 10 рабочих дней
Недостаточная детализация Exit Plan Риск потери данных при смене поставщика Закрепить процедуру экспорта и передачи информации
Удаление данных после расторжения Возможность потери информации до её переноса Предусмотреть переходный период не менее 30 дней

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

2.2. Разработка SLA (Service Level Agreement)

2.2.1. Проект соглашения об уровне обслуживания

SLA (Service Level Agreement) — это соглашение между заказчиком и поставщиком ИТ-услуг, которое определяет качество обслуживания, сроки реакции на инциденты и ответственность сторон.

Для компании «ТехноСервис» SLA разрабатывается для гибридной информационной системы, включающей CRM, складской учёт и интеграционные сервисы.

1. Предмет SLA

Соглашение распространяется на следующие компоненты:

  1. CRM-система.
  2. Модуль складского учёта.
  3. Интеграция с 1С:Бухгалтерией.
  4. Интеграция с корпоративным сайтом.
  5. Сервис обработки клиентских обращений.
  6. Система резервного копирования.

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

2. Классификация инцидентов

Для определения приоритетов все инциденты делятся на четыре уровня.

Уровень Описание Примеры
P1 — критичный Полная недоступность системы или серьёзная потеря данных CRM недоступна всем пользователям, остановлена работа склада, обнаружена серьёзная утечка данных
P2 — высокий Нарушена работа важной функции, существенно затрудняющей деятельность Не работает обмен с 1С, массово не регистрируются заявки
P3 — средний Частичная неисправность, при которой основные процессы продолжают работать Ошибка формирования отдельных отчётов, сбой одной функции CRM
P4 — низкий Незначительные ошибки и консультационные вопросы Запрос на изменение интерфейса, вопрос по настройке отчёта

3. Метрики и целевые значения (SLO)

Для системы устанавливаются следующие показатели качества обслуживания.

Метрика Целевое значение Как измеряется
Доступность сервиса (Uptime) Не менее 99,5% в месяц По журналам мониторинга
Время реакции на P1 Не более 15 минут От регистрации инцидента до начала работы специалиста
Время реакции на P2 Не более 30 минут По системе регистрации обращений
Время реакции на P3 Не более 4 часов По журналам Service Desk
Время реакции на P4 Не более 8 рабочих часов По журналам Service Desk
Время восстановления P1 Не более 4 часов От регистрации до восстановления сервиса
Время решения P2 Не более 8 часов От регистрации до устранения проблемы
Время решения P3 Не более 3 рабочих дней По системе тикетов
Время решения P4 Не более 5 рабочих дней По системе тикетов
Резервное копирование Ежедневно По журналам выполнения заданий
Проверка восстановления Не реже одного раза в квартал По результатам тестового восстановления

Время реакции означает начало работы над проблемой, а не её окончательное устранение.

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

4. Компенсации и штрафные санкции

Для стимулирования поставщика соблюдать установленные показатели предлагается следующая система компенсаций.

Фактическая доступность за месяц Компенсация от месячной стоимости обслуживания
99,5% и выше 0%
От 99,0% до 99,49% 5%
От 98,0% до 98,99% 10%
От 95,0% до 97,99% 20%
Менее 95,0% 30%

Формула расчёта компенсации:

\[ K=C\times P \]

Где:

  • \(K\) — сумма компенсации;
  • \(C\) — стоимость ежемесячного обслуживания;
  • \(P\) — установленный процент компенсации.

Например, если стоимость ежемесячного обслуживания составляет 190 000 рублей, а доступность снизилась до 98,5%, компенсация составит:

\[ K=190\,000\times0,10=19\,000 \]

Таким образом, поставщик должен предоставить заказчику компенсацию в размере 19 000 рублей.

Компенсация предоставляется в виде уменьшения следующего платежа или возврата денежных средств по согласованию сторон.

Дополнительно предлагается предусмотреть отдельную ответственность за повторяющиеся нарушения сроков реакции на критичные инциденты.

5. Исключения из SLA

Не учитываются при расчёте доступности:

  • Плановые технические работы, согласованные с заказчиком заранее.
  • Форс-мажорные обстоятельства.
  • Сбои внешних сервисов, не находящихся под контролем поставщика.
  • Отказ оборудования заказчика, если он не входит в зону ответственности исполнителя.
  • Нарушения, вызванные действиями пользователей заказчика.
  • Проблемы интернет-провайдера заказчика.

Плановые работы должны проводиться преимущественно в нерабочее время. О них необходимо уведомлять заказчика минимум за 48 часов.

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

Вывод по SLA: разработанные показатели позволяют установить измеримые требования к качеству обслуживания. Наиболее важными являются доступность не менее 99,5%, реакция на критичный инцидент в течение 15 минут и восстановление работоспособности не более чем за 4 часа.

2.2.2. Построение дерева SLA (SLA Tree)

Для компании «ТехноСервис» в качестве ключевого сервиса выбрана система обработки клиентских обращений.

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

Связь бизнес-целей, технических показателей и внутренних обязательств представлена ниже.

CUSTOMER OUTCOME

Обработка заявки за 30 минут

Сокращение времени обслуживания клиентов

PROVIDER SLO

Технические показатели поставщика

  • Доступность CRM ≥ 99,5%
  • Регистрация заявки ≤ 1 минуты
  • Реакция на P1 ≤ 15 минут
  • Восстановление P1 ≤ 4 часов

INTERNAL OLA

Внутренние обязательства ИТ-команды

  • Мониторинг системы 24/7 для P1
  • Проверка интеграций каждые 15 минут
  • Ответственный за инциденты назначается сразу
  • Резервное копирование ежедневно
  • Контроль исполнения заявок

Пояснение к схеме:

Customer Outcome определяет результат, который важен конечному клиенту.

Provider SLO описывает технические показатели, которые должен обеспечить поставщик.

Internal OLA определяет внутренние обязательства ИТ-отдела и других подразделений компании, необходимые для достижения согласованного уровня обслуживания.

Таким образом, дерево SLA связывает требования бизнеса с техническими характеристиками системы и действиями сотрудников.

2.3. Анализ управления жизненным циклом информационной системы

2.3.1. Этапы жизненного цикла выбранного ИТ-решения

Жизненный цикл информационной системы (ЖЦ ИС) — это совокупность этапов, которые система проходит от возникновения идеи её создания до окончательного вывода из эксплуатации.

Для гибридной системы компании «ТехноСервис» выделяются пять основных этапов.

Этап ЖЦ Что происходит? Кто отвечает? Ключевые риски
Планирование и выбор Анализ бизнес-процессов, формирование требований, выбор поставщика и расчёт бюджета Руководство, руководитель ИТ-отдела, аналитик Ошибки в требованиях, неправильный выбор системы
Внедрение Установка программного обеспечения, настройка модулей, интеграция и перенос данных Подрядчик, разработчики, системный администратор Срыв сроков, потеря данных, несовместимость систем
Эксплуатация и поддержка Повседневное использование системы, мониторинг, резервное копирование, устранение неисправностей ИТ-отдел, поставщик, пользователи Сбои, потеря информации, нарушение SLA
Модернизация Добавление новых функций, обновление программного обеспечения, расширение системы Руководитель ИТ-отдела, подрядчик, аналитик Рост затрат, несовместимость обновлений
Вывод из эксплуатации Перенос данных, отключение старой системы, удаление устаревших компонентов Руководитель ИТ-отдела, руководство, поставщик Потеря данных, нарушение доступа к архивам

Пояснение этапов:

1. Планирование и выбор.

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

2. Внедрение.

Происходит установка системы, настройка CRM и складского учёта, интеграция с бухгалтерией и перенос информации из старых баз данных.

3. Эксплуатация и поддержка.

Система используется сотрудниками в повседневной деятельности. ИТ-отдел контролирует работоспособность, выполняет резервное копирование и взаимодействует с поставщиком.

4. Модернизация.

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

5. Вывод из эксплуатации.

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

2.3.2. Применение фреймворка ITIL на этапе эксплуатации

Для организации эффективной эксплуатации информационной системы предлагается использовать рекомендации фреймворка ITIL 4.

ITIL представляет собой набор рекомендаций по управлению ИТ-услугами и повышению их качества.

Для компании «ТехноСервис» предлагается организовать следующие процессы.

1. Управление инцидентами (Incident Management).

Основная задача — максимально быстро восстановить работоспособность системы.

Порядок работы:

  1. Пользователь сообщает о неисправности через Service Desk.
  2. Система регистрирует обращение и присваивает номер.
  3. Инциденту назначается приоритет P1–P4.
  4. Ответственный специалист начинает диагностику.
  5. После устранения неисправности пользователь получает уведомление.
  6. Инцидент закрывается после проверки работоспособности.

Например, если складской модуль перестал отображать остатки, обращение регистрируется как P1 или P2 в зависимости от масштаба проблемы.

2. Управление проблемами (Problem Management).

Основная задача — выявлять и устранять причины повторяющихся инцидентов.

Если одна и та же ошибка регулярно возникает при обмене данными между CRM и 1С, ИТ-отдел должен не просто устранять последствия, а найти первопричину.

Для этого необходимо:

  • Анализировать повторяющиеся инциденты.
  • Выявлять общие причины ошибок.
  • Создавать базу известных ошибок.
  • Разрабатывать постоянные решения.
  • Контролировать отсутствие повторных сбоев.

3. Управление изменениями (Change Enablement).

Любые существенные изменения системы должны проходить предварительную оценку.

Например, перед изменением структуры базы данных необходимо:

  • Зарегистрировать запрос на изменение.
  • Оценить его необходимость.
  • Проанализировать риски.
  • Согласовать сроки и стоимость.
  • Создать резервную копию.
  • Провести тестирование.
  • Утвердить изменение перед внедрением.

Критические изменения должны согласовываться руководителем ИТ-отдела и ответственным представителем бизнеса.

4. Управление релизами (Release Management).

Данный процесс обеспечивает контролируемое внедрение новых версий программного обеспечения.

Предлагается следующая последовательность:

  1. Получение новой версии от поставщика.
  2. Проверка изменений.
  3. Тестирование на отдельном стенде.
  4. Проверка интеграций.
  5. Согласование даты обновления.
  6. Создание резервной копии.
  7. Установка обновления.
  8. Контроль работоспособности.

Обновления сначала устанавливаются в тестовой среде, а затем переносятся в рабочую систему.

5. Управление уровнем сервиса (Service Level Management).

Данный процесс обеспечивает контроль выполнения условий SLA.

Для этого необходимо:

  • Ежемесячно измерять доступность системы.
  • Контролировать время реакции на инциденты.
  • Проверять сроки восстановления.
  • Формировать отчёты для руководства.
  • Анализировать нарушения SLA.
  • Проводить встречи с поставщиком для обсуждения качества услуг.

Вывод: применение ITIL позволит перейти от устранения проблем по мере их возникновения к систематическому управлению ИТ-услугами. Это особенно важно для компании, поскольку новая система станет основой повседневной работы отдела продаж, склада и клиентской поддержки.

2.3.3. Оценка зрелости процессов управления ИТ

Для оценки зрелости ИТ-процессов компании используется пятиуровневая модель, основанная на принципах оценки зрелости процессов.

Уровень Название Характеристика
1 Начальный Процессы неформализованы, управление выполняется по необходимости
2 Повторяемый Основные процессы выполняются регулярно, но не полностью документированы
3 Определённый Процессы описаны, утверждены и распределены обязанности
4 Управляемый Используются метрики, контроль качества и регулярная отчётность
5 Оптимизируемый Процессы постоянно анализируются и совершенствуются

С учётом исходного описания компании можно сделать следующую оценку.

Область управления Текущий уровень Обоснование
Управление инцидентами 1 Обращения принимаются по электронной почте и телефону
Управление изменениями 1 Формализованный процесс не описан
Управление активами и данными 2 Используются 1С и Access, но данные разрознены
Управление информационной безопасностью 2 Есть отдельные системы, но комплексная модель защиты не описана
Управление ИТ-проектами 2 Есть ИТ-отдел, однако единая методология не указана
Управление уровнем сервиса 1 SLA и централизованный контроль качества отсутствуют

Средняя оценка:

\[ M=\frac{1+1+2+2+2+1}{6}=1,5 \]

Общий уровень зрелости ИТ-процессов компании — 1,5 из 5.

Это означает, что основные ИТ-функции выполняются, однако управление ими недостаточно формализовано.

Предложения по повышению зрелости:

Направление Мероприятие Целевой уровень
Управление инцидентами Внедрение Service Desk и классификации обращений 3
Управление изменениями Создание регламента согласования изменений 3
Управление данными Централизация баз и организация резервного копирования 3
Информационная безопасность Разработка политики защиты данных и контроль доступа 3
Управление проектами Внедрение единой методологии планирования 3
Управление SLA Введение показателей качества и регулярной отчётности 3

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

2.3.4. План миграции и внедрения на 6 месяцев

Для снижения рисков предлагается поэтапное внедрение гибридной системы.

Проект рассчитан на шесть месяцев.

Этап Длительность Основные действия Ответственные Результат
1. Подготовка Месяц 1 Анализ процессов, техническое задание, выбор подрядчика, аудит данных Руководитель ИТ, аналитик Утверждённое ТЗ и план проекта
2. Развёртывание пилота Месяц 2 Установка тестовой системы, настройка CRM и складского модуля Подрядчик, системный администратор Работающий пилот
3. Интеграция Месяц 3 Настройка обмена с 1С и WordPress, тестирование API Разработчики, подрядчик Работающие интеграции
4. Миграция данных Месяц 4 Очистка Excel и Access, перенос клиентских и складских данных Аналитик, разработчики Проверенные данные в новой системе
5. Обучение Месяц 5 Обучение сотрудников, подготовка инструкций, тестовая эксплуатация Подрядчик, руководители отделов Подготовленные пользователи
6. Запуск в эксплуатацию Месяц 6 Перевод в рабочий режим, контроль SLA, устранение ошибок Руководитель ИТ, подрядчик Полноценная эксплуатация

Диаграмма Ганта

График внедрения системы

Плановая продолжительность этапов в месяцах. Работы частично выполняются параллельно.

Начало

Продолжительность

02468ПодготовкаПилотИнтеграцияМиграцияОбучениеЗапуск

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

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

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

2.4. Управление взаимоотношениями с вендором (VRM)

2.4.1. Стратегия управления взаимоотношениями с поставщиком

VRM (Vendor Relationship Management) — это управление взаимоотношениями с поставщиками ИТ-услуг, направленное на обеспечение качества, соблюдение договорных обязательств и эффективное сотрудничество.

Для компании «ТехноСервис» предлагается организовать постоянное взаимодействие с поставщиком гибридной информационной системы.

1. Регулярные встречи с вендором (QBR).

QBR (Quarterly Business Review) — ежеквартальная встреча заказчика и поставщика для анализа результатов сотрудничества.

Предлагается проводить такие встречи один раз в три месяца.

На встречах рассматриваются:

  • Выполнение условий SLA.
  • Количество зарегистрированных инцидентов.
  • Сроки устранения неисправностей.
  • Результаты выполненных доработок.
  • Соблюдение бюджета.
  • Проблемы интеграции.
  • Планы модернизации системы.

По итогам каждой встречи составляется протокол с перечнем решений, ответственными сотрудниками и сроками выполнения.

2. Мониторинг выполнения SLA.

Контроль выполнения SLA осуществляется постоянно.

Для этого используются:

  • Система мониторинга доступности CRM.
  • Журналы регистрации инцидентов.
  • Система Service Desk.
  • Отчёты о резервном копировании.
  • Отчёты о времени реакции и восстановления.

Руководитель ИТ-отдела ежемесячно формирует отчёт о выполнении SLA и направляет его руководству.

3. Управление изменениями (Change Requests).

Все изменения информационной системы должны регистрироваться в виде запросов на изменение.

Порядок обработки:

  1. Сотрудник или подразделение формирует запрос.
  2. Аналитик описывает требуемое изменение.
  3. Подрядчик оценивает трудозатраты и стоимость.
  4. ИТ-руководитель анализирует технические риски.
  5. Руководство утверждает бюджет при необходимости.
  6. Исполнитель выполняет доработку.
  7. Изменение проходит тестирование.
  8. После приёмки оно переносится в рабочую систему.

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

4. KPI для оценки эффективности вендора.

KPI Целевое значение Период контроля
Доступность системы Не менее 99,5% Ежемесячно
Реакция на P1 Не более 15 минут По каждому инциденту
Восстановление P1 Не более 4 часов По каждому инциденту
Успешность интеграций Не менее 99% операций Ежемесячно
Выполнение плана работ Не менее 95% задач в срок Ежемесячно
Соблюдение бюджета Не более утверждённого бюджета Ежеквартально
Удовлетворённость пользователей Не менее 85% положительных оценок Ежеквартально
Успешность резервного копирования 100% запланированных заданий Ежедневно

5. Организация взаимодействия.

Для каждого направления назначается ответственный:

Направление Ответственный от «ТехноСервиса»
Договор и бюджет Руководитель компании
Технические вопросы Руководитель ИТ-отдела
Интеграции Разработчики
Бизнес-требования Аналитик
Приёмка работ Руководители подразделений
Контроль SLA Руководитель ИТ-отдела

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

2.4.2. Реестр рисков взаимодействия с вендором

Для управления рисками необходимо заранее определить возможные негативные события и разработать меры по их предотвращению.

Оценка производится по пятибалльной шкале:

  • Вероятность: 1 — очень низкая, 5 — очень высокая.
  • Влияние: 1 — незначительное, 5 — критическое.

Для определения приоритета используется формула:

\[ R=P\times I \]

Где:

  • \(P\) — вероятность возникновения;
  • \(I\) — влияние на проект.
Риск Вероятность (1–5) Влияние (1–5) Приоритет Меры минимизации
Vendor lock-in — зависимость от поставщика 4 5 20 Требовать открытые форматы экспорта, документированное API и Exit Plan
Срыв сроков внедрения 3 4 12 Поэтапный график, контрольные точки и ответственность за просрочку
Рост стоимости поддержки 4 4 16 Фиксация тарифов на первый год и согласование индексации
Уход вендора с рынка 2 5 10 Резервное копирование, документация и возможность смены поставщика
Недостаточная квалификация команды вендора 3 4 12 Проверка опыта, собеседование с ключевыми специалистами и референсы
Утечка персональных данных 2 5 10 Контроль доступа, аудит безопасности и договорные обязательства
Нарушение интеграции между системами 3 4 12 Тестовый стенд, мониторинг обмена и механизм повторной передачи
Потеря данных при миграции 2 5 10 Резервные копии и контрольная сверка до и после миграции

Анализ наиболее значимых рисков:

Наиболее высокий приоритет имеет зависимость от поставщика (Vendor lock-in). Если компания не сможет перенести информацию и интеграции к другому исполнителю, переход на новую систему может потребовать значительных затрат.

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

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

2.4.3. План выхода (Exit Plan)

Exit Plan — это заранее разработанный порядок прекращения сотрудничества с поставщиком и перехода на другую информационную систему.

Для компании «ТехноСервис» данный план имеет большое значение, поскольку гибридная архитектура предполагает использование нескольких компонентов и поставщиков.

Основные этапы выхода:

Этап Действие Срок Ответственный
1 Уведомление поставщика о прекращении сотрудничества За 30–60 дней Руководство
2 Формирование полного перечня данных для экспорта 5 рабочих дней Аналитик
3 Экспорт данных CRM и истории обращений До 10 рабочих дней Поставщик
4 Передача документации по интеграциям и настройкам До 10 рабочих дней Поставщик
5 Проверка целостности полученных данных До 5 рабочих дней ИТ-отдел
6 Импорт информации в новую систему До 10 рабочих дней Новая команда внедрения
7 Проверка работоспособности системы До 5 рабочих дней ИТ-отдел
8 Подтверждение удаления данных у старого поставщика После завершения переноса Руководитель ИТ

Что должно быть передано заказчику:

Данные и артефакты Формат
Клиентская база CSV, XLSX или SQL
История сделок CSV, JSON или SQL
История обращений CSV или JSON
Складские данные CSV, XLSX или SQL
Вложения и документы Исходные файлы с сохранением структуры каталогов
Настройки CRM Документированный экспорт или JSON
Описание API OpenAPI или другая техническая документация
Настройки интеграций Техническая документация
Журналы событий CSV или JSON
Резервные копии Согласованный формат СУБД или архив

Дополнительные условия:

  1. Данные должны быть переданы без дополнительной платы, если экспорт предусмотрен договором.
  2. Передача должна осуществляться по защищённому каналу.
  3. После передачи проводится проверка полноты и целостности данных.
  4. Поставщик должен обеспечить переходный период для устранения ошибок переноса.
  5. Удаление данных у прежнего поставщика производится после письменного подтверждения заказчика о завершении миграции и с соблюдением обязательных сроков хранения.
  6. Заказчику передаются все необходимые технические инструкции и сведения, без которых невозможно продолжить эксплуатацию системы.

Вывод: наличие Exit Plan снижает зависимость компании от конкретного поставщика и обеспечивает непрерывность бизнес-процессов при смене программного решения.

2.5. Итоговый отчёт и презентация

2.5.1. Общий вывод по лабораторной работе № 7

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

Для анализа был выбран открытый договор на предоставление SaaS-сервиса. Проведён анализ основных разделов документа, выявлены риски для заказчика и предложены способы улучшения договорных условий.

В качестве наиболее подходящей модели контракта для проекта «ТехноСервис» выбран гибридный контракт, который объединяет фиксированную стоимость основных работ и оплату дополнительных доработок по фактическим затратам.

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

Также рассмотрены этапы жизненного цикла информационной системы и предложено применение практик ITIL для управления инцидентами, проблемами, изменениями и релизами.

Оценка зрелости ИТ-процессов показала, что компания находится на начальном уровне развития. Для повышения эффективности предложено внедрение формализованных процессов управления ИТ-услугами.

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

Итоговый вывод: успешное внедрение информационной системы зависит не только от правильного выбора программного обеспечения, но и от качества договорных отношений, соблюдения SLA и грамотного управления жизненным циклом. Для компании «ТехноСервис» рекомендуется использовать комплексный подход, при котором технические, финансовые и организационные решения рассматриваются совместно.

2.5.2. План презентации для защиты работы № 7

Для защиты предлагается презентация из семи слайдов.

№ слайда Заголовок Содержание
1 Компания и выбранное ИТ-решение Описание «ТехноСервиса», существующие проблемы и выбранная гибридная архитектура
2 Анализ ИТ-контракта Выбранный договор, основные разделы и выявленные красные флаги
3 Разработка SLA Классификация P1–P4, доступность 99,5%, нормативы реакции и восстановления
4 Дерево SLA Связь бизнес-целей, технических показателей и внутренних обязательств
5 Жизненный цикл ИС Основные этапы, применение ITIL и оценка зрелости ИТ-процессов
6 План внедрения Шестимесячный график миграции, тестирования и запуска
7 VRM и итоговые рекомендации KPI поставщика, риски, Exit Plan и основные выводы

Основные тезисы для выступления:

  1. Компания нуждается в модернизации информационной инфраструктуры из-за разрозненности данных и отсутствия единой системы обработки обращений.
  2. Для реализации проекта выбран гибридный вариант, сочетающий локальный складской учёт и облачную CRM.
  3. Для защиты интересов заказчика необходим подробный контракт с фиксированными обязательствами поставщика.
  4. SLA должен гарантировать доступность не менее 99,5% и оперативную реакцию на критичные инциденты.
  5. Управление эксплуатацией предлагается организовать с использованием практик ITIL.
  6. Внедрение планируется завершить за шесть месяцев.
  7. Для снижения зависимости от поставщика необходимо заранее разработать Exit Plan.

Приложения к лабораторным работам

Я подготовил два дополнительных файла, которые можно приложить к отчёту.

Расчёты TCO, ROI и NPV

Excel · 3 листа · Формулы и исходные данные

Скачать Excel

Презентация для защиты работы № 7

PowerPoint · 7 слайдов

Скачать презентацию

Важные замечания перед сдачей

  1. Все финансовые суммы являются учебными экспертными оценками, а не реальными коммерческими предложениями.
  2. В расчётах NPV точные результаты составляют: SaaS — 3,90 млн, On-premise — 0,89 млн, гибрид — 3,93 млн рублей. В Excel используются формулы для автоматического пересчёта.
  3. Выбранная публичная оферта БИК используется как пример для анализа договора, а не как договор на внедрение всей системы «ТехноСервис».
  4. Соблюдение 152-ФЗ нельзя гарантировать одной установкой программного обеспечения: необходимы организационные, юридические и технические мероприятия.

Моя рекомендация: перед сдачей добавь титульный лист с названием вуза, дисциплиной, ФИО студента, ФИО преподавателя и годом выполнения.

Работа охватывает все пункты заданий 1.1–1.5 и 2.1–2.5, а финансовая модель и презентация подготовлены отдельными файлами.