В настоящее время главный тезис на рынке ИТ-услуг – импортозамещение. Многие производственные процессы как в крупных компаниях, так и на предприятиях МСП обеспечивались иностранным ПО. По ряду обстоятельств поставщики иностранного ПО ушли с российского рынка и отказались от поддержки своих решений. Это коснулось абсолютно всех отраслей. Но не все компании готовы сразу перейти на российское ПО. Например, спрос на разработку ERP- или WMS-систем растет в ретейле и логистике, в машиностроении – на CAD, CAE, CAM, PLM, PDM. На переходном этапе, думаю, вырастет потребность в поддержке западных решений, работающих автономно. В любом случае переход с иностранного ПО на полностью российское потребует крупных вложений и большого количества времени, а значит, потребность в ИТ-услугах будет только расти.
Внешняя или внутренняя ИТ-команда: экономическая целесообразность
Сразу надо сказать, что плюсы и минусы есть в обоих решениях. Плюс разработки своей командой в том, что персонал полностью погружен в процесс, понимает ценность решения и заинтересован в успехе проекта для своей компании. Более того, заказчикам ПО проще контролировать процесс разработки, а конечные пользователи находятся непосредственно рядом с разработчиками.
Среди минусов, во-первых, необходимость содержать полноценный штат профильных ИТ-специалистов с конкурентной зарплатой и высоким уровнем экспертизы (удовольствие не из дешевых). Большой штат специалистов, создаваемый годами, рано или поздно нужно будет оптимизировать, так как объем задач — величина непостоянная. Во-вторых, знания и умения у собственных разработчиков более специализированы, чем у специалистов профильных ИТ-компаний, имеющих портфель проектов с большим спектром технологических компетенций.
При этом, если посчитать суммарные затраты на штатных сотрудников, стоимость привлечения внешних специалистов будет сопоставима или даже меньше, а уровень качества услуг ИТ-подрядчика может быть в несколько раз выше, чем у своей команды. Но возможна и комбинированная схема взаимодействия.
Ошибки, влияющие на сроки проекта при работе с внешней командой, и пути их решения
Я бы выделил несколько основных:
Недостаточность первичных данных и как следствие ошибки при оценке проекта. Прежде всего необходимо декомпозировать проект на задачи для более точной оценки планирования человеческих, финансовых, материальных и временных ресурсов. И при этом все равно следует предусмотреть резервы в деньгах и времени для решения возникающих рисков.
Ошибки по управлению изменениями. Зачастую заказчик просит внести незапланированные изменения в проект. Лечится это на старте путем договоренностей по ограничению количества тех самых изменений между заказчиком и исполнителем.
Проблемы в коммуникациях и ожиданиях как между заказчиком и исполнителем, так и внутри команды проекта. Задача решается внедрением инструментов управления проектами, такими как ALM-система, таймшит и др. Они помогают значительно упростить планирование работы команды, структуру задач и ресурсного плана, ставить задачи и контролировать их своевременное исполнение, согласовывать фактические показатели о рабочем времени и себестоимости проекта, выявлять возможности снижения издержек на ранних этапах и оптимизировать рабочие процессы.
Какие сложности могут возникнуть с поставщиком ИТ-услуг в процессе их оказания? Как управлять возможными рисками?
Определяющими факторами выбора поставщика являются скорость, цена и качество. Именно этим и спекулируют недобросовестные поставщики. Заказчик, имеющий ограниченный бюджет, в большинстве случаев делает выбор в пользу наименьшей цены на рынке и при этом забывает пословицу о бесплатном сыре. По результату выполнения работ заказчик, скорее всего, получит ПО с ограниченным функционалом, без гарантий и перспектив развития или масштабирования. А итогом, скорее всего, станет увеличение бюджета на доработку решения.
Следующая сложность – время: заявленная быстрая реализация как конкурентное преимущество. Как говорилось выше, это либо следствие слабого анализа, либо намеренный обман, чтобы получить заказ.
Ну и, конечно, качество! При выборе поставщика необходимо обращать внимание на его опыт в аналогичных проектах, на уровень компетенций персонала и благодарственные письма. Если поставщик не готов делиться этой информацией, то, скорее всего, это будет говорить о низком качестве разработки.
Факторов, влияющих на работу, множество. Но все-таки если остановиться на оптимальном варианте, то следует выбирать поставщика, в составе услуг которого есть консалтинг и разработка. Консалтинг поможет контролировать процесс разработки. Вероятнее всего, это будет дороже, но на кону бизнес!