УправлениеИТ в бизнесе

Малыши и гиганты

Александр Башкиров | 31.03.2014

Малыши и гиганты

Использование Open Source всего лишь сводит к нулю одну из статей — остальные так или иначе остаются
В свое время, поработав с «большими» решениями от именитых вендоров, я думал, что третьего не дано: не могут решения маленькие сделать столько же, так же! Затем, поработав с «маленькими» решениями, с удивлением понял, что они могут быть не хуже решений больших. А весь фокус лишь в том, как поставить задачу.

В общем, не секрет, что ИТ-системы не возникают сами по себе. Любая из них — следствие решения определенной бизнес-задачи, решения определенной потребности бизнеса. Бизнес требует — ИТ дает адекватный ответ. Точнее, ИТ дает предложения по бюджету и возможностям — и бизнес совместно с ИТ выбирает. По-хорошему, такого рода решения должны быть соотнесены со стратегическими планами. Совсем по-хорошему — должны планироваться и заранее ложиться в бюджет следующих периодов. Это когда он есть, этот бюджет... А когда нет? Когда нет, все равно остается бизнес-потребность. И выделение целевого финансирования на то, чтобы ее закрыть. 

Здесь надо сделать небольшое отступление и вспомнить про любимый всеми нами класс бесплатных решений — Open Source. «Какое под них финансирование?» — спросите вы, и отчасти будете правы. «Отчасти» — потому что стоимость лицензии — это не полное финансирование на внедрение. Даже больше скажу: зачастую стоимость лицензий —наименьшая часть из всех расходов на внедрение. Почему так? Давайте рассмотрим типичную структуру затрат на внедрение ИТ-решения. Во-первых, это стоимость аппаратной части. Она может быть равной нулю, если аппаратные средства достаточной мощности и требуемой конфигурации есть у заказчика. Во-вторых, стоимость лицензий. Тоже может быть равной нулю, в случае OpenSource. В-третьих, затраты на внутреннюю команду внедрения. Могут быть равны нулю в случае полного аутсорсинга услуги по внедрению. В-четвертых, затраты на аутсорсинг внедрения, то есть на столь любимых ИТ-директорами интеграторов, внедренцев и прочую публику такого рода (несмотря на иронию, я с большим уважением отношусь к этим людям: достаточно долгое время сам был на «той стороне» баррикад). В-пятых, административные расходы на внедрение: секретари, офис, совещания (время первых лиц и сотрудников, задействованных в процессе). Нулевыми они не могут быть по определению, за исключением случаев проектирования сферической ИТ-системы в вакууме. (Честно сказать, ни разу не видел такого.)

Что получается в итоге? Использование Open Source всего лишь сводит к нулю одну из статей — остальные так или иначе остаются. Более того, если речь идет о достаточно серьезном Open Source (например, какая-нибудь ERP на базе Open Source), то не обойтись без сторонней организации, которая специализируется именно на такого рода внедрениях... А поскольку Open Source обычно документировано... средне, или плохо — то специалистов, глубоко погруженных в этот конкретный продут, мало. И они сконцентрированы в таких вот клубах по интересам. В итоге и приходится переплачивать за внедрение. Правда, сумма «переплаты» может вызвать улыбку — если сравнить ее со стоимостью внедрения какого-нибудь серьезного решения, относящегося к первой линейке... Это еще раз подтверждает, что все познается в сравнении.
Вывод из сказанного очень простой: любое внедрение любой системы будет стоить каких-либо денег заказчику, вне зависимости от того, попадет это в бюджет или не попадет, будут как-то оценены подобные затраты или нет. Они просто будут — и все. 

Вальс или гопак?

Вообще, приступая к поиску решений, нужно ответить себе на ряд очень простых вопросов. Первый: какую прямую задачу будет решать предложенное решение? Второй: какое время будет потребность в решении исходной задачи? Третий: насколько изменится исходная задача через полгода, год, два, три? Четвертый: сколько сотрудников будет охвачено привнесенным решением контуром автоматизации в настоящее время? Через год? Через два-три?

Вопросы, прямо скажем, непростые. Зачастую оценить, насколько будет востребовано решение через год-два, и дать прогноз роста — почти нереально. Хотя бы потому, что из всех известных мне компаний, хорошо если у 2–3% есть планы развития, с конкретными цифрами. Большинство же компаний живет по принципу: посмотрим, и если получится, то и дальше будем решать, что делать и как жить. 

Таким образом, перед ИТ-специалистом (аналитиком, руководителем) стоит непростая задача: в условиях высокой неопределенности предложить решение, которое полностью разрешит текущую задачу, оставит небольшой простор для оптимизации и возможность для будущего развития, а также впишется в примерный бюджет.

Собственно, в этом месте и начинаются различия между «большими» и «маленькими» ИТ-решениями. Вернее, между решениями для больших и небольших компаний. Почему? Да потому, что небольшие компании склонны чаще выбирать небольшие решения, которые закроют текущие задачи, выберут небольшой бюджет — проработают какое-то время, а там по принципу «как получится»: или оно будет продолжать работать, или будет выведено из эксплуатации, или еще что-нибудь случится (например, бизнес перепрофилируется, задачи изменятся и т. д.). А вот большие компании, как большие корабли, меньше подвержены такого рода флуктуациям. И, как следствие, больше уделяют внимания планированию, процессы в них более прогнозируемы. То есть вероятность попасть в яблочко при выборе решений для таких компаний выше. Да и в отличие от небольших компаний, у них уже есть своя инфраструктура, своя экосистема, и выполняя ИТ-проект для такой компании, нужно смотреть не только на то, как она решит ту или иную задачу, но и на то, как новая система впишется в существующий ИТ-ландшафт. Вообще, как ни парадоксально, по моему мнению, выбирать ИТ-решения для крупной компании легче, чем для маленькой. А большие ИТ-решения для большой ИТ-компании — выбирать проще, чем те же решения для маленькой, или маленькие решения для большой. И наконец, для большого решения в большой компании проще выстроить план — в том смысле, что такое решение проще соотнести с планами развития в части ИТ.

Аппетит приходит вовремя

Все причины, по которым компании принимают решение о необходимости внедрения того или иного решения, можно условно разделить на два класса: инициируемые со стороны ИТ и инициируемые со стороны бизнеса. Обычно предложения со стороны ИТ воспринимаются с большим недоверием, чем собственные: как говорится, «своя рубашка ближе к телу». Решения же, инициированные бизнесом, опять-таки, как правило, страдают некоторой поспешностью. Хотя встречаются, и достаточно часто, ситуации, при которых ИТ и бизнес «рука об руку» договариваются и делают конкретные шаги в сторону автоматизации определенного участка. 

И вот ура! Будем автоматизировать. Далее, рассматриваем и выбираем решение. Определяем список конкурсантов, начинаем писать ТЗ. Спустя некоторое время — окончательно определяемся, заключаем договор, начинаем внедрение... И где-то в середине пути или чуть раньше — приходят они. Страшный сон проектного менеджера — изменения по ходу проекта. Вообще, если говорить серьезно, то не так уж и страшны изменения, как про них говорят — и в проектном менеджменте существует целый раздел, посвященный тому, что изменениями нужно управлять и как это правильно делать. Но сейчас речь не об этом. А о том, что изменения не рождаются сами по себе на ровном месте. Их рождению предшествует опытное осмысление решения и попытка вписать его в работу со стороны каждого из участников процесса. И хотя одни изменения могут быть просто прекрасны, а без других никак не обойтись, в большинстве своем все они ведут к тому, что намеченный вектор смещается от заданной цели. И если этот процесс хоть на некоторое время упустить, то есть риск, что в итоге придем совсем не туда, куда планировали изначально. Более того, известны случаи, когда изменения разворачивали первоначальные намерения на 180 градусов. И чем дальше компания входит в проект, тем больше разыгрывается аппетит — и тем больше поступает запросов на изменения. И у этого процесса (еще раз подчеркну: абсолютно нормального) есть два тормоза. Первый — управление изменениями. Грамотно построенное, оно способно направить изменения в правильное русло, на благо конечному результату. И есть так называемый естественный тормоз, а именно возможности самой системы. Не секрет, что чем «меньше» и «проще» система, тем у нее больше ограничений. Соответственно, если система не может чего-то, запрашивать изменение в отношении этой функции почти всегда бессмысленно: ответ будет или «нет», или «можем, в специальной версии для вас, за отдельные деньги».

