Как не стать шашкой в шахматной игре, или Почему набитые шишки мало кого учат...
(Продолжение. Начало в IT News №16/2013)
Акт первый.
Поиски истины в темной комнате с оголенными проводами
И вот он, сладостный момент. Вы уже сильны, умны, хитры и предусмотрительны. Пришло время проверить при встраивании вас нового в старый корпоративный механизм, насколько вы стали сильны. Выдержит ли корпоративное поле новую, более тяжелую и мощную фигуру?
Шаг 1. Определяем состояние полей
С чего начать? С выбивания бюджета? Похоже, что вы нечему не научились. Начинать надо с определения зрелости бизнеса компании. Не то, насколько она прибыльна и каков антураж офиса или новой поточной линии производства. И не то, насколько велики бонусы и как все население страны дружно хочет работать в вашей компании.
Если у вас в компании каждый начальник сам решает, что делать и как, а руководство не в курсе, что в реальности происходит, ни о каких успешных IT-проектах можно и не думать. Только что-то маленькое. Большие и сложные проекты будут провалены. Этими самыми автономными начальниками. Общей несогласованностью. Лишний контроль им ни к чему.
Бизнес-процессы компании описаны? В каком виде? Если это стопка бумажек у того, на кого нагрузили работы по СМК, а все остальное работает так, как работало до эпохи нефтяного процветания, результат будет все тот же – провал проекта. А вот если вся или по крайней мере, бОльшая часть деятельности компании представлена в виде взаимосвязанных моделей, выполненных в единой методологии, понятно, где какая информация и какой документ находятся и нет между ними противоречий и нестыковок, вот тогда можно со спокойной совестью думать о Большом проекте. Как этого достичь? Это тема отдельная. Постараться для этого надо очень сильно. Всем, а не только IT-директору.
Шаг 2. Определяем потребности. Договариваемся со «своими». Выстраиваем баланс
Каждое подразделение имеет свои задачи и выдает результат, которым пользуются как структурные соседи, так и внешние компании. Вот с этих подразделений надо получить, обязательно в письменном виде, их «хотелки», то есть список того, какой функционал от ИТ им нужен. Пишите по максимуму, пусть помечтают. Получили? Зафиксировали как официальный документ? Теперь пусть напишут, зачем им это надо, и обоснуют, какую реальную пользу им это даст в виде роста их производительности. Опять фиксируйте как официальный документ. А вот теперь не поленитесь и подсчитайте, сколько на реализацию этих пожеланий нужно денег. Пусть выбирают: ходатайствовать и обосновывать свои пожелания перед генеральным и требовать увеличения бюджета не только на проект, но и на дальнейшее сопровождение и развитие или ужимать свои пожелания до рамок здравого смысла. Сделали? Теперь соберите их всех вместе, пусть подискутируют в присутствии генерального, а можно и акционеров, кому, что и в каком порядке надо будет сделать для наилучшего результата и чем они будут отвечать за свой вклад в проект. Чтобы это не превратилось в многомесячные упражнения в ораторском искусстве, ограничьте время на эскапады. Сделано? Внутренняя среда компании синхронизирована (по крайней мере внешне)? Пора заниматься ловкорукими и быстроглазыми хай-тек-купцами.
Шаг 3. Формируем «внешние» взаимоотношения с хай-тек-купцами
Предъявите хай-тек-купцам при встрече длинный первоначальный перечень «хотелок». Пусть понервничают. Бюджет пока держите в тайне, хотя не сильно играйте в секретность, у них, скорее всего, в компании могут быть свои люди, которые доложат, что вы ими манипулируете. Хотя уже по вашим подходам они поймут, что настроены вы серьезно и трюки с вами не прокатят.
Дальше разыгрываются трехходовка по снижению требований с вашей стороны и торг по бюджету и условиям проекта. Выбейте для себя возможность разворачивания стенда в самом строптивом подразделении с самыми монозадачными работниками – пусть помучаются с новой системой и выслушают взвешенные и интеллигентные комментарии руководителя этого подразделения, что даст вам очки и в переговорах с хай-тек-купцами. Там вы объясните, что можете играть роль сдерживающего фактора в общении с корпоративным правдоискателем, и покажете интеллигентному руководителю, что не все сотрудники подразделения заняты производительным трудом и есть хорошая возможность вести аппаратный торг с руководителем этого подразделения на синхронизацию интересов. Когда хай-тек-купец уже предвкушает подписанный контракт и прикидывает, куда потратить полагающиеся за это бонусы, обрадуйте необходимостью подписания SLA. Отразите в этом соглашении тот факт, что платить вы будете за конкретный результат: не в виде опытного запуска или пробной эксплуатации, а только в работе в реальной среде. Через какое-то время оговорите так называемый гарантийный срок. Плюс предусмотрите, что, если в течение года выйдет новая версия, вы после оценки получите ее со скидкой, а апдейт системы будет сделан за счет хай-тек-купца. Если последний не пойдет на это, вежливо попрощайтесь и переходите к работе с его конкурентом. Тот хай-тек-купец, который уверен в своем продукте, на такие условия пойдет. Будет ему и бонус, и совместный пиар, и рекомендации другим клиентам. Обязательно скажите об этом до переговоров о SLA, пусть знает и о кнуте, и о прянике.
Шаг 4. Считаем, считаем, считаем. Занавес. Продолжение во втором акте…
(Продолжение следует)
Заповеди IT-директора (сокращенный вариант)
1. Не бойтесь не делать. Перестаньте строить из себя монтёра-сержанта-спасателя в стиле «что приказали, то и исполняю, любой ценой». Станьте политиком, играйте в аппаратные игры, внедряйте только нужные проекты, не бойтесь говорить «нет», если есть сомнения в успехе. Не получится в этой компании, уйдете в другую, более эффективную. Мир велик, владеющие и руководящие идиоты от бизнеса поверхность земного шара не сплошным ковром покрывают.
2. Думайте, анализируйте и еще раз думайте, а не стройте предположения. До начала проекта, во время проекта, вне проекта, а не когда количество проблем в нем стало критическим. Не загоняйте себя в ловушку, пытаясь склеить несклеиваемое, не обещайте того, что не в состоянии понять и выполнить сами. Не беритесь за проекты, в которых не уверены, какими бы классными они ни казались. Даже если этот проект поддерживает сам вендор со своими ресурсами. Таких, как вы, у него много, рано или поздно у кого-то получится нормальный проект, о нем и будут говорить, кто же афиширует неудачи. И даже если ваши специалисты дают голову на отсечение, что сделают все как надо, им ведь попробовать интересно, выгодную компетенцию нарастить для будущего. Ну не получилось у них сделать – виноваты только начальник-ламер и вендор криворукий. Ну сменят место работы, какие проблемы. Дефицит и востребованность IT-специалистов с опытом никто не отменял. Ответственность за весь проект все равно на вас и только на вас. Отвечать за впустую потраченные бюджеты и отсутствие результата вам, а не им.
3. Не жадничайте. Всегда будет желание взять недорогое решение, которое вроде и хорошо, но что-то настораживает. Ваша цель – сделать ИТ работающими, и компромиссы в стиле «лучшее соотношение цена/качество» не только неуместны, но и опасны. А уж про маркетинговую поддержку хай-тек-купцов забудьте. Не давайте им, да и коллегам по корпоративному полю, инструмент по манипулированию вами. Ну разбогатеете на пару лет позже, но ни у кого не будет повода называть вас маркой стиральной машины. Со спокойной совестью легче спится и надежнее дела делаются.
4. Не верьте. Красивым интерфейсам, обещаниям совместимости, новому функционалу, восторгу своих технарей. Тем более если все это декларировано в красочной презентации, продемонстрировано в демоверсии или проверено в результате референс-визита технарей под строгим присмотром хай-тек-купца. Стенд, тест, обкатка в боевых условиях на самых глупых пользователях, на самом провальном и конфликтном подразделении, и, если результат будет внушать оптимизм, только тогда можно думать о проекте.
5. Изучайте. Досконально, не только по книжкам, но и на практике. В первую очередь все тонкости ведения бизнеса в компании, какая продукция производится, как производится, почему производится эта, а не другая. Как продавцы работают с клиентом, какие тренинги посещают, что из этого выносят, как работают с клиентом. Пригодится тогда, когда соседние подразделения начнут втирать вашим аналитикам сказки про то, как они работают и что им нужно от ИТ.
6. Коммуницируйте. Кто владеет информацией, тот понимает все явные и скрытые потоки информации, пересечения и несовпадения интересов, мотивы действий. Сидя в серверной и гоняя чаи с подчиненными или корпя в своем кабинете над отчетами и документами, много не узнаешь. Общайтесь, общайтесь, общайтесь. Если надо, превратитесь в жилетку, в которую плачутся коллеги. Среди вала эмоций будут крупинки бесценной информации, сможете потом использовать ее на благо IT-проекта и не только.
7. Считайте. Не пытайтесь захапать больше бюджета, чем сможете переварить, даже если способны обосновать целесообразность его выделения. Маятник качнется в обратную сторону, и, когда в следующий раз очень понадобятся деньги, их могут не выделить. А если уже выделили, тратьте с умом. Не надо лихорадочно закупать новенькое оборудование, просто чтобы оно было. Потом это аукнется повышенными амортизационными отчислениями. Не надо накачивать заработные платы – бюджет просядет, и все либо перестанут работать, либо уйдут в более доходное место. Лучше используйте мотивационные схемы в оплате. Если деньги некуда девать, договоритесь с коллегой-партнером о переброске части бюджета на его проект в формате взаимозачета, но подходить к этому надо очень и очень взвешенно.
Некоторые признаки потенциально провального IT-проекта
В компании параллельно идет несколько проектов (ИТ или не ИТ, неважно), выполняемых по разным методологиям.
Выделен бюджет исходя из понимания финансистов, и под него ищутся решения.
Существенные расхождения сроков и ресурсов от запланированных, даже если в совокупности все сходится.
До выделения бюджета не сделан анализ потребностей бизнеса (в целом и в частности по подразделениям).
План-график проекта определяет поставщик исходя из загруженности ключевых специалистов интегратора в других проектах.
Бизнес-процессы для проекта описывает либо интегратор, либо каждое из подразделений – пользователей системы делает это по своей методике, либо берутся модели из СМК.
Описываются IT-процессы, и под них пытаются «подогнать» бизнес-процессы.
Не проводятся стендовые испытания и оценка удовлетворенности самыми проблемными и конфликтными подразделениями – будущими пользователями системы.
Идеология новой системы радикально отличается от уже имеющейся.
Проект делается только силами IT-дирекции, без привлечения бизнес-подразделений, либо их участие номинальное.
Генеральный директор не предоставил карт-бланш IT-директору и не курирует проект как «спонсор».
Не разработана система показателей для оценки качества внедрения до начала проекта.
Отсутствует формализованный SLA (с бонусами и штрафами) с поставщиком и интегратором.
Опубликовано 23.12.2013