Больше двух лет лежала в черновиках заметка, решил опубликовать. К сожалению, тема “Как генерировать правильные и хорошие решения?” не раскрыта. 😉
Сегодня решил написать не про виртуализацию, а про более общую, сильно философскую тему. Про подготовку решений и принятие решений.
Начну с простого примера, который и буду раскручивать для раскрытия формирования решения. Перед некоей компанией стоит проблема выбора – все сервера виртуализировать или не все.
Второй проблемой стало резервное копирование. В компании имеет FC-хранилище entry-уровня и резервные копии с одних LUNов с данными кладутся на другие LUNы. На вопрос “вы понимаете, что в случае проблем со хранилищем вы потеряете всё?” получен ответ “да, понимаем!”.
Третье проблемой является наличие бородатых серверов 3-5-7 летней старости временами тормозящих, и ИТ хочет обновить часть из них.
Со своими проблемами ИТ приходит к бизнесу и требует сделать ВЫБОР, предлагая варианты решения.
Первое развитие. “Мы не хотим просить”
Решение проблем:
- Первой – не будем виртуализовать новые сервисы, у нас итак 3 сервака виртуальных.
- Второй – Положить резервные копии с одних 10 серверов на локальные диски другие 10 серверов, ведь там есть свободное место.
- Третьей – оставить инфраструктуру как есть, подкрутить настройки, перекомплектовать сервера, пересобрать RAID’ы.
Второе развитие. “Раз вы просите, то держите”
ИТ-отдел почесал репу и предложил “комплексное” решение:
Давайте купим блейд-центр с 8 лезвиями, напичканными самыми крутыми процессорами, завиртуализируем на них часть сервисов, плюс пару серверов дополнительно будем их использовать по классической схеме без виртуализации. На вопрос “а разве сервисы, которые будут на этой паре запущены проблематично виртуализовать?” дают “чтобы избежать пустых разговоров что 1с7 тормозит из-за того, что сервер виртуальный, я решил сделать так”. Решение вышло порядка 100 тысяч баксов, оно решило бы пару проблем, а резервные копии видать предлагается делать по первому варианту развития.
Муки выбора
Бизнес спрашивает: “оба варианта работают?”, – “да, первый это как теперь, правда, иногда тормоза и бэкап не старее пары дней, а вот если второй должно всё хорошо работать.”
А теперь посмотрите на позицию бизнеса, ему предложили целых ДВА варианта: один не требует ЗАТРАТ и всё работает с мелкими косяками, а второй – возьми и выложь 100 000 баксов с вероятным улучшением ситуации.
В итоге, ИТ в горести, печали и обиде, бизнес тоже недоволен.
“Принимай решение не торопясь, взвесив все возможные варианты.” – один из принципов менеджмента Toyota.
ИТ выступил стороной готовящей решения, и сделал два ПЛОХИХ варианта, первый плохой и для ИТ, и для бизнеса, а по второму не поинтересовался доступным бюджетом. Бизнес выступил стороной принимающей решения и выбрал из принципа “из двух зол выбирают меньшее”, денег столько тратить не готовы, и можно сделать “бесплатно”.
Вместо этого ИТ необходимо было подготовить 3-4 ХОРОШИХ варианта. Определить критичность и приоритет задач, разделить в соответствии с этим закупки на этапы, человеческим языком на уровне пользователя кратко пояснить, что даёт и какие проблемы закрывает каждый вариант, каждый этап. Чтобы бизнес правильно принял решение у него должны быть варианты правильных решений.
Знакомая ситуация… К сожалению – действительно, если предложить 2 варианта (бесплатно и фигово, относительно дорого и все-равно не идеально) БИЗНЕС выбирает первый.
А еще многое зависит от человека, который преподносит эти идеи БИЗНЕСУ, если красиво расписать второй вариант и меньше акцентировать внимание на первом, можно и второй вариант протолкнуть.
===============
По поводу потери всего при проблем с хранилищем – он (БИЗНЕС) то понимает, только вот жопа в мыле будет не у него а у ИТ в случае проблем. Не то, что бы БИЗНЕСУ было не холодно не жарко в случае проблем (у него тоже будет напряженка и аврал), но ИТ получит приказ восстанавливать инфраструктуру как хочет, хоть как-нить да еще и в минимальные сроки. Эт хорошо если еще БИЗНЕС адекватный и он признает что он понимал что ИТ его предупреждал, но бывает варианты, когда ИТ еще и крайний останется (мол чего не убедил, мы ведь люди далекие от этого и не понимали насколько это все опасно).
Словами выражено то, что уже на основании опыта понимается в голове, но четко не формулируется.
Спасибо.
Mister Nobody ты зачем такую “тяжелую” тему поднял?
Т.к. я уже много лет CIO, то отвечу за бизнес, т.к. сам познал на своей шкуре что такое – потребности бизнеса.
Все ит(шные) варианты решения проблем – барахло 🙂
Бизнесу нужно решение, которое не дорогое и не дешевое, ни плохое, ни хорошее, а выгодное!
А выгода, там, где формируются или открываются возможности.
Виртуализация открывает возможности, которые бизнес по мере своей зрелости либо пользует, либо нет, а это уже задача ит-управленца.
Вы должны бизнесу говорить что, есть “маза”, которая поможет, сэкономит, обеспечит конкурентное преимущество, удешевит бизнес-процессы, уберет проблемы, добавит понтов и прочее. А виртуальная или серверная “маза”, то бизнесу – ДО ЛАМПОЧКИ.
Может быть в этой ситуации выгоднее не железо покупать, а перейти на SaaS или PaaS с IaaS (Amazon, Bitcasa, например).
Процитирую моего руководителя – “… ит-подразделение нужно только потому, что те кто делает бабки не имеют времени разобраться в той куче проблем несовершенного софта и железа, которое есть на данный момент”.
Я вообще, всем рекомендую при разговоре с руководством говорить только языком бизнес-процессов, задач и процедур и их ЦЕН сейчас и потом, если примут ваше решение. А в основу любого финансово-экономического обоснования бэкапов закладывайте цену данных организации, ее знает фин. директор 🙂 Задайте ему вопрос. Ответ будет – феерическим, поверьте.
Кстати да, подпишусь под знанием цены данных фин.диром.
Общался с фин.диром одного SMB-предприятия (1 сервер, ~40ПК), так товарищи после общения со мной захотели поставить рейд-плату в сервер и организовать рейд-массив под диск с данными 1С.
Они, видимо, думали, что ежедневный бэкап закрывает их потребности. Когда я сказал, что это не так, стали чесать репу.
Немного подумав я решил написать 3 причины, когда бизнес дает денег ИТ:
1. Обучение, расширение кругозора, понты, просто по-приколу и т.д
В моей практике это было много раз, чаще всего это было импульсивное решение руководства, которое было поддержано и реализовано.
Пример: оснащение всех руководителей Ipad. Привело к тому, что теперь мы партнеримся с Apple на очень серьезном уровне и это влияет на бизнес.
2. Не дать денег нельзя, т.е. вынужденная выдача бабла на что-то непонятное.
Это 2 EMC CX-4 хранилища и мега проект по 1С. Это все потребовалось, когда бизнес начал расти по 20% в год.
3. Реальные инвестиции.
Это самый сложный момент. Ваша продукция должна быть либо электронной, либо иметь большую долю сложной обработки или учета в электронном виде. Также нужна гора расчетов и долгое формирование целого блока единомышленников из топ-менеджмента. Результатом будет изменение сути бизнеса, т.е. дорогое и комплексное решение. Пока в процессе.
Первая причина зависит от личности руководителя и его интуиции.
Вторая причина зависит от личности ИТ-руководителя и его интуиции.
Третья причина зависит от личности владельца и его интуиции.
Супер, но тут ИТ может влиять только на п.2 и косвенно на п.1.
Причем чаще на п.2 в форме шантажа “если мы не сделаем это, то все рухнет прям завтра в обед”. Ситуации “все дико тормозит” встречаются все реже.
Случай реальных инвестиций как правило самый затратный, если он влечет за собой модернизацию бизнес-процессов. Но он может обернуться самыми высокими прибылями в конце концов. И тут да, надо увидеть, что это стоит реализовать.
На самом деле все 3, просто методики разные.
п.1 – просто поддержать и удачно ввернуть в контекст решения проблемы и задачи свои услуги.
п2. – любой сбой или проблему анализировать и давать экспертизу.
п.3 – это уже “политИк”, т.е. задействование административного и коммуникативного навыка.
Но в их основе – четкий ответ на вопрос: “на фига это нужно?”. Ответил четко и просто – получи бабло. Начал рассказывать, да еще в итшных терминах, начнут сомневаться и искать альтернативы.
Вообще формула ит-управленца это завтракать с тем, кто отвечает за сбыт; обедать с тем кто отвечает за производство; а ужинать с тем, кто отвечает за финансы, и никогда не смешивать и не менять порядок 🙂