Заказать звонок
Москва, Пресненская набережная, 12
Корзина 0
Войти
PMJournal.ru - управление проектами
Портал для профессионалов в управлении проектами
Услуги
Книги
Онлайн-курсы
Кейсы
Статьи
Новости
Обзоры
Тренинги
Работа
Персоны
Мероприятия
Ещё
    PMJournal.ru - управление проектами
    Услуги
    Книги
    Онлайн-курсы
    Кейсы
    Статьи
    Новости
    Обзоры
    Тренинги
    Работа
    Персоны
    Мероприятия
    Ещё
      0
      PMJournal.ru - управление проектами
      0
      • Услуги
      • Книги
      • Онлайн-курсы
      • Кейсы
      • Статьи
      • Новости
      • Обзоры
      • Тренинги
      • Работа
      • Персоны
      • Мероприятия
      • Личный кабинет
      • Корзина0
      Будьте на связи
      Москва, Пресненская набережная, 12
      info@pmjournal.ru
      • Facebook
      • Вконтакте
      • Twitter
      • Instagram
      • Telegram

      Как ИТ-проекты выглядят со стороны Заказчика?

      • Главная
      • Блог
      • Бизнес статьи
      • Как ИТ-проекты выглядят со стороны Заказчика?
      // Бизнес статьи
      Автор: Александр Кольцов

      Никогда не задумывались, как ваш Заказчик видит ИТ-проекты со своей стороны? Как принимает решения о выборе ИТ-подрядчика?


      Никогда не задумывались, как ваш Заказчик видит ИТ-проекты со своей стороны? Как принимает решения о выборе ИТ-подрядчика? Если вы уже заказчик проекта и собираетесь искать подрядчика через Интернет, бросьте эту затею. В этой статье я расскажу о том, как происходит выбор ИТ-подрядчика, что такое ИТ-проект в структуре крупного бизнеса. Какие ошибки допускают подрядчики, работая с клиентом.

      Как Заказчик ИТ-проекта выбирает подрядчика?

      Поиск подрядчика через вендора

      Я участвовал в проектах по внедрению CRM-системы для московских банков. И должен сказать, что для них железное правило – обращаться к вендорам (вендоры – это владельцы программных продуктов, Microsoft, Oracle, IBM и т.п.) за советом в выборе подрядчика. Ведь речь идет об огромных рисках, которые измеряются сотнями тысяч или миллионами долларов, и на них нельзя не обращать внимания. Поддержка со стороны вендоров – это верный признак того, что компания проверенная. А присутствие, например, представителя Microsoft, на вашей встрече с подрядчиком будет означать, что вы на пути к выбору действительно опытной и надежной компании.

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

      Можно начинать конкурс

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

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

      Сообщить подрядчикам бизнес-проблему иницаиции проекта

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

      Проверить состав команды от ИТ-партнера

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

      Партнер должен говорить в предложении на языке заказчика

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

      Я не люблю, когда коммерческие предложения содержат малопонятные документы, например, «Vision», «Концепция» и пр. Всего однажды на моей практике мы согласились заплатить за такой документ. Помните, что «Концепция» или «Vision» – это документы, которые не несут никакой ценности вашему клиенту.

      Я знаю, что многие методологии рекомендуют создание подобных документов, но совершенно не объясняют, как их продать. Возможно, такой документ необходим подрядчику для того, чтобы лучше понимать, что нужно делать. Но если ему что-то непонятно, он всегда может спросить. Ответы на вопросы и для него, и для вас будут бесплатными. Для тех, кто верит в стандарты Microsoft Solution Framework (MSF) и другие, дам практический совет: в качестве верхнеуровневых документов используйте “Функциональные требования к Системе” и “Календарный график разработки и внедрения”. Эти документы позволяют, не создавая “всяких там концепций”, оценить функциональный объем проекта, перечень итераций или этапов разработки системы. Такие документы несут большую ценность.

      Полная стоимость работ с учетом оборудования и лицензий

      Тщательно проверяйте, чтобы в конкурсной заявке была указана полная стоимость работ по внедрению тех или иных IT-решений. Часто подрядчики включают в стоимость проекта только расходы по внедрению и настройке программного продукта, но забывают, например, прописать стоимость оборудования. Без машин ни один программный продукт работать не будет. Для вас проект – это цельное понятие. И если продукт должен работать на серверах в 400 тысяч евро, то 100 тысяч евро, которые просит подрядчик за консультирование, это лишь капля в море для вас.

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

      Как узнать, что ИТ-подрядчик – надежный?

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

      Демонстрация на данных заказчика

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

      Обучение команды заказчика

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

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

      ИТ-проекты и их структура

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

      Система – первый компонент

      Первый компонент – это собственно система. Сюда я отношу само программное обеспечение, оборудование, лицензии, средства интеграции новой системы с уже имеющимися программными продуктами в компании. В общем, это программная часть (софт) и оборудование (хард). Все технические задания, описание требований, тестирование и пр. относится к этому компоненту. Иногда сюда же я отношу вопросы технической поддержки после завершения проекта и подписание Service Level Agreement (SLA). Зачастую как заказчики, так и подрядчики, видят в объемах работ проекта только этот элемент. Но это – только начало.

      Данные в системе – второй компонент

      Второй компонент – это данные, которые загружаются в систему. Почему-то считается, что программный продукт является самодостаточным, если он соответствует каким-то описанным требованиям. Но программа без данных никому не нужна. И это ваша задача как заказчика своевременно и в полной мере подготовить весь комплекс данных для загрузки в систему. Хорошим примером служит проект по внедрению CRM-решения. Просто «накатить» программный продукт на приобретенные сервера – 30% проекта. Самое «веселье» начинается, когда в справочники начинают поступать данные о клиентах и их контактах, договоры, списки товаров и пр. Данные могут быть некорректной структуры, неполными, храниться в разных форматах и т.п. Привести данные к требуемому виду, сделать очистку, сопоставление (mapping) и пр. – еще та задача, менеджеры-практики это знают. Практически все проекты пробуксовывают на этом компоненте.

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

      Дело в том, что не были учтены еще три важных элемента проекта.

      Управленческие решения на стороне заказчика – третий компонент

      Чтобы система начала работать, недостаточно установить софт и закинуть туда пару справочников. Вся работа должна сопровождаться принятием управленческих решений. Бизнес-процессы компании должны быть готовы к приему нового функционала. Например, для создания call-центра компании необходимо… создать call-центр. Это значит, набрать необходимых людей, создать им рабочие места, определить мотивацию людей, согласовать правила передачи клиентов к продажам через Call-центр. Без соответствующего управленческого решения создание call-центра невозможно и программный продукт не получится внедрить.

      Персонал на стороне заказчика – четвертый компонент

      Еще одним элементом проекта является персонал. Это люди, которых нужно нанять, обучить, аттестовать. А это существенные временные и финансовые затраты, про которые многие забывают. Кстати, ИТ-менеджеры часто не умеют оценивать эти работы. Считается, что обучение – это рассказать о новом функционале сотрудникам заказчика. Но требуется еще обучить людей работать в условиях изменившихся бизнес-процессов. Например, появился отдел, который отвечает за ведение общей базы данных клиентов в CRM. К моменту внедрения программного продукта торговый персонал, который, кстати, не имеет доступа в CRM, должен знать правила взаимодействия с новым подразделением.

      Управление проектами и затраты на это процесс – пятый компонент

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

      С какими проблемами сталкивается заказчик при работе с ИТ-проектами?

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

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

      Бывает, консультанты недооценили объемы работ и хотят больше денег. Можно сказать, что это классическая проблема. И, к сожалению, здесь не найти волшебной палочки. Нужно сделать так, чтобы требования по проекту были детализированы настолько, чтобы отклонение было минимальным. Но зачастую это нереально. Поэтому самый лучший выход – это «разрезать» проект на более мелкие итерации. Мой опыт говорит, что при помощи итераций можно сделать даже сложную систему при условии, что она не является полностью новой разработкой.

      Проблема перерасхода бюджета также актуальна. В этом случае совет один – проработайте бюджет с учетом всех элементов проекта (их пять, помните?). Тогда отклонения будут минимальными.

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

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

      Автор: Александр Кольцов
      Понравилось Понравилось Не понравилось Не понравилось

      Поделиться
      Назад к списку
      • Комментарии
      • Facebook
      • Вконтакте
      Загрузка комментариев...
      Категории
      • Кейсы40
      • Бизнес статьи35
      • Новости13
      • Обзоры38
      • Проект "Бизнес-эволюция"0
      • Тренинги4
      • Работа9
      • Персоны64
      • Мероприятия4
      Это интересно
      • Краткое содержание PMBOK 7
        Краткое содержание PMBOK 7
      • Наш новый проект "FADU.RU - сообщество предпринимателей, бизнес и технологии"
        Наш новый проект "FADU.RU - сообщество предпринимателей, бизнес и технологии"
      • Agile - быть или не быть?
        Agile - быть или не быть?
      • Управление требованиями в Agile. Бизнес-анализ в гибких проектах
        Управление требованиями в Agile. Бизнес-анализ в гибких проектах
      • Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
        Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      • Проектный офис – баланс человеческих ресурсов и программного обеспечения
        Проектный офис – баланс человеческих ресурсов и программного обеспечения
      • Что влияет на эффективность проектных команд
        Что влияет на эффективность проектных команд
      • Синдром отличника
        Синдром отличника
      • Коммуникации в управлении проектами
        Коммуникации в управлении проектами
      • Отчет об исследовании Agile в России 2018
        Отчет об исследовании Agile в России 2018
      • Об эффекте сотой обезьяны
        Об эффекте сотой обезьяны
      • Дюжина ножей в спину PMO
        Дюжина ножей в спину PMO
      • Книга "Как сдать экзамен PMP (Project Management Professional)"
        Книга "Как сдать экзамен PMP (Project Management Professional)"
      • О нулях и единицах в проектных коммуникациях
        О нулях и единицах в проектных коммуникациях
      • Пишите быстро, отвечайте медленно
        Пишите быстро, отвечайте медленно
      • Управление ожиданиями и ожидание управления
        Управление ожиданиями и ожидание управления
      • Книга "Корпоративная система управления проектами"
        Книга "Корпоративная система управления проектами"
      • Проекты по слиянию и поглощению (\M&A)
        Проекты по слиянию и поглощению (\M&A)
      • Эффективное управление хаосом
        Эффективное управление хаосом
      • Страх потери в проектном управлении
        Страх потери в проектном управлении
      Облако тегов
      50 проектов Agile Gartner IPMA jira Kanban M&A MS Project opm3 PDCA PM PMBOK PMBOK7 PMI PMP PRINCE2 Project Manager RUP Scrum waterfall web-разработка ZohoProjects анти КСУП Боль веб-сервис внедрение информационной системы управления проектами внедрение корпоративной системы управления проектами внедрение проектной методололгии жизненный цикл проекта зачем нужно проектное управление информационная система управления проектами ИСУП коммуникации конференция по управлению проектами Корпоративная Система Управления Проектами КСУП Менеджер проекта Менеджмент менеджмент менеджмент проектов веб-сервисы Методология проектного управления Мотивация области управления проектами Обучение управлению проектами Онлайн-обучение онлайн-тренинги по управлению проектами Онлайн-школа освоенный объем погуби проектное управление подборка принимать решения приоритезация провал проекта продакшн Проектный офис проекты процессное управление процессы управления проектами регулярный менеджмент Роман об управлении проектами Руководитель проекта сервисы сертификация по управлению проектами Стандарт управления проектами ГОСТ строительные проекты тайм-менеджмент технология проектного управления типы коммуникаций типы контрактов Тренинги умение договариваться умение спорить Управление бюджетом управление закупками Управление идеями управление инновациями Управление интеграцией Управление качеством Управление коммуникациями Управление персоналом управление поручениями Управление проектами управление проектами Управление проектами в органах государственной власти Управление проектом управление рисками Управление содержанием Управление сроками Управление стейкхолдерами управление хаосом Фейковое проектное управление финансовый анализ ценность проектного управления Цитаты об управлении проектами Цифровая трансформация
      Подпишитесь на нашу рассылку и получайте первыми все самые интересные новости об управлении проектами!
      Онлайн-школа по управлению проектами
      Авторский тренинг «Стань Руководителем проекта, начни зарабатывать больше»
      Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      Услуги по управлению проектами
      Внедрение Корпоративной Системы Управления Проектами (КСУП)
      Книги по управлению проектами
      Книга "Корпоративная система управления проектами"
      Книга "Как сдать экзамен PMP (Project Management Professional)"
      Наши контакты


      Заказать звонок
      info@pmjournal.ru
      Москва, Пресненская набережная, 12
      © 2025 PMJournal.ru - управление проектами. Все права защищены.
      • Вконтакте
      • Facebook
      • Twitter
      • Instagram
      • Telegram
      0