В этом материале я хочу поделиться опытом, как выбрать ITSM/ESM систему и что, на мой взгляд, нужно учесть. За 10+ лет внедрений я видел, как компании выбирают решения и мне есть, что сказать по этому поводу.
Начнем. Знакомая история? ИТ-директор говорит: «Нам нужна ITSM-система, чтобы заявки обрабатывались быстрее». Через год — система есть, а заявки всё так же висят неделями. Или проект стартует с бюджетом 3 миллиона на автоматизацию Service Desk, а финиширует на 8 миллионах с интеграциями, о которых никто не подумал заранее.
Меня зовут Евгений Котухов, я эксперт по внедрению и оптимизации ITSM/ITAM решений, официальный технологический партнер SimpleOne с 10-летней экспертизой в автоматизации ИТ-процессов. Реализовал десятки ESM-проектов для компаний госсектора, энергетики, торговли и финансов. Специализируюсь на быстрых внедрениях полного цикла с запуском от 2 месяцев — от аудита процессов до рабочего решения, включая сложные интеграции с корпоративными системами. Обладаю опытом руководства командой, внедрения новых методологий и повышения качества IT-услуг через оптимизацию процессов и ITSM-систем
Чтобы выбрать ITSM/ESM-систему, мы с вами обсудим, зачем они вообще нужны, и как не прогадать с выбором. Важно: я искренне считаю, что нет плохих систем или неправильных подходов к выбору системы — каждый бизнес уникален, даже если с первого взгляда кажется, что нет. Поэтому одно из главных правил — нет неправильных подходов и плохих систем, есть непонимание, что же нам нужно.
Ах да, чуть не забыл: речь будет идти всё-таки про энтерпрайз. Не так важна сфера деятельности, как масштаб — все-таки малым предприятиям на 10 человек ITSM не нужен, за редким исключением. Но все-таки держите в голове такой себе крупный энтерпрайз.
Что такое ITSM/ESM-система и зачем нужна бизнесу?
Прежде чем погружаться в методику выбора, давайте рассмотрим, что такое вообще этот ITSM/ESM, Service Desk. Для тех, кто не знаком с понятиями, тех кто только находится в начале пути хотелось бы немного объяснить о чем вообще идет речь.
Как по мне, ITSM — это подход, или философия, если угодно, которая говорит, что надо бы управлять ИТ как услугами, а значит понимать своего клиента, понимать, что ему нужно, и доставлять ему ценность. Суть подхода кроется в мысли, что мы не просто устанавливаем программное обеспечение или сбрасываем пароль, а делаем это для того, чтобы бизнес мог зарабатывать. ИТ становится партнером для бизнеса и четко понимает его потребности, понимает, как работа отдела влияет на бизнес-процессы.
ServiceDesk – многозначный термин: это и класс систем, и группа поддержки, и точка коммуникации между ИТ и бизнесом. В контексте систем ServiceDesk – это платформа для автоматизации обработки обращений пользователей, которая сокращает время решения инцидентов, запросов и повышает качество ИТ-поддержки.
Со временем стали появляться всевозможные фреймворки, библиотеки, методологии и прочие страшные слова, которые взяли за основу эту мысль и обогатили это процессами практикам. Так появился ITIL, процессы управления инцидентами, управления запросами на обслуживание, событиями, конфигурационными единицами и всем остальным, что сейчас нам позволяет оказывать классный сервис.
При этом на ITSM дело не закончилось — бизнес стал расширять принципы управления ИТ-услугами на другие отделы. Такие подразделения, как HR, бухгалтерия и даже маркетинг становятся поставщиками услуг, как ИТ-отдел. Это и называется ESM — Enterprise Service Management.
Тут и подоспевают вендора с их ITSM/ESM-системами, разной ценовой политикой, культурой взаимодействия, и функциональными решениями, которые так или иначе основаны на ITIL как на лучших практиках. Из большого количества вендоров нужно же выбрать одного, а как? Ответ ниже.
Пошаговый алгоритм выбора ITSM/ESM-системы
Начнем с того, почему вам вообще нужно выбрать новую ITSM/ESM систему. Например, пришел новый ИТ-директор и решил, что надо заменять. Или кому-то из топов не нравится дизайн, хотят импортозамещения, текущая система не удовлетворяет в плане функциональности. Каждая причина имеет право на существование, да и в целом она не так сильно важна, но является отправной точкой.
В целом все, о чем пойдет речь, применимо и к другим классам систем, но у решений класса ESM (Enterprise Service Management, управление корпоративными услугами) есть важное отличие — это не только система, но и целая методология/культура работы. Поэтому самый первый и важный шаг, который нужно сделать, это…
Прежде чем перейти к шагу 1, стоит честно ответить на несколько вопросов:
Как мы сейчас работаем? Каких клиентов — внутренних или внешних — мы обслуживаем? Что для нас значит «хороший сервис»? Как мы принимаем решения? Какой уровень прозрачности и ответственности для нас естественен? Что у нас получается хорошо, а где системно болит?
Когда вы поймете собственный стиль работы, реальные потребности и ожидания людей, станет ясно, что выбирать систему вслепую невозможно. Не бывает «плохих» или «правильных» платформ — бывает несоответствие между культурой организации, её зрелостью, реальными задачами… и тем, как устроена выбранная система.
И вот поэтому самый первый шаг (шаг 0) — не смотреть на рынок, а смотреть на себя. Уже от этого зависит всё остальное. Если вы понимаете свои потребности и клиентские сценарии, систему вы подберёте безошибочно. Если не понимаете — никакая система не спасёт.
Шаг 1: понять цель внедрения новой ITSM/ESM системы
Вы хотите просто учитывать заявки и повысить общую производительность — это хорошая цель, понятная и рабочая. Или высшее руководство решило, что нужно меняться всей организацией и трансформировать все процессы с целью перехода на ESM-подход — это уже другой сценарий.
В любом случае, от цели зависят ваши ожидания. Правильная и четко сформулированная цель позволит вам выбрать лучшее решение.
Тут на помощь приходят проверенные методики постановки целей. Можно использовать такие подходы, как:
SMART цели
OKR (Objectives and Key Results)
Метод «от противного»
Шаг 2: выявить проблемы и сформулировать требования
После того, как вы определились с целью, нужно понять, какие проблемы вы хотите решить. Я искренне считаю, что лучше всего идти именно от проблем. Не «Мы хотим учитывать все критичные инциденты», а «Мы не понимаем, когда и почему у нас случаются критичные инциденты». Это упражнение лучше всего сделать в первую очередь для самих себя, а уже потом превратить это в критерий выбора, например, в такой: «Система должна учитывать все критичные инциденты и хранить историю по ним».
Так нужно выделить 10, 100, 1000 проблем и желаний, превратив их в конкретные требования с приоритетом. Для выявления проблем можно использовать что угодно:
Классический мозговой штурм
Обратный мозговой штурм
Метод «5 Почему»
Карта пути пользователя
Интервью со стейкхолдерами
Анализ текущих метрик
Метод SWOT для текущей ситуации
По моему опыту, при выборе ITSM/ESM-решения есть критерии, которые являются мастхев и на которые точно стоит обратить внимание.
Начнем с функциональных критериев — это про то, сможет ли система реально закрыть ваши задачи, а не просто красиво выглядеть в презентации вендора.
Функциональные критерии
Критерий |
Описание |
Примечание |
Поддержка ITIL-процессов из коробки |
Количество готовых процессов (Incident, Problem, Change, Service Request и т.д.) |
Важно: если вы стратегически смотрите на сервисный подход и планируете развивать его за рамки ИТ, стоит обратить внимание, что ключевые ITIL-процессы, например, управление услугами и конфигурациями услуг (CMDB), должны быть на уровне платформы |
Обеспечивает возможность глубокой кастомизации портала самообслуживания |
Настройка интерфейса, форм, виджетов под корпоративный стиль и бизнес-логику |
Чем больше возможностей кастомизации портала тем лучше. Есть системы, у которых порталы не кастомизируются, или для этого нужно докупать специальные лицензии |
Обеспечивает хранение данных об активах в одной базе данных управления конфигурациями (CMDB) |
Централизованное хранилище информации об ИТ-инфраструктуре и связях между КЕ |
CMDB в целом один из ключевых процессов. Услуга является конфигурационной единицей, обращения должны быть связаны с услугами и т.д. поэтому обращайте внимание на наличие CMDB |
Обеспечивает наличие инструментов для анализа данных и генерации отчетов |
Встроенные конструкторы отчетов, дашборды, экспорт данных |
Всегда удобно строить отчеты самостоятельно без привлечения разработчиков, без интеграции с DWH и BI. Например, у вендора на уровне платформы могут быть специальные инструменты для контроля и анализа метрик, такие как сбалансированные карты показателей. |
Обеспечивает наличие Low-code инструментов |
Возможность создавать формы, процессы, бизнес-правила без программирования. Даже если у вас много ITSM-процессов, то наличие Low-code позволяет легко кастомить существующие и добавлять новые |
Low-code решает 80% задач за часы, а не недели разработки |
Нет зависимости от вендора |
Возможность самостоятельно кастомизировать решения созданные на платформе, не только с помощью Low-code, но и с Pro-code , например, используя Javascript |
Крупному бизнесу нужны специфические процессы, которых часто нет в коробочных решениях для автоматизации. Когда на платформе есть Pro-code, компания может самостоятельно внести нужные изменения, а не ждать вендора или интегратора |
Гибкость в настройке моделей стандартизированных запросов без программирования |
Наличие инструмента (например, возможность быстрого добавления атрибутов/полей без изменения базы данных) для быстрого создания и изменения анкет-форм для разных услуг с различными полями и логикой. |
Позволяет бизнес-пользователям самостоятельно адаптировать и расширять каталог услуг, не перегружая систему и не привлекая разработчиков для каждой новой формы (будь-то ИТ-услуга, HR или любая другая), а также определять порядок обработки запросов, в том числе автоматизируя его |
Обеспечивает двухстороннюю интеграцию по API с сторонними системами |
Наличие REST/SOAP API для обмена данными с внешними системами, а также организации информационного обмена в рамках брокеров сообщений (AMQP) |
Без API вы застрянете в ручной работе при интеграции с AD, почтой, мониторингами и другими системами |
Обеспечивает управление версиями и сборкой |
Контроль изменений конфигурации системы, откат к предыдущим версиям |
Выбирайте системы, которые имеют встроенную систему контроля версий и возможность произведения откатов функционала |
Продолжаем — следующая категория финансовые критерии. Здесь важно смотреть не только на ценник лицензий, но и на то, во что реально выльется владение системой через год-два.
Финансовые критерии
Критерий |
Описание |
Примечание |
Стоимость лицензий |
Базовая стоимость лицензий на пользователей и компоненты системы |
Смотрите на финальную цифру после всех "опциональных" модулей — она может вырасти в 3-5 раз |
Как лицензируется портал? |
Модель лицензирования портала самообслуживания (по пользователям, по обращениям, безлимит) |
Есть системы у которых разные лицензии для портала. Всегда уточняйте этот вопрос |
Обеспечивает понятную политику лицензирования |
Прозрачность модели: нет ли скрытых лицензий на отдельные модули, серверные компоненты, интеграции |
Честно говоря, это боль — есть вендоры, у которых спецификация это десятки строк, и с ними сложно работать как подрядчику, так и заказчику. Лучше выбирать тех, у кого все прозрачно и понятно 1 лицензия на всю систему без ограничений |
TCO (Total Cost of Ownership) |
Полная стоимость владения: лицензии + поддержка + обновления + инфраструктура + доработки |
Помним, что реальная стоимость за 3 года может быть в 2-3 раза выше первоначального бюджета на покупку |
Заканчиваем нефункциональными критериями — это про экосистему вокруг продукта, партнерскую сеть, прозрачность вендора, а также опыт конечных пользователей (агентов, сотрудников и клиентов). На практике именно эти факторы определяют, насколько комфортно вам будет работать с платформой после внедрения.
Не функциональные критерии
Критерий |
Описание |
Примечание |
Производительность решения |
Платформа поддерживает высокие нагрузки и большие объемы данных. Система масштабируется под потребности enterprise: добавляются вычислительные ресурсы при росте нагрузки на отдельные компоненты |
Быстродействие сохраняется при одновременной работе большого количества пользователей |
Современный UX/UI |
Современный адаптивный интерфейс работает на любых устройствах — компьютерах, планшетах, смартфонах. Инструменты настройки интерфейса сокращают количество кликов для выполнения операций: то, что раньше требовало 10 действий, теперь выполняется за 2-3 клика |
Платформа предоставляет готовые инструменты для оптимизации пользовательских сценариев: чек-листы, быстрые ответы, омниканальную поддержку через мессенджеры |
Является ли система платформой? |
Возможность использовать решение не только для ITSM, но и для автоматизации других процессов (HR, Finance, Legal и т.д.) |
Это должна быть именно платформа, а не просто система с ограниченным функционалом |
Прозрачность взаимодействия |
Отсутствие конфликта интересов (например, когда вендор сам играет роль интегратора) |
Если вендор монополизирует интеграцию — будьте готовы к завышенным ценам и отсутствию альтернатив |
Обучение |
Активные программы обучения партнёров, сертификация, совместные активности |
Без нормального обучения ваша команда будет учиться методом проб и ошибок на проде |
Наличие маркетплейса |
Централизованная площадка для загрузки готовых решений и интеграций от вендора и партнеров |
Маркетплейс экономит месяцы разработки — берете готовое решение и адаптируете под себя. Я лично активно размещаю свои доработки на маркетплейсе |
Количество приложений, дополнений у вендора |
Объем экосистемы готовых модулей и расширений |
От 15+ приложений — это показатель зрелости платформы и активного комьюнити |
Наличие открытой дорожной карты, на который можно повлиять |
Публичная дорожная карта развития продукта с возможностью голосования за фичи |
Закрытая дорожная карта — это лотерея: угадаете ли вы, что разработает вендор в следующем году |
Количество интеграционных партнеров |
Число сертифицированных партнеров-интеграторов на рынке |
Один-два партнера — это фактически монополия, минимум 10 для здоровой конкуренции |
Шаг 3: оценить риски
Тут начинается самое интересное, потому что выбор и внедрение ITSM/ESM системы – это всегда риски, особенно финансовые. И лучше думать о них заранее, чем потом удивляться, почему не получилось. Давайте честно посмотрим, что может пойти не так.
1. Организационные риски
Сопротивление изменениям — это главный киллер любого проекта внедрения. Сотрудники привыкли работать по-старому, и «зачем нам эта новая система?» уже не просто вопрос, а диагноз.
Как снизить сопротивление: вовлекайте пользователей с самого начала, пусть они участвуют в выборе решения; назначьте амбассадоров изменений в каждом отделе.
Еще один риск — отсутствие поддержки руководства. Если топы просто разрешили купить систему, но сами не участвуют, проект обречен.
Что делать: найдите официального спонсора проекта на уровне C-level; покажите, как проект связан со стратегией компании.
2. Технические риски
Интеграции — это боль и страдание. Ваша новая ITSM/ESM-система должна подружиться с Active Directory, почтой, 1С, системой мониторинга, базой знаний, телефонией и еще 15 системами.
Чтобы снизить риски, на этапе выбора системы требуйте proof of concept для критичных интеграций. Проверяйте референсы вендора именно по интеграциям и закладывайте время на их реализацию.
Миграция данных – еще один вызов для компании. Данные из старой системы нужно перенести, и они обычно в странном формате, с ошибками и дублями, неполные, с кривыми связями
Что делать: провести аудит данных еще до выбора системы, сделать 2-3 тестовых миграции перед реальной, запланировать параллельную работу систем хотя бы на 2-4 недели.
3. Финансовые риски
Бюджет всегда раздувается, это закон природы. Изначальная оценка «5 млн на лицензии» превращается в «8 млн на лицензии + 3 млн на консалтинг + 2 млн на интеграции + еще нужны сервера». Подробнее о скрытых расходах поговорим в шаге 6.
Как управлять финансовыми рисками: запрашивайте total cost of ownership (TCO) на 3-5 лет, разбейте проект на фазы с контролем бюджета на каждой, изучите модель лицензирования.
4. Риски поставщика (вендора)
Вендоры могут обещать многое, но реальность внедрения часто отличается от красивых презентаций. Систему внедрили, а техподдержка отвечает через неделю, документация только на английском, а сообщество пользователей — три человека в телеграме.
Как управлять рисками выбора вендора: запрашивайте полную экосистему поддержки — работает ли центр обучения с реальными кейсами, есть ли активное сообщество практиков, сколько времени занимает решение технических вопросов. Проверьте возможность влиять на развитие платформы через обратную связь пользователей. Изучите, как вендор взаимодействует с клиентами после внедрения — предоставляет ли методологическую поддержку, помогает ли в оптимизации процессов, обучает ли команду лучшим практикам
5. Риски принятия системы пользователями
Систему внедрили, а никто не пользуется. Продолжают слать письма и звонить по старинке. Чтобы этого не случилось, примите превентивные меры:
UX/UI должен быть простым и понятным, проверяйте его на этапе выбора
Первые 3 месяца пользователям нужна активная поддержка и обучение
Следите за adoption rate: сколько % пользователей реально работают в системе
Помните, что рисков не нужно бояться, к ним нужно готовиться. Лучший проект — это проект, где вы знаете все риски и имеете план для каждого из них.
Шаг 4: оценить вендоров и их культуру
Ок, вы понимаете цели, проблемы собраны, риски на контроле. Самое время разобраться с вендорами. И тут важно понять одну простую вещь: вы выбираете не просто систему А или систему Б, вы выбираете партнера на ближайшие 3-5-7 лет. С этой компанией вам работать, общаться, взаимодействовать каждый раз, когда что-то пойдет не так, когда нужна будет помощь или когда захотите внедрить что-то новое.
На рынке есть два основных типа вендоров:
Тип 1: Вендор + Интегратор в одном лице
Это когда компания и систему разрабатывает, и сама же её внедряет, изредка привлекая партнеров. Казалось бы, удобно – один контракт, одни контакты, все под контролем. Но честно? Мне такой подход не очень нравится, и вот почему:
Нет разделения ответственности: если что-то пошло не так, кто виноват? Система кривая или внедрение плохое? Вендор начинает защищать свой продукт, а вы остаетесь со своими проблемами. Иногда вендор считает, что знает лучше вас и подминает вас под систему, а не систему под вас.
Конфликт интересов: вендор заинтересован продать максимум своего продукта и часов консалтинга, а не решить вашу проблему.
Отсутствие конкуренции: партнеры конкурируют за качество внедрения, а монополист-вендор просто берет деньги.
Тип 2: Вендор продукта + Экосистема партнеров
Вендор делает качественный продукт, развивает его, а внедрением занимаются независимые партнеры-интеграторы. Тут плюсы очевидны:
Вендор сосредоточен на продукте, а не отвлекается на внедрения
Вы выбираете интегратора по компетенции, цене и адекватности
Конкуренция между партнерами работает на вас
Если партнер не устроил – меняете его, а не систему
Как оценить культуру вендора
И пара слов о культуре. Я общаюсь с вендорами как потенциальный партнер. Расскажу историю с реального проекта одного из вендоров (как раз первого типа), у которого система, к слову, классная, хорошая, функциональная. Но подход... оставляет желать лучшего. Возникла ситуация: в одном из полей системы было написано «Аброщения». Обычная опечатка, да? Я спрашиваю: ребят, можно это поправить? Ответ: «Нет, делай так, как написано в ТЗ! Мы это зафиксируем как доработку, подпишем дополнительное соглашение, проведем ПМИ, это будет стоить столько-то».
Вот это и есть культура вендора. Я четко вижу такие вещи, потому что общался с вендорами не только как заказчик, но и как партнер, и эти красные флаги очень хорошо видны. И знаете что? С такой культурой вам жить годами. Каждый раз, когда нужно будет что-то изменить или исправить, вас будут разводить на дополнительные соглашения и часы работы.
Не выбирайте только по функциональности и цене. Плохой вендор превратит даже хорошую систему в кошмар, а хороший вендор компенсирует некоторые недостатки продукта своим сервисом и готовностью помогать. Чтобы не ошибиться с выбором, задайте вендору жесткие вопросы. Поспрашивайте рынок. Пообщайтесь с реальными клиентами. И помните: если вам уже на этапе выбора что-то не нравится в подходе вендора, после покупки станет только хуже.
Шаг 5: найти и выбрать интегратора (поставщика)
Окей, с вендором разобрались, теперь про тех, кто будет систему внедрять. Первым делом запросите референсы и проверьте их. Не просто список «мы внедряли у X, Y, Z», а реальные контакты людей, с которыми можно поговорить. И обязательно звоните! Вот о чем спрашивать:
Сроки: обещали 6 месяцев, сделали за сколько реально?
Бюджет: уложились в оценку или раздули в 2 раза?
Кома��да: приходили одни и те же люди или постоянная ротация?
Качество: что пришлось переделывать после них?
Конфликты: были ли спорные моменты и как их решали?
Поддержка: помогли ли после внедрения или пропали?
Узнайте, сколько проектов внедрили именно на этой платформе, есть ли кейсы в вашей индустрии или похожего масштаба, кто в команде: джуны или люди с опытом?
Страшная правда про интеграторов
Поставщики все +/- одинаковые. Экспертиза у всех нормальная. Именно поэтому лучше всего выбирать не по известному имени (BigName Consulting за 25 миллионов), а по:
Адекватности людей
Реальной цене без накруток за бренд
Опыту именно в вашей системе
Референсным проектам
Или можете сделать еще проще — обратиться ко мне, и мы с вами посчитаем ваш проект. Я либо сделаю его сам, либо приведу вас к адекватному партнеру, с которым я работаю и за которого могу поручиться.
Шаг 6: посчитать TCO и принять финальное решение
Почти финишируем! Осталось посчитать реальную стоимость владения и принять решение.
Выше мы уже говорили о том, что Total Cost of Ownership (TCO) — это не только лицензии. Расскажу подробнее, что входит в TCO на 3-5 лет:
1. Лицензии и подписки
Начальная стоимость лицензий (perpetual vs subscription?)
Ежегодное продление поддержки (обычно 15-25% от стоимости лицензий)
Рост числа пользователей: планируете расширяться?
Дополнительные модули, которые понадобятся со временем
2. Внедрение и интеграции
Работа интегратора (человеко-дни × ставка)
Интеграции со сторонними системами (каждая = минимум 2-4 недели работы)
Миграция данных из старой системы
Кастомизация под ваши процессы
3. Инфраструктура
Сервера (покупка или аренда облака)
Лицензии на ОС (Windows Server, RHEL)
СУБД (Oracle, MS SQL – это отдельные деньги!)
Резервное копирование, мониторинг
Сетевое оборудование, балансировщики
4. Команда и поддержка
Администратор системы (1-2 FTE)
Разработчик/конфигуратор для доработок (0.5-1 FTE)
Поддержка пользователей (1-2 линия, сколько человек?)
Обучение новых сотрудников
5. Развитие
Новые процессы и модули
Обновления системы
Изменения в интеграциях (системы меняются, интеграции ломаются)
Аудиты и оптимизация
6. Скрытые расходы
Время простоя при миграции/обновлениях
Обучение пользователей (не только начальное, но и периодическое)
Потеря производительности в первые месяцы (люди привыкают)
Необходимость держать параллельно старую систему какое-то время
Важно понимать, что небольшим компаниям возможно подойдут простые коробочные решения, с проработанными ITSM-процессами, но для крупных компаний сервисный подход уже давно не просто про ИТ. Поэтому внедрение именно ESM-платформ, а не просто ITSM-решений, позволяет окупить проект чуть ли не в 5 раз быстрее по сравнению с автоматизацией только ИТ-услуг.
Технологический стек имеет значение
Важный момент для оценки TCO: на чем написана система? Это влияет на доступность специалистов на рынке:
JavaScript/Node.js — специалистов полно, не проблема найти и не очень дорого
.NET/C#, java — тоже нормально, но уже подороже
PHP — специалистов много, но часто надо искать качество
Редкие технологии (например, некоторые проприетарные решения) – держать у себя редких специалистов дорого, на рынке их мало
СУБД тоже критична:
PostgreSQL, MySQL — бесплатные, открытые, специалистов много
MS SQL Server — лицензии платные, но специалистов хватает
Oracle — очень дорогие лицензии + дорогие специалисты (зато мощно и надежно)
Принятие финального решения
У вас на столе 2-3-4 варианта. Как выбрать? Используйте финальный чек-лист решения:
Посчитали TCO на 3-5 лет для каждого варианта
Провели PoC для финалистов (1-2 системы)
Оценили все варианты по всем критериям с весами
Проверили технологический стек и доступность специалистов
Получили buy-in от всех ключевых стейкхолдеров
Перечитали контракт с юристом
Убедились в наличии бюджета и команды
Готовы приступить к внедрению
Что дальше?
Поздравляю, вы прошли весь путь от постановки целей до принятия решения! Это только первая часть приключения. Дальше начнется самое интересное — внедрение. Но это уже совсем другая история.
Если вы сделали эти шаги качественно, вы знаете:
Куда идете (цели)
Что ищете (требования)
Какие подводные камни вас ждут (риски)
С кем работать (вендор и интегратор)
Во сколько это обойдется (TCO)
А это уже 80% успеха.
Удачи в выборе системы! И помните: нет идеальных систем, есть система, которая подходит именно вам, с вендором, с которым можно работать, и командой, готовой это внедрить.
***
Также, скоро будет опубликован большой обзор рынка ITSM/ESM систем России, поэтому подписывайтесь, буду рад поделиться своим видением.
Остались вопросы? Нужна помощь в выборе или расчете проекта? Пишите, разберемся вместе.