In theory, theory and practice are the same. In practice, they are not.
Я уже писал о вреде функциональных тендеров для высокотехнологичных системуслуг, однако, мода - жестока, а решающие судьбы стремятся ей следовать, ну а нам, решающим проблемы,необходимо придумывать как остаться модным и при этом не навредитьпроизводству.
Наверно самым ужасным последствием функционального тендера является получение предложений, которые объективно невозможно сравнить. Объяснение очевидно: у меня есть практика использования ряда продуктов (если я радел за стандартизацию, то, очевидно, - одного-двух), о них я имею мнение, подтвержденное практическим опытом. Однако, в результате функционального тендера я получаю предложения из всех продуктов, представленных на рынке. Почувствуйте разницу между перечнем продуктов, которые яотшортлистил у себядля использованияв компании, очевидно, из соображений стандартизации, и перечнем вообще всех продуктов, представленных на рынке в данном классе. Оставим за кадром устойчивое желание производителя убеждать меняв том, что его продукция соответствует запрашиваемому мноюклассу продуктов, допустимяпокупаюне что-то волшебное, типа DLP или SIEM , где функционал может варьироваться настолько, что вместо первого мнемогут продать антиспам или Remote Desktop, а вместо второго - сервер syslog, а выбираючто-то более понятное - СХД , или систему резервного копирования, или, просто, сервер, монтируемый в стойку. И даже в этом случае, выбор на основании заверений производителей, подкрепленный только маркетинговыми буклетами, - чреват супер-негативными последствиями для моегоИТ-комплекса. Ни для кого не секрет, что в приличном ряде случаев, заявленные в спецификациях показатели либо вовсе не выполняются никогда, либо достигаются только в тепличных лабораторных условиях, далеких от боевых, поэтому полагаться на них слепо, с моей точки зрения, - преступная халатность!
Но закончим бла-бла-бла! Риски, порожденные желаниемразвивать ИТ на базе функциональных тендеров надо компенсировать,придумывать контрмеры. И вот что сразу приходит на ум.
1. Без сомнения нельзя включать в боевые системы решения, не прошедшие тестирование в компании.А раз так, имеет смысл говорить о внутренней сертификации (== тестирование в максимально приближенных к боевым условиях).
2. Порядок проведения внутренней функциональной сертификации - предмет отдельного поста, может, и не одного, но, как минимум должны проверяться:
- все предъявляемые функциональные требования (собственно, все требования, заявленные в функциональной спецификации),
- требования по надежности и доступности,
- требования по интеграции и совместимости,
- работа вендорских линий поддержки,
- стоимость владения: периодическое обслуживание, ЗИП и т.п.
В общем, все это тянет на эксплуатацию в течение не менее 3-х месяцев, причем, очевидно, чем дольше, тем лучше.
3. Результаты тестирования - использовать как при подготовкеусловий функционального выбора - среди каких вендоров (очевидно, если фирма "Нашимаршрутизаторы" делает ненадежное сетевое оборудование, его не надорассматривать в функциональном тендере на выбор маршрутизаторов), так и при оценке соответствия функциональным требованиям (т.е. полагаться не голословные заверения вендора, а на результаты собственной сертификации).
Понятно, что все эти упражнения с сертификацией потребуют дополнительных немалых инвестиций: в оборудование, которое нивелируетриски нестабильной работы испытываемого железа и софта (или вовсе придется подниматьспециализированную тестовую лабораторию), в персонал, который будет осуществлять интеграциютестируемого оборудования в среду, затем - занитизацию, скорее всего, потребуются какие-либо дополнительные тестовые испытания, имитирующие пиковые нагрузки или нестандартное поведение окружения и пользователей.... в общем, стандартно, новый процесс - новые инвестиции, Закон сохранения работает всегда!
Если взять во вниманиевсе о чем я сейчас и ранее написал, то первоначальная идеяполучения экономии, породившая функциональные тендеры, по крайней мере в области ИТ иилиИБ, мне кажется ошибочной. А вам?
