company_banner

FAQ про центры решений — как большие компании в России выбирают софт так, чтобы не наступать на грабли

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

    Поскольку понять как что-то сделать на таком уровне очень сложно (всё-таки надо иметь пару лет крайне редкого опыта), а вариантов как правило не один, начинаются проблемы. В итоге может получиться размытое техзадание, которое выставляется на тендер. И тендер выигрывает «за две копейки» кто-то, кто сделает всё, как было в задаче — но при этом совершенно не то, что хотел бизнес. Думаю, как это происходит, объяснять не нужно.

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

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

    Почему нельзя развернуть пилотный проект у заказчика?
    В моей практике был случай, когда заказчик выбирал систему управления ресурсами и проектами в течение 4 месяцев из трёх вариантов. Соответственно, к ним приходили специалисты из одной компании, смотрели, ковыряли, развёртывали. IT-специалисты тыкались, изучали, осваивались и вообще прогоняли почти полную «бету» — потом цикл повторяется для двух других решений. Если у вас столько свободного времени и денег — да, это хороший вариант для ответственного выбора.

    Как делается обычно?
    Обычно заказчик точно знает, что именно хочет решить. И ему достаточно убедиться, что система принципиально это может, никаких грабель в процессе не будет, плюс всё это сделано не через одно место, а может быть и будет «заточено» под его конкретные бизнес-процессы. Соответственно, сначала идёт просто осмотр софтверного решения, потом — более детальное ковыряние по описанным задачам. Через день-два ковыряния и комментариев наших консультантов появляется понимание, как это всё работает и что может делать.

    Как выглядит центр решений?
    Я работаю с HP Solution Center, поэтому дальше буду рассказывать на его примере. Наш центр выглядит как небольшая комната с плазмой, ноутбуками и прочими штуками для презентации. Все это подключено к ЦОДу в этом же здании.



    Полный список решений в HP SC
    Business Service Management:
    • HP Network Node Manager
    • HP Operations Manager
    • HP SiteScope
    • HP Business Process Monitor
    • HP Real User Monitor
    • HP Operations Manager I
    • HP Business Service Manager
    • HP Service Health Reporter
    • HP Service Level Management
    • HP Service Health Analyzer

    IT Financial Management:
    • HP Service Manager
    • HP Asset Manager
    • HP Executive Scorecard

    Business Service Automation:
    • HP Network Automation,
    • HP Client Automation,
    • HP Server Automation,
    • HP Storage Essentials,
    • HP Operation Orchestrator.


    HP Cloud Service Automation I.

    TippingPoint

    ArcSight:
    • HP ArcSight
    • HP ArcSight Logger


    Hardware
    Основывается на технологиях конвергентной инфраструктуры HP: HP BladeSystem, Matrix Operating Environment и Cloud Service Automation for Matrix.


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

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

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

    А как обычно пишется техзадание?
    Первый вариант — гуглится что-то похожее и дописывается «на коленке». Результат предсказуем и плачевен. Вариант лучше — дописывается уже после визита к соседям и долгого общения с их финансовым директором и IT-специалистами. Лучше — теми, кто наступал на грабли. Третий вариант — после центра решений. В случае, если нет предельной конкретики с измеряемыми требования, обычно получается техзадание уровня «сделайте мне хорошо». Что такое «хорошо» каждый понимает по-своему, и в результате исполнитель делает далеко не то, что нужно было заказчику.

    То есть можно заранее понять, насколько, например, новый софт будет удобно сопровождать?
    Да, и это тоже, конечно. Обычно же надо разработать кейсы, поднять решения, интегрировать их между собой, продумать как это всё будет выполняться на уровне архитектуры решения и на уровне кейсов и задач. Подготовить инженеров. А каждая линейка состоит из десятка решений, плюс коробочные интеграции требуют серьёзной доработки напильником. Нужны сложные смежные интеграции между блоками — иначе просто не получится проверить решение самых важных задач. Связки между блоками — отдельная история. Кто-то пробует делать самостоятельно, но софт далеко не самый простой. Нужна очень высокая квалификации специалистов, которые его настраивают. Консолидированное решение, увеличивающее эффект от внедрения — это трудно и сложно, поэтому при самостоятельных попытках часто получается такой странный велосипед на костылях. Пилотные проекты или демо-развёртывание в центре решений снимают большую часть этих проблем.

    Ок, я нашел в списке HP Solution Center решение, которое хочу посмотреть. Что дальше?
    1. Вы пишете о том, что хотите и для какой компании. Если специалисты сейчас не где-нибудь во Владивостоке на боевом внедрении, мы договариваемся о встрече.
    2. На встрече вы получаете финансовые данные и информацию о функционале для оценки решения. На месте всё показывается на практическом кейсе (на тестовой базе).
    3. Если нужно — ваш IT-специалист ковыряется в этом кейсе и вообще инфраструктуре центра решений хоть сутки.
    4. Дальше вы точнее понимаете, подходит или нет и присылаете кучу вопросов и более детальные требования.
    5. В ряде случаев для задач, которые нельзя оценить на типовых тестовых базах, поднимается пилотное решение.

    Кто обычно приходит в центр решений?
    По моей практике — топы и IT-специалисты. Руководству интересен взгляд с точки зрения бизнес-ценностей, они приносят примеры кейсов и спрашивают, как это решается. Мы демонстируем. Потом IT-специалисты остаются и играют с тестовой системой как русские мужики с новой бензопилой. Потом все уходят думать, и через примерно неделю появляются уже те, кто будет непосредственно обслуживать решение в будущем — и задают вопросы, оценивают. Они дают оценку своим руководителям, доуточняют рад моментов. Принимается решение о внедрении.

    Кому ещё нужен центр решений?
    • Тем, кто хочет посмотреть на новые версии ПО или смежные модули в работе. Как правило, это 80% обращений от уже имеющихся заказчиков: их специалистам нужно быстро и просто оценить, насколько востребованы новые релизы.
    • Оценка новинок: когда софт только вышел, и толком про него ничего не понятно, а задачи он решает актуальные, надо идти и смотреть. Это не самый частый случай, но центр решений становится просто незаменим.
    • Когда нужно проверить решения класса Big Data, например, а тестовой площадки просто нет. Можно посмотреть и оценить на крупных массивах данных.


    Что ещё очень важно?
    Поскольку у нас моделируется инфраструктура компании, получается полный охват по софту. То есть мы не показываем кусочки типа «а вот если бы на входе у нас было вот это» с рядом допущений, а реально моделируем развёрнутый комплекс ПО. То есть данные из управления финансами сразу отображаются, например, в остальных модулях.

    По охвату и комплексности центра HP решений – это самый большой в России. К тому же был создан совместно с вендором. Не каждый интегратор может позволить себе несколько стоек в ЦОДе под такие задачи, плюс надо ещё собрать команду, которая досконально знает и софт, и как его используют на практике компании в нашей стране. Ну и плюс лицензии-сертификаты и всё остальное.

    По каким вопросам чаще всего обращаются в центр решений?


    ИТ-планирование
    • Управление ИТ-процессами
    • Управление активами в ИТ
    • Инструменты стратегического планирования в ИТ

    Поддержка:
    • Мониторинг АО серверов, ИХД и сетевой инфраструктуры
    • Мониторинг ОС и инфраструктурных сервисов
    • Мониторинг производительности бизнес-приложений
    • Централизованный портал мониторинга ИТ-инфраструктуры и «здоровья» приложений
    • Автоматизация задач управления конфигурациями серверов
    • Автоматизация задач управления конфигурациями сетевых устройств
    • Автоматизация задач управления ресурсами СХД
    • Автоматизация регламентных процессов диагностики
    • Автоматизация комплексных рабочих процессов управления

    Разработка:
    • Портал самообслуживания сервисов класса IaaS, PaaS и SaaS
    • Создание и публикация ИТ-сервисов
    • Управление процессом разворачивания ИТ-сервисов
    • Расчет стоимости потребления ИТ-сервисов

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

    Я как раз искал что-то подобное, кому писать?


    Я руковожу центром решений HP и командой инженеров по решениям HP. Если интересно посмотреть конкретный софт или решения, пишите на VFeldchun@croc.ru. А, вообще, это HP SC – не единственный центр решений КРОК, поэтому если что, можно спрашивать и по другим направлениям, я дам контакты соответствующего коллеги.
    • +18
    • 12,2k
    • 3
    КРОК
    91,75
    IT-компания
    Поделиться публикацией

    Комментарии 3

      +2
      Как делается обычно?
      Обычно заказчик точно знает, что именно хочет решить. И ему достаточно убедиться, что система принципиально это может, никаких грабель в процессе не будет, плюс всё это сделано не через одно место, а может быть и будет «заточено» под его конкретные бизнес-процессы. Соответственно, сначала идёт просто осмотр софтверного решения, потом — более детальное ковыряние по описанным задачам. Через день-два ковыряния и комментариев наших консультантов появляется понимание, как это всё работает и что может делать.


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

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

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

          Вот представьте себя компанией с 2-3 тысячами офисов. Вы бы решились накатить даже просто новую версию, не протестировав её где-то? А здесь речь об интеграции принципиально нового решения.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое