Неуловимый Джо информационных технологий
Автор
Андрей Федоров
Ребрендинг — красивое маркетинговое понятие, хотя в некоторых случаях под ним скрывается банальная спекуляция.
ИТ-стратегия порой напоминает «неуловимого Джо» из бородатого анекдота. Джо неуловим, потому как особо никому не нужен. На многих ИТ-мероприятиях спикеры проникновенно рассказывают о необходимости этой штуковины, слушатели сочувственно кивают, соглашаясь, что мол да, без нее никуда.
Затем, допытываясь у коллег о наличии этой сущности, с ужасом узнаешь, что ни у кого ее, в общем-то, нет, а у кого есть, давно пылится на полочке безо всякого применения. Или мне так везет?
Попробуем разобраться, почему «Джо» столь неуловим. По определению, взятому из презентации IBM: «ИТ стратегия — это согласованный с бизнес-стратегией концептуальный план развития информационных технологий, реализация которого обеспечит: взаимодействие высшего руководства и менеджеров ИТ в решении задач бизнеса, управление развитием ИТ в соответствии с долгосрочными целями бизнеса, эффективность долгосрочных инвестиций в развитие ИТ».
Пока-пока-по камушкам…
Итак, первый камень преткновения, о который сбиваешь ноги на фразе «согласованный с бизнес-стратегией», — собственно наличие этой самой бизнес-стратегии, чтобы было с чем согласовывать. Много ли российских предприятий ее имеют?
«Долгосрочные цели бизнеса» — нынче вполне себе определенное второе препятствие, ибо какое может быть долгосрочное планирование, если в мировой экономике все сотрясается, того и гляди рухнет. Когда вокруг нестабильно, по большей части думают о выживании, а не о развитии. Строить далеко идущие планы не приходится, ибо без толку. Сколько ни прогнозируй, все равно не угадаешь. Пожалуй, только корпорации-монстры могут себе позволить загадывать надолго, да и то, судя по спонтанным «сливам» кусков бизнеса и отказу от недавно приобретенных компаний/продуктов, долгосрочной бизнес-стратегией здесь как-то не пахнет. Получаем, что потолок планирования где-то год, а этот период долгосрочным никак не назовешь.
Третий камешек — «долгосрочные инвестиции в развитие ИТ». Если не рассматривать предприятия, для которых ИТ — основной инструмент зарабатывания денег, то долгосрочные инвестиции с началом кризиса и по сей день несколько усохли. Причем долгосрочные инвестиции не только в ИТ, так что обижаться на бизнес нет смысла, мы все в одной лодке. В ходу правило, что инвестиции нынче должны окупаться за год–два. Если больше — согласование финансирования уже под вопросом. Да и какие долгосрочные инвестиции в ИТ без долгосрочной стратегии?
Да и, по большому счету, на горизонте не видать новых ИТ, способных существенно повысить эффективность бизнеса. То, что было действительно полезно, большинство уже приобрело и адаптировало для нужд предприятий. В сухом остатке — вещи, широко рекламируемые, но по которым есть весомые сомнения в части окупаемости. Недавно даже ИТ-услуги, в частности аутсорсинг, попали в немилость на американском рынке: «В США начался коллапс на рынке ИТ-услуг» .
И, наконец, что касается «взаимодействия высшего руководства и менеджеров ИТ». Если бизнес осознал, что для дальнейшей работы жизненно необходима бизнес-стратегия, вероятнее всего его зрелость такова, что без участия ИТ-менеджера уже не обойтись. Грамотный ИТ-менеджер, участвуя в процессе создания бизнес-стратегии, способен дополнить ее нюансами, тесно связанными с ИТ, там, где это действительно полезно и позволит получить дополнительное конкурентное преимущество или, как минимум, держаться на плаву.
ИТ-менеджер: крылья, ноги и хвосты
Сделать декомпозицию глобальной бизнес-стратегии на функциональные подразделения, в том числе ИТ, уже не большая проблема. На самом деле, даже если бизнес-стратегия сформулирована без участия ИТ-менеджера, само ее наличие существенно упрощает задачу разработки ИТ-стратегии. Если курс определен, то выйти на него со стороны ИТ не так сложно, учитывая достаточно широкий спектр инструментов. Не исключен вариант, когда поддержка бизнес-стратегии со стороны ИТ будет непомерно дорогой или слишком долгосрочной, но маловероятно, чтобы выпал вариант, когда ИТ совсем не сможет ей соответствовать.
Революция снизу, когда ИТ-менеджер по собственной инициативе создает ИТ-стратегию и затем предлагает ее в качестве одного из кирпичиков бизнес-стратегии, вероятно, возможны. Эдакий вариант, когда продвинутое яйцо начинают учить куриц(у). Однако, чтобы из этого что-то вышло, статус ИТ-менеджера в среде бизнес-руководства должен быть очень высок. ИТ-менеджер, зачастую, может лишь настойчиво подталкивать бизнес сделать движение в нужном направлении, но результат непредсказуем.
Опять же, в компаниях малого и среднего бизнеса, особенно в кризисные годы, из-за банальной нехватки персонала ИТ-менеджер в значительной степени занят оперативной работой. О краткосрочной ИТ-стратегии он, вероятно, размышляет, ведь ИТ в компании не может находиться в стагнации, поскольку это прямой путь к деградации, но вот смысл формулировать ее в виде некоторого документа для представления бизнес-руководству не очевиден.
Неисповедимы пути бизнеса
Мне не раз приходилось быть свидетелем столь спонтанных бизнес-изменений, которые не то что за год не прогнозировались, а и за пару месяцев до решения в курсе грядущих метаморфоз были единицы. Более того, не возьмусь однозначно сказать, хорошо это или плохо, что бизнес так непредсказуем. Думается, что в случае малого и среднего бизнеса это скорее плюс, а для крупного — скорее, нереализуемое исключение, так как инерционность последнего не позволит быстро меняться. Еще хуже, когда крупный глобальный бизнес диктует условия и загоняет в рамки средний бизнес дочерних компаний. Тогда и бежать быстро толком не получается, да и с маневрированием начинаются проблемы. Позволю себе далее сухое изложение сути проблемы изредка разбавлять «фигурами», или так называемыми «бизнес-кейсами».
Фигура первая, назидательная
Дело было в предкризисные годы, на дворе стоял август. Мы активно занимались проектом по смене платформы с «1С» 7.7 на 8.1 «УПП». Работы продвигались по графику, и до конца года планировалось завершить адаптацию с тестированием, с месяц поработать в двух системах параллельно, а с начала года переходить к запуску в работу.
Неожиданного из головного датского офиса компании приходит депеша, в которой нам предписывается бросать возню с «1С» и начинать подготовку к внедрению SAP. Первым делом надо было оценить затраты на перекройку инфраструктуры под SAP. Поскольку наша компания была приобретена относительно недавно, у нас действовали собственные стандарты на ИТ-оборудование и ПО, по ряду позиций отличающиеся от стандартов собственника, куда более дорогих, да и, местами, не особо для нас пригодных. Соответственно, перед развертыванием SAP надо было все перестандартизировать, проще говоря, выбросить «все, что нажито непосильным трудом» и заменить на новое. Естественно, за наш счет.
По нашему мнению особого смысла во внедрении SAP в компании, в общем-то, не было, а доводить до нас, зачем оно нам надо, не стали. Компания работает относительно автономно от собственника, то есть получаемый синергетический эффект с тем, какая информационная система для управления у нас используется, коррелирует слабо. Вполне достаточно небольшого количества информационных стыков. Отчасти мы выживали и были прибыльны за счет оперативного изменения бизнес-процессов. Для этого нам требуется гибкая система, а SAP, который хостится за рубежом, к таковым можно было причислить с большой натяжкой. Ждать месяцами изменений, которые нужно сделать за неделю — явно не способствуют развитию и процветанию бизнеса. Хотя такой подход типичен для западных компаний. Вероятнее всего, опять же пресловутая стандартизация без оглядки на целесообразность и экономические расчеты. Совокупные инвестиции в SAP для нас были как дополнительный груз пловцу, с которым бы он как минимум хорошо нахлебался воды, а то и вовсе пошел ко дну, но зато стандартно.
В октябре того же года состоялась встреча с руководством проекта по внедрению SAP, на которой нас просветили, что внедрять SAP надо, потому как он стоит у большинства компаний холдинга, и этой участи нам не избежать, ибо мы есть в графике внедрений. В ответ мы продемонстрировали разработанные нами ИТ-системы, покрывающие бизнес-процессы компании. Системы, максимально «заточенные» под оптимальное выполнение операций сотрудниками. После демонстрации у руководства появилось выражение озадаченности. По ходу выяснилось, что некоторые вещи в реализации SAP нам как-то не очень подходят, а менять их ради нас никто не собирается, ибо это основа для учета всего холдинга. Мы, конечно, уже смирились с тем, что какие-то ключевые для нас вещи после внедрения придется выполнять ректально. Но — надо так надо, best-practice все-таки, супротив не попрешь. Да и сколько жертв до этого уже приходилось приносить на алтарь различным ИТ-богам, SAP — не первый и не последний, а «человек, как таракан, ко всему привыкнет».
В общем, озадаченное SAP руководство покинуло нашу скромную обитель. Проект по внедрению «1С» находился в «замороженном» состоянии. Где-то по прошествии месяца мы получили известие, что внедрение SAP в компании откладывается на неопределенный срок, и мы можем продолжать развертывать «1С». Эта коллизия обошлась моему бюджету в лишних несколько сотен тысяч рублей, поскольку пришлось нагонять месяцы «заморозки». Запускали «1С» «по-живому», без тестовой эксплуатации, в результате первый квартал нового года специалисты «1С» дни и ночи сливались в экстазе с нашим проектом и были порядком измождены под конец. Эту утеху с ними разделили и сотрудники бизнес-подразделений. Но, к их чести, компания не померла, мужественно пережив тяготы и невзгоды и перейдя на новый уровень оптимизации бизнес-процессов.
Полагаю, немало коллег, работающих в локальных компаниях крупных холдингов, не раз бывали в подобных ситуациях. При этом степень зрелости бизнеса холдинга может быть сколько угодно высокой. Однако подобный стиль управления — достаточно характерный шаблон. В данном случае подход простой: раз ИТ-стратегия на повсеместную стандартизацию каким-то продуктом принята, то нужно ей следовать, не взирая ни на что. Не совпади сроки внедрения с нарастающей первой волной кризиса и соответствующим сокращением доходов, развернули бы SAP и потом несколько лет зализывали бы раны, очухиваясь от внедрения, восстанавливая прибыльность бизнеса. В нашем случае дорогое ПО для управления — скорее, «не по Сеньке шапка». Дополнительные преимущества вряд ли получим, но потратимся хорошенько.
Партизанские ИТ
По аналогии с «партизанским маркетингом», пожалуй, уже настало время вводить термин «партизанские ИТ» (guerrilla IT), ибо сейчас обилие технологий и их доступность позволяют за скромные деньги решать весьма сложные и амбициозные задачи, причем, быстро, что немаловажно. В крупном бизнесе, избалованном значительными бюджетами, подобные эксперименты не приветствуются, ибо риски относительно высоки. Гораздо проще и надежней (впрочем, в последнее время не всегда) выбрать проверенное решение известного брэнда, не важно, что наценка за «марку» может быть многократной от реальной стоимости.
В случае относительно небольших компаний, собственниками которых является крупный бизнес, потребность в «партизанских ИТ» получается еще выше, ибо стандарты и стратегия в головном офисе рождаются долго и в муках, а работать как-то надо, поэтому приходится искать дешевые, а то и вовсе бесплатные субституты, чтобы не помереть в процессе родов.
В последние годы соблазн воспользоваться подходами «партизанских ИТ» возникает все чаще, ибо качество многих коммерческих продуктов скорее падает при сопутствующем росте цены, мотивируемой ростом количества зачастую ненужного функционала. С сервисом тоже как-то дороговато, и его качество порой оставляет желать лучшего. В идеале при использовании коммерческих продуктов у компании существенные затраты на инвестиции должны компенсироваться сокращением операционных расходов. На практике, частенько, получаем как рост капитальных затрат, так и операционных расходов. То, что поддержку коммерческого продукта можно передать на аутсорсинг, в чем-то уменьшает риски зависимости от своих сотрудников, например, разработчиков, но увеличивает зависимость от производителя. Причем, зависимость от производителя или аутсорсера получается куда более жесткой, поскольку если после внедрения оказывается, что софт глючный, шансов, что вскоре будет решение проблемы от производителя, не слишком много. Зато придется щедро вознаграждать аутсорсера за разработку различных workaround, чтобы заставить коммерческий софт хоть как-то дышать. Маркетинговая стратегия, когда изначально выпускается некачественный (сырой) продукт, чтобы потом можно было мужественно решать проблемы, попутно взимая с покупателей мзду за их решение, уже давно стала стандартом ведения бизнеса.
Фигура вторая, печальная
Долгое время мы использовали в компании оборудование Nortel, не дешевое, но весьма надежное. Пожалуй, это пример, когда инвестиции значительные, но операционные расходы относительно низкие. Мне был симпатичен их подход evergreen, который определял, что пользователь их оборудования относительно недорого может довести свое старое оборудование до современного уровня в любой момент. Грубо говоря, они декларировали возможность производить апгрейд оборудования, когда это реально необходимо, не взимая постоянную мзду за ненужный саппорт.
Avaya после приобретения компании Nortel об этой концепции благополучно позабыла, начав размывать часть полученных разработок в своих продуктовых линейках. Как-то возникла необходимость добавить несколько лицензий на SIP-транки, железо для поддержки которых уже есть в станции и нужно лишь сгенерировать кей-код для открытия функционала. Ранее добавление необходимого количества лицензий обошлось бы в $500. В ответ на мой запрос Avaya ответила, что софт на станции ныне уже не поддерживается, и чтобы добавить лицензий, нужно потратить что-то около $18 тыс. на обновление ПО до поддерживаемого уровня и на приобретение ненужного мне саппорта. По сути, нас взяли в заложники, навязав апгрейд станции и поддержку.
Используя подходы «партизанских ИТ», можно собрать вполне надежное решение добавив в схему Asterisk, эдакий швейцарский нож, которому под силу разрешить ряд проблем с телефонией с минимальным ущербом для бюджета.
Фигура третья, нервная
Приведу другой пример, показывающий, что приобретение коммерческих продуктов совсем не гарантирует их поддержку. Году в 2008-м для организации видеоконференцсвязи (ВКС) мы закупили недешевое оборудование итальянской фирмы Aethra. В кризис подразделение этой компании, занимающееся разработкой систем ВКС, было приобретено RADVision. Некоторое время назад, зайдя на российский сайт Aethra, мы обнаружили новую прошивку для ВКС, сдуру накатили на «железо», после чего имеющийся у нас код активации перестал подходить, а старой прошивки уже ни где не было. Нет бы предупредить заранее, что прошивка требует другого кода! Обратились в Aethra (ныне RADVision), получили ответ: оборудование не поддерживается; старую прошивку мы не знаем где взять; лицензии на новую не знаем, как сгенерировать, но постараемся помочь. Ждем помощи уже с месяц, но опыт подсказывает: шансов, что она будет, нет. По счастью на torrent нашлась старая прошивка (более старая, чем у нас была, но которая не спрашивает ключа активации). По идее, если ты не желаешь продавать продукт и ключи к нему, сними защиту и выложи в открытый доступ. Это было бы корректно по отношению к потребителям и не оставалось бы неприятного осадка.
Следуя принципам «партизанских ИТ», здесь тоже можно приладить Asterisk, собрав незамысловатую конструкцию из камеры с широкоугольным объективом, например топовыми моделями web камер от Logitech, HP, Microsoft и др., либо для особых ценителей качества и нестандартных решений - использовать в качестве веб-камеры фотоаппарат (например, «зеркалку») или видеокамеру, и подходящим VoIP-клиентом. Как верно отмечалось в рекламе, «если нет разницы, зачем платить больше». Несомненно, при таком подходе подрастет стоимость сопровождения за счет падения юзабилити, но зато можно подсократить инвестиции. В некоторых случаях такой обмен более чем приемлем. По сути, это ИТ-стратегия на минимизацию капитальных затрат за счет роста операционных.
Мыши плакали, но продолжали есть кактус
Все мы понимаем, что производителям нынче хочется сделать так, чтобы оборудование/софт ломались в точно намеченный срок по окончании гарантии/техподдержки, чтобы покупатель шел за новым «шедевром». Проблема здесь одна: после подобных мытарств хочется навсегда позабыть о такой компании или о ее новом хозяине и попытать судьбу с другой, пусть потенциально такой же убогой, но с другой.
Ребрендинг — красивое маркетинговое понятие, хотя в некоторых случаях под ним скрывается банальная спекуляция. Грешат этим многие, и все бы ничего, если бы не многократное увеличение стоимости «отребрэнденных» продуктов. Например, у IBM, весьма уважаемой мной компании, «железками» которой пользуюсь многие годы, качество, производительность и уровень сервиса почти безупречны, но и ценник за приобщение к счастью соответствующий. И ладно, когда уверен, что покупаешь продукцию IBM и поэтому платишь соответственно! Но когда знаешь, что берешь, например, СХД от LSI, не менее уважаемой компании, но куда более скромной по аппетитам, под личиной IBM втридорога, почему-то не оставляет ощущение обмана. Это чувство усиливается, когда видишь ценник на жесткие диски для СХД. Какой-нибудь Seagate диск 2 Тбайт с SATA-интерфейсом стоит в районе $250–300, а тот же диск для СХД IBM DS4200 в «обертке» от IBM обойдется уже в $2500. И почему-то слабо верится, что замена в оригинальном диске Seagate прошивки волшебным образом повышает его надежность и производительность в 10 раз... И почему-то поставить оригинальный Seagate не получится — СХД его не признает за своего. Другие крупные вендоры, вроде HP, EMC и т.д., идут сходным путем, живя «на эти три процента».
На сей счет принцип «партизанских ИТ» говорит, что имеет смысл попробовать использовать подходящий сервер, скажем Supermicro, с установленным ПО, делающим из сервера СХД: Open-E, Nexenta, Avrora[Raid] и др. Кто-то скажет, что при такой ИТ-стратегии просядет надежность ИТ-системы. В некоторых случаях это несомненно, но, с другой стороны, стоимость такой СХД будет минимум в 4(!) раза меньше, чем «железо» именитого бренда, при сходной производительности. Фактически, по цене одной брендовой СХД можно взять минимум два отдельных сервера с двухканальными FC-картами и таким образом поднять отказоустойчивость системы, при «отвязавшись» от вендора.
Затем, допытываясь у коллег о наличии этой сущности, с ужасом узнаешь, что ни у кого ее, в общем-то, нет, а у кого есть, давно пылится на полочке безо всякого применения. Или мне так везет?
Попробуем разобраться, почему «Джо» столь неуловим. По определению, взятому из презентации IBM: «ИТ стратегия — это согласованный с бизнес-стратегией концептуальный план развития информационных технологий, реализация которого обеспечит: взаимодействие высшего руководства и менеджеров ИТ в решении задач бизнеса, управление развитием ИТ в соответствии с долгосрочными целями бизнеса, эффективность долгосрочных инвестиций в развитие ИТ».
Пока-пока-по камушкам…
Итак, первый камень преткновения, о который сбиваешь ноги на фразе «согласованный с бизнес-стратегией», — собственно наличие этой самой бизнес-стратегии, чтобы было с чем согласовывать. Много ли российских предприятий ее имеют?
«Долгосрочные цели бизнеса» — нынче вполне себе определенное второе препятствие, ибо какое может быть долгосрочное планирование, если в мировой экономике все сотрясается, того и гляди рухнет. Когда вокруг нестабильно, по большей части думают о выживании, а не о развитии. Строить далеко идущие планы не приходится, ибо без толку. Сколько ни прогнозируй, все равно не угадаешь. Пожалуй, только корпорации-монстры могут себе позволить загадывать надолго, да и то, судя по спонтанным «сливам» кусков бизнеса и отказу от недавно приобретенных компаний/продуктов, долгосрочной бизнес-стратегией здесь как-то не пахнет. Получаем, что потолок планирования где-то год, а этот период долгосрочным никак не назовешь.
Третий камешек — «долгосрочные инвестиции в развитие ИТ». Если не рассматривать предприятия, для которых ИТ — основной инструмент зарабатывания денег, то долгосрочные инвестиции с началом кризиса и по сей день несколько усохли. Причем долгосрочные инвестиции не только в ИТ, так что обижаться на бизнес нет смысла, мы все в одной лодке. В ходу правило, что инвестиции нынче должны окупаться за год–два. Если больше — согласование финансирования уже под вопросом. Да и какие долгосрочные инвестиции в ИТ без долгосрочной стратегии?
Да и, по большому счету, на горизонте не видать новых ИТ, способных существенно повысить эффективность бизнеса. То, что было действительно полезно, большинство уже приобрело и адаптировало для нужд предприятий. В сухом остатке — вещи, широко рекламируемые, но по которым есть весомые сомнения в части окупаемости. Недавно даже ИТ-услуги, в частности аутсорсинг, попали в немилость на американском рынке: «В США начался коллапс на рынке ИТ-услуг» .
И, наконец, что касается «взаимодействия высшего руководства и менеджеров ИТ». Если бизнес осознал, что для дальнейшей работы жизненно необходима бизнес-стратегия, вероятнее всего его зрелость такова, что без участия ИТ-менеджера уже не обойтись. Грамотный ИТ-менеджер, участвуя в процессе создания бизнес-стратегии, способен дополнить ее нюансами, тесно связанными с ИТ, там, где это действительно полезно и позволит получить дополнительное конкурентное преимущество или, как минимум, держаться на плаву.
ИТ-менеджер: крылья, ноги и хвосты
Сделать декомпозицию глобальной бизнес-стратегии на функциональные подразделения, в том числе ИТ, уже не большая проблема. На самом деле, даже если бизнес-стратегия сформулирована без участия ИТ-менеджера, само ее наличие существенно упрощает задачу разработки ИТ-стратегии. Если курс определен, то выйти на него со стороны ИТ не так сложно, учитывая достаточно широкий спектр инструментов. Не исключен вариант, когда поддержка бизнес-стратегии со стороны ИТ будет непомерно дорогой или слишком долгосрочной, но маловероятно, чтобы выпал вариант, когда ИТ совсем не сможет ей соответствовать.
Революция снизу, когда ИТ-менеджер по собственной инициативе создает ИТ-стратегию и затем предлагает ее в качестве одного из кирпичиков бизнес-стратегии, вероятно, возможны. Эдакий вариант, когда продвинутое яйцо начинают учить куриц(у). Однако, чтобы из этого что-то вышло, статус ИТ-менеджера в среде бизнес-руководства должен быть очень высок. ИТ-менеджер, зачастую, может лишь настойчиво подталкивать бизнес сделать движение в нужном направлении, но результат непредсказуем.
Опять же, в компаниях малого и среднего бизнеса, особенно в кризисные годы, из-за банальной нехватки персонала ИТ-менеджер в значительной степени занят оперативной работой. О краткосрочной ИТ-стратегии он, вероятно, размышляет, ведь ИТ в компании не может находиться в стагнации, поскольку это прямой путь к деградации, но вот смысл формулировать ее в виде некоторого документа для представления бизнес-руководству не очевиден.
Неисповедимы пути бизнеса
Мне не раз приходилось быть свидетелем столь спонтанных бизнес-изменений, которые не то что за год не прогнозировались, а и за пару месяцев до решения в курсе грядущих метаморфоз были единицы. Более того, не возьмусь однозначно сказать, хорошо это или плохо, что бизнес так непредсказуем. Думается, что в случае малого и среднего бизнеса это скорее плюс, а для крупного — скорее, нереализуемое исключение, так как инерционность последнего не позволит быстро меняться. Еще хуже, когда крупный глобальный бизнес диктует условия и загоняет в рамки средний бизнес дочерних компаний. Тогда и бежать быстро толком не получается, да и с маневрированием начинаются проблемы. Позволю себе далее сухое изложение сути проблемы изредка разбавлять «фигурами», или так называемыми «бизнес-кейсами».
Фигура первая, назидательная
Дело было в предкризисные годы, на дворе стоял август. Мы активно занимались проектом по смене платформы с «1С» 7.7 на 8.1 «УПП». Работы продвигались по графику, и до конца года планировалось завершить адаптацию с тестированием, с месяц поработать в двух системах параллельно, а с начала года переходить к запуску в работу.
Неожиданного из головного датского офиса компании приходит депеша, в которой нам предписывается бросать возню с «1С» и начинать подготовку к внедрению SAP. Первым делом надо было оценить затраты на перекройку инфраструктуры под SAP. Поскольку наша компания была приобретена относительно недавно, у нас действовали собственные стандарты на ИТ-оборудование и ПО, по ряду позиций отличающиеся от стандартов собственника, куда более дорогих, да и, местами, не особо для нас пригодных. Соответственно, перед развертыванием SAP надо было все перестандартизировать, проще говоря, выбросить «все, что нажито непосильным трудом» и заменить на новое. Естественно, за наш счет.
По нашему мнению особого смысла во внедрении SAP в компании, в общем-то, не было, а доводить до нас, зачем оно нам надо, не стали. Компания работает относительно автономно от собственника, то есть получаемый синергетический эффект с тем, какая информационная система для управления у нас используется, коррелирует слабо. Вполне достаточно небольшого количества информационных стыков. Отчасти мы выживали и были прибыльны за счет оперативного изменения бизнес-процессов. Для этого нам требуется гибкая система, а SAP, который хостится за рубежом, к таковым можно было причислить с большой натяжкой. Ждать месяцами изменений, которые нужно сделать за неделю — явно не способствуют развитию и процветанию бизнеса. Хотя такой подход типичен для западных компаний. Вероятнее всего, опять же пресловутая стандартизация без оглядки на целесообразность и экономические расчеты. Совокупные инвестиции в SAP для нас были как дополнительный груз пловцу, с которым бы он как минимум хорошо нахлебался воды, а то и вовсе пошел ко дну, но зато стандартно.
В октябре того же года состоялась встреча с руководством проекта по внедрению SAP, на которой нас просветили, что внедрять SAP надо, потому как он стоит у большинства компаний холдинга, и этой участи нам не избежать, ибо мы есть в графике внедрений. В ответ мы продемонстрировали разработанные нами ИТ-системы, покрывающие бизнес-процессы компании. Системы, максимально «заточенные» под оптимальное выполнение операций сотрудниками. После демонстрации у руководства появилось выражение озадаченности. По ходу выяснилось, что некоторые вещи в реализации SAP нам как-то не очень подходят, а менять их ради нас никто не собирается, ибо это основа для учета всего холдинга. Мы, конечно, уже смирились с тем, что какие-то ключевые для нас вещи после внедрения придется выполнять ректально. Но — надо так надо, best-practice все-таки, супротив не попрешь. Да и сколько жертв до этого уже приходилось приносить на алтарь различным ИТ-богам, SAP — не первый и не последний, а «человек, как таракан, ко всему привыкнет».
В общем, озадаченное SAP руководство покинуло нашу скромную обитель. Проект по внедрению «1С» находился в «замороженном» состоянии. Где-то по прошествии месяца мы получили известие, что внедрение SAP в компании откладывается на неопределенный срок, и мы можем продолжать развертывать «1С». Эта коллизия обошлась моему бюджету в лишних несколько сотен тысяч рублей, поскольку пришлось нагонять месяцы «заморозки». Запускали «1С» «по-живому», без тестовой эксплуатации, в результате первый квартал нового года специалисты «1С» дни и ночи сливались в экстазе с нашим проектом и были порядком измождены под конец. Эту утеху с ними разделили и сотрудники бизнес-подразделений. Но, к их чести, компания не померла, мужественно пережив тяготы и невзгоды и перейдя на новый уровень оптимизации бизнес-процессов.
Полагаю, немало коллег, работающих в локальных компаниях крупных холдингов, не раз бывали в подобных ситуациях. При этом степень зрелости бизнеса холдинга может быть сколько угодно высокой. Однако подобный стиль управления — достаточно характерный шаблон. В данном случае подход простой: раз ИТ-стратегия на повсеместную стандартизацию каким-то продуктом принята, то нужно ей следовать, не взирая ни на что. Не совпади сроки внедрения с нарастающей первой волной кризиса и соответствующим сокращением доходов, развернули бы SAP и потом несколько лет зализывали бы раны, очухиваясь от внедрения, восстанавливая прибыльность бизнеса. В нашем случае дорогое ПО для управления — скорее, «не по Сеньке шапка». Дополнительные преимущества вряд ли получим, но потратимся хорошенько.
Партизанские ИТ
По аналогии с «партизанским маркетингом», пожалуй, уже настало время вводить термин «партизанские ИТ» (guerrilla IT), ибо сейчас обилие технологий и их доступность позволяют за скромные деньги решать весьма сложные и амбициозные задачи, причем, быстро, что немаловажно. В крупном бизнесе, избалованном значительными бюджетами, подобные эксперименты не приветствуются, ибо риски относительно высоки. Гораздо проще и надежней (впрочем, в последнее время не всегда) выбрать проверенное решение известного брэнда, не важно, что наценка за «марку» может быть многократной от реальной стоимости.
В случае относительно небольших компаний, собственниками которых является крупный бизнес, потребность в «партизанских ИТ» получается еще выше, ибо стандарты и стратегия в головном офисе рождаются долго и в муках, а работать как-то надо, поэтому приходится искать дешевые, а то и вовсе бесплатные субституты, чтобы не помереть в процессе родов.
В последние годы соблазн воспользоваться подходами «партизанских ИТ» возникает все чаще, ибо качество многих коммерческих продуктов скорее падает при сопутствующем росте цены, мотивируемой ростом количества зачастую ненужного функционала. С сервисом тоже как-то дороговато, и его качество порой оставляет желать лучшего. В идеале при использовании коммерческих продуктов у компании существенные затраты на инвестиции должны компенсироваться сокращением операционных расходов. На практике, частенько, получаем как рост капитальных затрат, так и операционных расходов. То, что поддержку коммерческого продукта можно передать на аутсорсинг, в чем-то уменьшает риски зависимости от своих сотрудников, например, разработчиков, но увеличивает зависимость от производителя. Причем, зависимость от производителя или аутсорсера получается куда более жесткой, поскольку если после внедрения оказывается, что софт глючный, шансов, что вскоре будет решение проблемы от производителя, не слишком много. Зато придется щедро вознаграждать аутсорсера за разработку различных workaround, чтобы заставить коммерческий софт хоть как-то дышать. Маркетинговая стратегия, когда изначально выпускается некачественный (сырой) продукт, чтобы потом можно было мужественно решать проблемы, попутно взимая с покупателей мзду за их решение, уже давно стала стандартом ведения бизнеса.
Фигура вторая, печальная
Долгое время мы использовали в компании оборудование Nortel, не дешевое, но весьма надежное. Пожалуй, это пример, когда инвестиции значительные, но операционные расходы относительно низкие. Мне был симпатичен их подход evergreen, который определял, что пользователь их оборудования относительно недорого может довести свое старое оборудование до современного уровня в любой момент. Грубо говоря, они декларировали возможность производить апгрейд оборудования, когда это реально необходимо, не взимая постоянную мзду за ненужный саппорт.
Avaya после приобретения компании Nortel об этой концепции благополучно позабыла, начав размывать часть полученных разработок в своих продуктовых линейках. Как-то возникла необходимость добавить несколько лицензий на SIP-транки, железо для поддержки которых уже есть в станции и нужно лишь сгенерировать кей-код для открытия функционала. Ранее добавление необходимого количества лицензий обошлось бы в $500. В ответ на мой запрос Avaya ответила, что софт на станции ныне уже не поддерживается, и чтобы добавить лицензий, нужно потратить что-то около $18 тыс. на обновление ПО до поддерживаемого уровня и на приобретение ненужного мне саппорта. По сути, нас взяли в заложники, навязав апгрейд станции и поддержку.
Используя подходы «партизанских ИТ», можно собрать вполне надежное решение добавив в схему Asterisk, эдакий швейцарский нож, которому под силу разрешить ряд проблем с телефонией с минимальным ущербом для бюджета.
Фигура третья, нервная
Приведу другой пример, показывающий, что приобретение коммерческих продуктов совсем не гарантирует их поддержку. Году в 2008-м для организации видеоконференцсвязи (ВКС) мы закупили недешевое оборудование итальянской фирмы Aethra. В кризис подразделение этой компании, занимающееся разработкой систем ВКС, было приобретено RADVision. Некоторое время назад, зайдя на российский сайт Aethra, мы обнаружили новую прошивку для ВКС, сдуру накатили на «железо», после чего имеющийся у нас код активации перестал подходить, а старой прошивки уже ни где не было. Нет бы предупредить заранее, что прошивка требует другого кода! Обратились в Aethra (ныне RADVision), получили ответ: оборудование не поддерживается; старую прошивку мы не знаем где взять; лицензии на новую не знаем, как сгенерировать, но постараемся помочь. Ждем помощи уже с месяц, но опыт подсказывает: шансов, что она будет, нет. По счастью на torrent нашлась старая прошивка (более старая, чем у нас была, но которая не спрашивает ключа активации). По идее, если ты не желаешь продавать продукт и ключи к нему, сними защиту и выложи в открытый доступ. Это было бы корректно по отношению к потребителям и не оставалось бы неприятного осадка.
Следуя принципам «партизанских ИТ», здесь тоже можно приладить Asterisk, собрав незамысловатую конструкцию из камеры с широкоугольным объективом, например топовыми моделями web камер от Logitech, HP, Microsoft и др., либо для особых ценителей качества и нестандартных решений - использовать в качестве веб-камеры фотоаппарат (например, «зеркалку») или видеокамеру, и подходящим VoIP-клиентом. Как верно отмечалось в рекламе, «если нет разницы, зачем платить больше». Несомненно, при таком подходе подрастет стоимость сопровождения за счет падения юзабилити, но зато можно подсократить инвестиции. В некоторых случаях такой обмен более чем приемлем. По сути, это ИТ-стратегия на минимизацию капитальных затрат за счет роста операционных.
Мыши плакали, но продолжали есть кактус
Все мы понимаем, что производителям нынче хочется сделать так, чтобы оборудование/софт ломались в точно намеченный срок по окончании гарантии/техподдержки, чтобы покупатель шел за новым «шедевром». Проблема здесь одна: после подобных мытарств хочется навсегда позабыть о такой компании или о ее новом хозяине и попытать судьбу с другой, пусть потенциально такой же убогой, но с другой.
Ребрендинг — красивое маркетинговое понятие, хотя в некоторых случаях под ним скрывается банальная спекуляция. Грешат этим многие, и все бы ничего, если бы не многократное увеличение стоимости «отребрэнденных» продуктов. Например, у IBM, весьма уважаемой мной компании, «железками» которой пользуюсь многие годы, качество, производительность и уровень сервиса почти безупречны, но и ценник за приобщение к счастью соответствующий. И ладно, когда уверен, что покупаешь продукцию IBM и поэтому платишь соответственно! Но когда знаешь, что берешь, например, СХД от LSI, не менее уважаемой компании, но куда более скромной по аппетитам, под личиной IBM втридорога, почему-то не оставляет ощущение обмана. Это чувство усиливается, когда видишь ценник на жесткие диски для СХД. Какой-нибудь Seagate диск 2 Тбайт с SATA-интерфейсом стоит в районе $250–300, а тот же диск для СХД IBM DS4200 в «обертке» от IBM обойдется уже в $2500. И почему-то слабо верится, что замена в оригинальном диске Seagate прошивки волшебным образом повышает его надежность и производительность в 10 раз... И почему-то поставить оригинальный Seagate не получится — СХД его не признает за своего. Другие крупные вендоры, вроде HP, EMC и т.д., идут сходным путем, живя «на эти три процента».
На сей счет принцип «партизанских ИТ» говорит, что имеет смысл попробовать использовать подходящий сервер, скажем Supermicro, с установленным ПО, делающим из сервера СХД: Open-E, Nexenta, Avrora[Raid] и др. Кто-то скажет, что при такой ИТ-стратегии просядет надежность ИТ-системы. В некоторых случаях это несомненно, но, с другой стороны, стоимость такой СХД будет минимум в 4(!) раза меньше, чем «железо» именитого бренда, при сходной производительности. Фактически, по цене одной брендовой СХД можно взять минимум два отдельных сервера с двухканальными FC-картами и таким образом поднять отказоустойчивость системы, при «отвязавшись» от вендора.
* * *
Подобных примеров »клиентоориентированного» подхода не счесть — как по «железу», так и по софту. К сожалению, нынче стратегия, опирающаяся на известный брэнд, не является залогом успеха ИТ-инфраструктуры. Возможно, настала пора переосмыслить традиционный подход и решать задачи теми средствами, которыми ранее побрезговали бы воспользоваться. Просто потому, что ситуация такая, а развиваться как-то надо. Застой в бизнесе — штука неприятная, а застой в ИТ еще хуже. Хотя перегибать палку не стоит, и к принятию подобных решений следует подходить максимально взвешенно, понимая, какой ценой потом придется компенсировать риски.
Опубликовано 05.10.2011