Малыши и гиганты
Автор
Александр Башкиров
Использование 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 устраняя «детские болезни», и попадают-таки в сегмент выше, пересматривают ценовую политику, теряют старых клиентов, находят новых... Все это я привожу не для того, чтобы показать, как все плохо, а для того, чтобы наглядно продемонстрировать, что «взросление» ИТ-решения — это процесс. Длительный, местами неудобный, местами требующий внимания, местами требующий переосмысления основ... но дорогу осилит идущий — в этом процессе главное — не увлекаться, понимая, куда и зачем движется система.
Ну и напоследок рассмотрим обратную ситуацию. Обычно попытка интегрировать большое решение в малый бизнес проваливается еще быстрее, чем попытка использовать «маленькое» решение в большом бизнесе. Потому что «большие» решения обычно сильно кастомизируются, их обслуживание стоит достаточно весомых для малого бизнеса сумм, в общем — получается кругом невыгодно.
Таким образом, все достаточно просто, если не вдаваться в детали: хотим мы или нет, но для каждого типа бизнеса будут свои типы ИТ-решений. И иначе никак.
Опубликовано 31.03.2014