Не исключен и третий сценарий, фактически являющийся комбинацией первого и второго: некоторые изменения, находящиеся в границах возможности системы, проходят по процессу, а те, что вне контура, разбиваются о невозможность реализации. Тем не менее правило, что аппетит приходит во время еды, действует применительно к внедрению любых ИТ-решений на 100%. А вот в зависимости от масштаба и возможностей выбранных систем последствия могут быть очень разные.

Гигант и кроха

Еще один очень важный применительно к теме вопрос: а что, собственно, считать «большим» и «маленьким» решением? Некоторые производители отвечают на него сами, указывая, что вот такой-то продукт предназначен для малого бизнеса (и тут же дают критерии, по количеству операций, пользователей и т. д.). Но чаще такого нет, и тут уже приходится додумывать самостоятельно. 

Самый традиционный способ — рассматривать по числу пользователей. Очень грубо, все, что менее 50, — это малый бизнес, от 50 до 200 — средний. Ну и выше — крупный. Более 1000 — сверхкрупный. Второй способ — смотреть на объем операций. Тут так однозначно цифры не приведешь, но всем понятно, что если операций в сутки около миллиона, то явно речь идет о большом бизнесе. Третий способ — смотреть на оборот компании за определенный период.

Почему так важно понимать, какой бизнес большой, а какой нет? Дело в том, что компании не живут в оторванном состоянии. Они работают, развиваются, переживают кризисы и падения... и внедряют ИТ-решения. Для того чтобы четко понимать, какие решения нужно вообще рассматривать, а какие можно не рассматривать (в силу требований, объема, стоимости и т. д.), и нужна подобная классификация. При этом замечу, что традиционная для российского бизнеса градация по цене решения может и не сработать: маленькое решение от именитого производителя вполне может стоить достаточно приличные деньги. И найдет своего покупателя (того, у которого довольно большой оборот или который захочет по какой-либо причине именно это решение).

Вообще, к настоящему времени рынок в достаточной степени пришел к равновесному состоянию, то есть появились четко сегментированные по видам бизнеса, по целевому назначению, по величине бизнеса решения. При этом, конечно, «каждый солдат мечтает стать генералом» — система, ориентированная на малый бизнес, заявляет о своей применимости и для большого бизнеса, но, как правило, попытка использовать изначально ориентированные на малый бизнес решения для большого заканчиваются печально: или не хватает возможностей, или не работает в заданной конфигурации, или показывает низкую производительность под нагрузкой... Безусловно, некоторые из «маленьких» систем делают определенные шаги — step-by-step устраняя «детские болезни», и попадают-таки в сегмент выше, пересматривают ценовую политику, теряют старых клиентов, находят новых... Все это я привожу не для того, чтобы показать, как все плохо, а для того, чтобы наглядно продемонстрировать, что «взросление» ИТ-решения — это процесс. Длительный, местами неудобный, местами требующий внимания, местами требующий переосмысления основ... но дорогу осилит идущий — в этом процессе главное — не увлекаться, понимая, куда и зачем движется система.

Ну и напоследок рассмотрим обратную ситуацию. Обычно попытка интегрировать большое решение в малый бизнес проваливается еще быстрее, чем попытка использовать «маленькое» решение в большом бизнесе. Потому что «большие» решения обычно сильно кастомизируются, их обслуживание стоит достаточно весомых для малого бизнеса сумм, в общем — получается кругом невыгодно.

Таким образом, все достаточно просто, если не вдаваться в детали: хотим мы или нет, но для каждого типа бизнеса будут свои типы ИТ-решений. И иначе никак. 


Журнал: Журнал IT-Manager [№ 03/2014], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Мысли вслух

Все жалуются на нехватку времени. Особенно обидно, что его не хватает на самые важные вещи. Совещания, созвоны, подготовка внутренних отчетов, непонятно, насколько нужных, но которые начальство требует так, как будто это именно то, ради чего мы работаем.
Сейчас мы вступаем в следующую фазу выздоровления и восстановления, но гибридный мир никуда не денется
В России опрос показал: 48% составляют технооптимисты, а больше половины – технофобы и техноскептики.

Компании сообщают

Мероприятия

Юникон & гейм экспо минск / unicon & game expo minsk
Минск, пр. Победителей, 20/2 (футбольный манеж)
14.05.2021 — 16.05.2021
12:00
SAS Global Forum 2021
ОНЛАЙН
18.05.2021 — 20.05.2021