Отношения «заказчик-исполнитель» – это всегда и борьба и, одновременно, единство. И как в любых сложных взаимоотношениях, что-то напрягает больше, что-то меньше. Но ради дела заказчики и исполнители приходят к взаимопониманию. Что для этого может сделать клиент, понятно – проявить лояльность, пересмотреть какие-то соглашения. А что может сделать исполнитель, кроме всем известного ценового демпинга? Есть ли сегодня, например, у ИТ-компаний, другие способы удовлетворить клиента и самим на этом не прогореть? Я считаю, что есть. Главное: заказчику нужно предлагать не «подсказки», а готовые решения ИТ-проблем, причем заблаговременно. И действительно помогать получать лучшие ИТ — за меньшие деньги, но без падения качества обслуживания.
В последние три года сложностей у сервисных компаний, особенно небольших, было достаточно. Это справедливо и для взаимоотношений с клиентами. Причем в ушедшем году мы чаще всего сталкивались с тремя трудностями, о которых и поговорим ниже. Высокая повторяемость ситуации заставила меня задуматься, можно ли превратить эти камни преткновения в поле новых возможностей для бизнеса. Оказалось — вполне. Возможно, эти сложности и решения помогут и другим ИТ-компаниям, и организациям-заказчикам.
Сложность №1. Заказчик сам себе ставит диагноз и выписывает рецепт
Представим, что в средней или крупной торгово-производственной компании идут постоянные сбои в ИТ-инфраструктуре. Причем, одиночные сбои складываются в повторяющиеся цепочки. Производительность ИС падает, важные бизнес-приложения работают медленно и плохо. В центре еще ничего, а вот в регионах… ИТ-директор считает, что все это связано с неважной работой ИТ-инфраструктуры. И решает внедрить систему мониторинга. Чтобы его администраторы не только «тушили пожары», но и могли реагировать на сбои и простои ИТ-сервисов компании проактивно. Он тщательно выбирает вендора, потом системного интегратора, который внедрит ему решение, закупает лицензии, решая, какие модули системы важны, а на каких можно сэкономить. Закупает оборудование под эту непростую в согласовании инициативу. В итоге, ИТ-директор получает свою систему мониторинга. Но выясняется, что она не умеет делать нужных вещей – например, глубоко мониторить состояние Linux-серверов, работу СУБД с открытым кодом (Open Source) или виртуальных машин на том же Open Source. Это или не было предусмотрено в техническом задании. Или не получилось из-за бюджетных ограничений.
Дальше – больше. Добавились новые сервисы (сегодня это происходит постоянно), но свежеиспеченная система мониторинга пропустила их, так как сервисы нужно было добавлять вручную. А системный администратор в этот момент болел. Или задача не была внесена в его должностные обязанности. Но даже если система должна была обнаружить сервисы автоматически, этого тоже могло не случиться. Потому что работа с системой мониторинга вполне могла быть выстроена не как отдельный, ключевой процесс, а по остаточному принципу.
«Маркеров» тут много. Например, неверно выбранные шаблоны, по которым должно идти автоматическое добавление новых объектов (серверов или БД) в систему мониторинга.
Кстати, параметры, которые система мониторинга должна отслеживать и контролировать, тоже сильно меняются со временем – ИС становится все более нагруженной, у нее появляются проблемы с быстродействием. В этом случае всегда нужно проверять выполнение определенных запросов или, например, дополнительные параметры СУБД. Но система об этом так и не узнает… А компания продолжает страдать от того, что ее ключевые бизнес-приложения (например, система коммерческого учета на 1С) работают все медленнее и хуже.
Казалось бы, этих сложностей можно избежать, если правильно настроить сообщения системы мониторинга об ИТ-инцидентах и проблемах. Но чаще всего они настроены лишь базово, т.е. система присылает несчастным ИТ-специалистам до 60% т.н. ложных (falsepositive) срабатываний. На которые инженеры сначала добросовестно реагируют, а потом понимают, что эти сообщения – «пустышки», не требующие внимания, и откликаться перестают. Опасность состоит в том, что со временем сотрудники ИТ-службы перестают ориентироваться в этом потоке сообщений и пропускают критичные (ведущие к дорогостоящим для компании сбоям). Например, сообщения о том, что на жестком диске окончательно закончилось свободное место (а до того у них был поток регулярных сообщений: «Свободного места на диске осталось меньше 15%»). Как в той сказке про мальчика и волков. Более тонкая настройка системы мониторинга могла бы предотвратить эту проблему, но она требует привлечения квалифицированных разработчиков и возможна не всегда. Сама же служба эксплуатации не может точно настроить систему, и она как-то работает. Год – пока вендор оказывает обязательную поддержку. А потом становится инструментом, который используется «стихийно». Пользы от нее в таком режиме немного. То есть, «прописанное лекарство» не помогает. Несмотря на регулярный «прием».
Как этого избежать
Заказчику нужно показать и рассказать, что нужного эффекта, ради которого он собирается тратить немалые деньги, помогает достичь не техническая система, а сервис централизованного мониторинга и контроля. Который сам себя актуализирует. У него тоже есть весьма продвинутый технический «контур», но за этим «контуром» должна скрываться не пустота и не работа внутренней ИТ-службы клиента «по остаточному принципу», а организационно-техническая система. Которая непрерывно генерирует и поддерживает целый «поток» экспертных компетенций, охватывающий все элементы ИТ-инфраструктуры, включая сети передачи данных, виртуализацию, Linux-инфраструктуру и др. При этом команда экспертов должна уметь выдавать компаниям-заказчикам не только подсказки, но и полностью готовые решения: «Через месяц ваша СУБД перестанет справляться – вам нужно уже сейчас нарастить количество таких-то ресурсов для нее на 25%, а таких-то на 11%». Или: «Эти сообщения означают, что нужно исправить ошибки в работе Active Directory». Речь именно о решениях, принятых на основе объективных данных о «здоровье» ИТ. «Вытянутых» из компании, безошибочно проанализированных СЦМК и подтвержденных экспертами.
Сложность №2. Заказчик из ритейла хочет в три раза лучших технологий за в три раза меньшие деньги
Как найти «общий стык» с клиентом
Можно предложить заказчику из ритейла не единый уровень качества ИТ-обслуживания (SLA) по России, а дифференцированный или «умный» (Smart SLA). Когда все торговые точки — в центре и в регионах — делятся на более и менее критичные с точки зрения цены простоев («А» — простои наиболее дороги; «С» — наименее). Соответственно, в точках категории «А» требуется самое быстрое время решение ИТ-проблем (30 минут – 1 час), а в точках «С» приемлемо более долгое (4 часа – на следующий день), но и самое недорогое (в 2 – 2.5 раза дешевле, чем в точках «А»). Во-первых, это полностью оправданно – проходимостью точек, наличием подменного оборудования и характеристиками основного. Во-вторых, это позволяет действительно гибко регулировать бюджет на ИТ-обслуживание. При этом точки не остаются в категориях навсегда, а перемещаются — в зависимости от изменений в самой торговой сети. В магазине категории «А» установили дополнительные кассы или, наконец, предусмотрели резервный интернет-канал? Значит, его можно перенести в категорию «В», где параметры на закрытие ИТ-инцидентов мягче, а затраты клиента ниже. Если с одной кассой или с основным интернет-каналом что-то произойдет, на продажи это не повлияет, а «закрыть» ИТ-инцидент можно будет чуть позже. То есть, ощутимое снижение ИТ-бюджетов происходит при сохранении или росте качества ИТ. Есть и множество других приемов, приносящих эффект без «обязательного» негатива.
Сложность №3. Импортозамещение: ожидание «нового Windows»
Федеральные органы исполнительной власти России (ФОИВы), согласно действующей нормативной базе, должны замещать привычные западные операционные системы, клиентские и офисные приложения, ИТ-инфраструктурные сервисы на российские. И большинство из них ожидают «нового Windows». А российским разработчикам и сервисным компаниям приходится из раза в раз «защищаться» и объяснять, что «здесь будет немного иначе». В этом – одна из главных сложностей нынешнего этапа импортозамещения. И тут может помочь только осознанная смена риторики. Нужно не бояться говорить заказчику правду. Что российские продукты пока набрали значительно меньший суммарный срок коммерческой эксплуатации (особенно если учесть разницу в объеме клиентской базы). И уровень инвестиций в «русский Linux» и другое ПО также заметно ниже – по вполне понятным причинам.
Наконец, сервисным компаниям нужно предупреждать госзаказчика о том, что замещения «один в один» не произойдет. Не нужно ждать, скажем, что замена Active Directory на SambaDC в составе ОС АЛЬТ (разработчик — «Базальт СПО») автоматически принесет те же групповые политики, один в один. Авторизация и аутентификация пользователей будет работать, а групповых политик, таких же, как у MS, не будет. При этом будет неправильным, если заказчик поймет это как: «Мы поняли, этот продукт – хуже!». Вовсе нет, просто MS AD должен замещаться на два продукта: на SambaDC и систему управления инфраструктурой крупного предприятия на базе Puppet или аналогичных продуктов для управления конфигурациями. Это не хуже, просто это другая концепция, опирающаяся на другие продукты. Если этого не объяснить, будут жаловаться пользователи, недоумевать даже многие специалисты. А все снимается разъяснением в начале. И правильно спланированным профессиональным обучением/переобучением системных администраторов и пользователей. И, конечно, профессиональной технической поддержкой комплекса импортонезависимых продуктов из одного окна. Тогда вопросы и необоснованные претензии не появляются вовсе или быстро уходят в прошлое.
Более того, многие организации быстро оценят преимущества применения полнофункциональных продуктов вместо урезанных аналогов, а также интеграции этих продуктов в комплексы, которые обслуживаются как одно целое. И уже с этой точки зрения посмотрят на реальные недостатки «офисной автоматизации», мешающей переходу на настоящие бизнес-приложения и качественному решению задач ИБ. На минусы стихийно сложившихся средств интеграции, которыми невозможно управлять. И на другие последствия «лоскутной информатизации». Импортозамещение дает шанс исправить эти ошибки, что сулит огромные преимущества. Например, в плане радикального повышения темпа изменений информационной системы. Другого такого шанса не будет.
Итого
В основе всех этих решений (СЦМК вместо системы мониторинга, Smart SLA вместо единого SLA по России, грамотного, правильно спланированного и постепенного импортозамещения вместе с разъяснениями различий в замещающих и замещаемых решениях) лежит понимание проблем корпоративных заказчиков – из крупных государственных и муниципальных структур, госкорпораций, коммерческих компаний, торговых сетей. И того, что действительно их беспокоит (тающие бюджеты на ИТ и необходимость работать хорошо, недовольство пользователей «новым миром»). А также стремление дать действительно полезный ответ. То есть такие ИТ-услуги, которые снимают эти боли заказчиков, не всегда явные даже для них самих.
