Корпоративные информационные системы (ИС) играют ключевую роль в управлении и оптимизации бизнес-процессов современных организаций. Как и любые другие технические активы – а как я уже утверждал ИС это вполне себе технический актив – эти системы проходят определённые этапы жизненного цикла, начиная от планирования и заканчивая утилизацией. Пока не очень понятно при чем тут технический аудит при закупках ИТ-систем, но скоро я всё объясню.
Понимание жизненного цикла КС помогает разрабатывать стратегии для их эффективного управления и поддержки, основные этапы тут такие:
- Планирование и анализ требований: Этот этап включает в себя определение целей и задач, которые должна выполнять система. Анализируются бизнес-процессы, собираются и уточняются требования от всех заинтересованных сторон.
- Проектирование: На этом этапе создается архитектура системы, разрабатываются технические спецификации и планируется структура данных. Концептуальная модель превращается в детальный проект, готовый к реализации.
- Разработка и тестирование: После утверждения проектной документации наступает этап кодирования и интеграции различных компонентов системы. Тестирование проверяет работоспособность и безопасность созданного решения, выявляет ошибки и недочеты.
- Внедрение: Выполняется установка ПО на рабочих местах пользователей и обучение персонала. На этом этапе критически важны подготовка и поддержка пользователей для обеспечения безболезненного перехода.
- Эксплуатация и поддержка: Система вступает в фазу рутинного использования, предусматривающую регулярное обновление, обслуживание и поддержку пользователей.
- Изменение или утилизация: Когда система устаревает или больше не удовлетворяет бизнес-требованиям, она либо модифицируется, либо заменяется новой системой.
Вполне себе классический водопад. Agile не про то, чтобы это всё сломать, он про ту рационализацию, чтобы одну итерацию длиной в целый проект разбить на кучу мелких и получать результат по итогу каждой из итераций. Но сейчас не об этом.
Закупка корпоративных ИС через тендерные процедуры
В больших корпоратах и госухе далеко не всегда пилят чего-то сами, предпочитая решать свои потребности в подходе buy вместо build. Особенно это было выражено раньше, до того, как любая достаточно крупная компания стала “немножко биг-техом”. Процесс закупки ИС, особенно в государственном и крупном корпоративном секторе, часто осуществляется через тендерные процедуры. Это необходимо для обеспечения прозрачности и честной конкуренции среди поставщиков (хочется в это верить). Как правило тендер содержит следующие основные этапы:
- Подготовка тендерной документации: Заказчик разрабатывает ТЗ, в котором описываются требования к функциональности, производительности и другим характеристикам системы.
- Публикация тендера: Объявление о проведении тендера размещается на официальных площадках, чтобы привлечь поставщиков.
- Сбор и оценка заявок: Компании-поставщики направляют свои предложения. На основе критериев, изложенных в тендерной документации, оцениваются их соответствие требованиям и способности.
- Выбор победителя и заключение контракта: На основании комплексной оценки заявок выбирается поставщик, с которым подписывается контракт.
Вроде всё логично. Но есть одно “но” – зачастую решение принимается только на основе конкурсной документации. Нетрудно догадаться, что это прекрасная почва для того, чтобы поставщику слега преукрасить действительность в свою пользу.
Проблематика несоответствия между тендерной документацией и реальным состоянием закупаемой ИС
Несоответствие между заявленными спецификациями в тендерной документации и реальными возможностями поставляемого продукта — распространённая проблема. Это может привести к увеличению расходов, задержкам в реализации проекта и недовольству пользователей. Помимо “злого умысла” могут быть и более банальные причины (в прямом соответствии с бритвой Хэнлона):
- Недостаточная детализация требований: В тендерной документации иногда отсутствует чёткое описание требований и критериев оценки, что затрудняет однозначное понимание поставщиками нужд заказчика.
- Неучтенные технологические ограничения: Часто заказчики не учитывают технические ограничения или специфики существующей инфраструктуры, что приводит к функциональным ограничениям в предложенных решениях.
- Пробелы в коммуникации: Недостаточное взаимодействие между заказчиком и поставщиками на этапе подготовки тендера может стать причиной неправильного толкования функциональных требований.
Как же с этим бороться? Мне видится есть одно действенное средство – технический аудит при закупках ИТ-систем!
Детальный технический аудит при закупках ИТ-систем как способ решения проблем несоответствия
Технический аудит предполагает работу “на уровне земли”, то есть с самой системой как единственным достоверным источником правды. “Бумажный аудит” через документы, презентации и другие прокси источники недопустим, т.к. не позволяет адекватно проработать ключевые риски.
Технический аудит должен быть направлен на проработку рисков в порядке убывания их приоритета. Для этого не требуется всестороннего реестра рисков, хотя основные риски безусловно должны быть зафиксированы перед началом этого процесса. Именно проработка основных рисков ляжет в основу работы по техническому аудиту. В процессе взаимодействия с системой скорее всего будут подмечены дополнительные поводы для беспокойства. Их стоит фиксировать и приоритезировать наравне с другими рисками.
Детальный технический аудит гармонично сочетается с пилотным внедрением. Пилотное внедрение это добротная методика, но не всегда есть возможность ей воспользоваться. Я рекомендую всегда проводить пилотное внедрение если это возможно и сочетать его с техническим аудитом.
К довольно очевидным минусам пилотного внедрения относится необходимость завершить тендерные процедуры. В случае неудовлетворительного пилота их нужно будет запустить заново. Также не обойдется без компенсации расходов исполнителя даже при провале пилота.
Из-за минусов пилотного внедрения оптимально получить инсталляцию для технического аудита в рамках тендера. Далеко не все поставщики могут на это пойти, но именно те из них, у кого “слова” меньше расходятся с “делом”, буду больше расположены подтвердить слова делом. Вот какие преимущества получает заказчик, использующий практику детального технического аудита:
- Выявление скрытых проблем: Позволяет заранее идентифицировать и устранить потенциал проблем в предлагаемой системе.
- Обоснованность выбора поставщика: Обеспечивает объективные данные для принятия решений при выборе поставщика, что снижает вероятность ошибок.
- Снижение финансовых рисков: Подтверждает, что система соответствует заявленным требованиям, и позволяет избежать дополнительных затрат на доработки после внедрения.
Заключение
В заключение можно сказать вот что. Понимание жизненного цикла корпоративных информационных систем, тщательное планирование тендерных процедур и проведение технического аудита являются критическими факторами для успешной реализации проектов по закупке корпоративного ПО. Эти меры позволяют минимизировать риски ошибок и обеспечить соответствие конечного решения ожиданиям бизнеса. И вообще уменьшают количество страданий в мире – короче сплошные плюсы!