Одной из "инноваций" высокой модели зрелости ИТ являются функциональные тендеры, заключающиеся в том, что в требованиях к автоматизации не указываются конкретные продукты, а указываются исключительно функциональные требования, что дает свободу выбора решения для потенциальных поставщиков, а для заказчика - возможность выбора решения, которое максимально удовлетворяет его требованиям и, вместе с тем, сопряжено с наименьшими затратами.
Считаю такой подход к решению проблем автоматизации концептуально неправильным, при условии, что мы начинаем не чистого листа, потому что он разрушает стандартизацию - нельзя судить о размере айсберга по его вершине, так нельзя выбирать и решение исключительно по функционалу. Есть разные взгляды на стандартизацию для информационной безопасности (некоторые говорят, что это плохо, аргументируя это тем, что одна уязвимость сразу будет доступна везде, так как все стандартно), но я сторонник того, что в крупной компании на первый план выходит возможность управлять процессами обеспечения ИБ, а в хаотичной инфраструктуре это сделать крайне проблематично (покрайней мере эффективность (effectiveness) такой работы будет низкая). ОК, зафиксировали, стандартизация для ИБ - это хорошо, и если в этом есть сомнения, этому можно посвятить отдельный пост.
Если мы стартуем не с чистого листа, то у нас уже есть сложившиеся практики управления процессами ИТ и ИБ, уже есть типовые решения, шаблоны, правила - читай, стандарты, - есть компетенции по тем или иным решениям, тем или иным вендорам, поэтому наши операционные косты невелики, что является хорошим показателем для ИТ/ИБ (поскольку и то и другое прежде всего косты и вся наша эффективная работа заключается в уменьшении этих расходов). Стандартизация - эффективнейший инструмент в борьбе с костами. Если мы играем функциональные тендеры, то мы намеренно идем на разрушение этих сложившихся практик - закупая всю жизнь недешевое железо от HP по функциональному тендеру мы можем получить серверы от "Depo-computers", а принтеры от Ricoh, а сетевое оборудование - Huawei вместо Cisco. При этом, мы, безусловно, снизим закупочную стоимость, но, почему-то, забывая о законе сохранения, не понимаем, что косты уйдя из закупки перекочевали в операционные расходы, собственно с чем ИТ/ИБ борятся всю свою жизнь: новые решения новых вендоров, будучи функционально эквивалентными, могут иметь отличные практики по их сопровождению, обслуживанию, обеспечению безопасности.... - все это потребует создания новых практик, обучения обслуживающего персонала, написания новых стандартов, модификации процессов сопровождения и обеспечения безопасности - это все стоит ресурсов и это нельзя выпускать из вида и всегда тщательно анализировать при принятии решения о необходимости проведения функционального тендера.
Всему написанному можно возразить, сказав, что все требования по вендорам и соответствия существующим практикам/стандартам можно вписать в требования. Но тут у меня разрыв шаблона, поскольку добавление таких требований убивает идею функционального тендера, ибо выбирается решение не функционально удовлетворяющее, а продукт конкретного вендора.
Я склонен думать, что все это типичный пример "побочных последствий" КПЭ (см. раздел Problems), когда закупщикам ставится цель снижения стоимости закупок и они успешно сливают эти расходы в Operations. Но надо же за деревьями и лес видеть!
Считаю такой подход к решению проблем автоматизации концептуально неправильным, при условии, что мы начинаем не чистого листа, потому что он разрушает стандартизацию - нельзя судить о размере айсберга по его вершине, так нельзя выбирать и решение исключительно по функционалу. Есть разные взгляды на стандартизацию для информационной безопасности (некоторые говорят, что это плохо, аргументируя это тем, что одна уязвимость сразу будет доступна везде, так как все стандартно), но я сторонник того, что в крупной компании на первый план выходит возможность управлять процессами обеспечения ИБ, а в хаотичной инфраструктуре это сделать крайне проблематично (покрайней мере эффективность (effectiveness) такой работы будет низкая). ОК, зафиксировали, стандартизация для ИБ - это хорошо, и если в этом есть сомнения, этому можно посвятить отдельный пост.
Если мы стартуем не с чистого листа, то у нас уже есть сложившиеся практики управления процессами ИТ и ИБ, уже есть типовые решения, шаблоны, правила - читай, стандарты, - есть компетенции по тем или иным решениям, тем или иным вендорам, поэтому наши операционные косты невелики, что является хорошим показателем для ИТ/ИБ (поскольку и то и другое прежде всего косты и вся наша эффективная работа заключается в уменьшении этих расходов). Стандартизация - эффективнейший инструмент в борьбе с костами. Если мы играем функциональные тендеры, то мы намеренно идем на разрушение этих сложившихся практик - закупая всю жизнь недешевое железо от HP по функциональному тендеру мы можем получить серверы от "Depo-computers", а принтеры от Ricoh, а сетевое оборудование - Huawei вместо Cisco. При этом, мы, безусловно, снизим закупочную стоимость, но, почему-то, забывая о законе сохранения, не понимаем, что косты уйдя из закупки перекочевали в операционные расходы, собственно с чем ИТ/ИБ борятся всю свою жизнь: новые решения новых вендоров, будучи функционально эквивалентными, могут иметь отличные практики по их сопровождению, обслуживанию, обеспечению безопасности.... - все это потребует создания новых практик, обучения обслуживающего персонала, написания новых стандартов, модификации процессов сопровождения и обеспечения безопасности - это все стоит ресурсов и это нельзя выпускать из вида и всегда тщательно анализировать при принятии решения о необходимости проведения функционального тендера.
Всему написанному можно возразить, сказав, что все требования по вендорам и соответствия существующим практикам/стандартам можно вписать в требования. Но тут у меня разрыв шаблона, поскольку добавление таких требований убивает идею функционального тендера, ибо выбирается решение не функционально удовлетворяющее, а продукт конкретного вендора.
Я склонен думать, что все это типичный пример "побочных последствий" КПЭ (см. раздел Problems), когда закупщикам ставится цель снижения стоимости закупок и они успешно сливают эти расходы в Operations. Но надо же за деревьями и лес видеть!
No comments:
Post a Comment