Продолжение прежней истории с подмоченным оборудованием IBM пока отсутствует. До сих пор разбирались с Заказчиком везти ему железо или нет. Поэтому, пока об этом проекте рассказать особо нечего, исключая то, что сдавать проект надо через 10 дней, а по предварительным планам на все работы еще потребуется не менее 2-х месяцев. Проектная команда, во главе с менеджером проекта откровенно
«забили» на предложенную Заказчиком дату сдачи. Для меня вообще ход этого проекта полный нонсенс – даты утверждаются без наших подписей… Такое ощущение, что генеральный подрядчик сам собирается вести запуск систем.
В дополнение ко всему, инженеры обнаружили, недостатки комплектности оборудования, по другому говоря, часть оборудования была упущена из виду при подготовке спецификации. Это происходит сплошь и рядом когда не проводится предварительное техническое проектирование, а сразу идет конкурс.
Суть в том, что поставляются серверы IBM, которые предполагалось разбить на логические разделы (LPAR). Эту операцию можно производить либо со специальной аппаратной консоли, либо при наличии определенного программного обеспечения (стоимость $600 на процессор). Ни первого, ни второго у нас нет. Придется договариваться с IBMна время пуско-наладки помочь. Однако покупать все равно придется, что составит дополнительных затрат от 10 до 16 тыс. $. Конечно же в проекте должен быть фонд устранения вероятных рисков. Что-то я не помню, правда, в бюджете такую строчку в явном виде J.
Все это говорит о том, что ИТ инфраструктуру необходимо делать всегда в 2-а этапа.
На первом этапе, составляется спецификация по результатам эскизного проектированияи согласно этой неточной спецификации начинается поставка.
Параллельно идет процесс полноценного технического проектирования. По окончании стадии технического проектирования должна быть подготовлена окончательная спецификация, точная на 100%. Выявленный недостаток оборудования поставляется на данном этапе.
По окончании поставки 1-й, основной части оборудования (согласно эскизной спецификации) начинается монтаж и пусконаладка. Через некоторое время приходит остаток оборудования.
Да, в этом случае срок проекта несколько увеличивается. Однако это увеличение прогнозируемо как в сроках, так и в бюджете. В результате отсутствуют конфликты между Заказчиком и Исполнителем. Заказчик по результатам проекта, не будет считать что ему впарили лишнее, а Исполнитель не потеряет в прибылях и получит в свою копилку очередной удачный проект.
На этом можно пока временно поставить, так сказать запятую. Продолжение мытарств, по построению катастрофоустойчевых ЦОДов в государственном российском органе, будет продолжено в последующих «буднях».
А теперь, хотел бы немного поведать о другом проекте. Участвую я в другой истории.
Суть – одно из министерств России решило, что в этом году надо осчастливить себя и заодно часть учебных заведений России чем-то компьютерным. А компания, где я работаю, соответственно должна обосновать, по какой причине такое осчастливливание должно происходить.
Я предлагаю вдуматься в то, что происходит. Т.е. министерство имеет деньги и знает, что деньги обязаны быть потрачены на благие цели. Но вот на какие цели в министерстве не знают и просят сторонних людей, которые не имеют собственно прямого отношения к тому, чем занято министерство, объяснить чиновникам ЗАЧЕМ им тратить деньги.
После длинной цепочки в нашей организации, это дело свалилось благополучно на меня и я теперь должен обосновать с какого, такого перепугу надо потратить боооольшую кучу денег.
И вот сел я думу думать.
Позвал сотоварищей, вместе начали думу думать еще сильней.
Позвонили в парочку учебных заведений, знакомым преподавателям и спросили: «А вот если бы у вас были бы деньги, вы на что бы их в первую очередь потратили бы…»
Мысли рождались, но все какие-то слабенькие, так сказать креатив не попер...
Набросали варианты, под варианты накидали эскизы инфраструктуры, подсчитали деньги. Прошло 3 дня. Показали старшим братьям по разуму (системному архитектору, который съел собак больше чем я).
Не одобрил.
Уточнили название предполагаемого конкурса у Заказчика.
Название содержала немыслимые словесные кульбиты, переворачивающие с ног на голову наше решение.
Обоснование решения переделали.
Но суть технических решений менять не стали (часто так случается, что обоснование другое, а ИТ инфраструктура прежняя). Становилось жарче.
После одобрения второго варианта страшим братом, показали Заказчику.
Заказчик сути не понял и предложил альтернативную трактовку постановки задачи.
Т.о. прошло еще около 4-х дней.
Сегодня штурмом переделал техническое решение.
Все поменял кардинально.
Показал старшему брату.
Брат негодовал.
Устроили с ним и еще одним мучеником мозговой штурм.
В ходе 2-х часов сплошного мыслительного всплеска, родилась идея. Надо уподобить учебное заведение обычному предприятию. И начать решать обычные управленческие задачи, связанные с любым процессом управления предприятием (и под это все обосновать поставку серверов, программного обеспечения и т.д. и т.п.).
Как известно, в ходе управленческой деятельности необходимо осуществлять следующее:
·устанавливать цели;
·планировать задачи для достижения целей;
·организовывать производственный процесс;
·контролировать достижение целей;
·в ходе всех перечисленных действий необходима всеобщая координация.
Под эти обобщенные функциональные единицы мы и решили подвести информационно-технологические компоненты.
О сути компонентов и вариантах ИТ решений, покрывающих хотя бы частично тот или иной управленческий процесс расскажу в следующем своем выпуске.
