Просмотр исходного текста страницы Важное преимущество заказной разработки – способность развиваться в разнородной информационной среде

;[[:Категория:Михаил Заборов (Статьи)|Михаил Заборов]], руководитель направления Торговые сети

компании CustIS (Заказные ИнформСистемы)
;[[:Категория:Андрей Борейко (Статьи)|Андрей Борейко]], заместитель директора по развитию бизнеса компании CustIS (Заказные ИнформСистемы)

''Обзор на сайте CNews «ИТ в торговле 2007» <ref>[Обзор «ИТ в торговле 2007» http://www.cnews.ru/reviews/free/trade2007/index.shtml]</ref>.''

<blockquote> ''О тенденциях и подходах к использованию торговыми сетями заказных ИТ-решений.''
</blockquote>

'''CNews: Как вы оцениваете современное соотношение спроса ритейлеров на заказные разработки и коробочные решения? Как этот спрос изменился по сравнению с ситуацией 2-3 летней давности?'''

''' Андрей Борейко:''' Рискну предположить, что ни участники этого рынка, ни аналитики не могут с уверенностью сказать в каком процентном отношении оплаченный спрос распределяется между услугами заказной разработки и коробочными решениями. Ведь лицензии за ПО и объявленная цена внедрения — это только надводная часть айсберга. В действительности доля заказной разработки больше того, что можно увидеть из рейтингов и обзоров.

Если говорить о рынке решений для ритейла, то сейчас, в отличие от ситуации 2-3 летней давности, подтягивается вторая волна розничных сетей, которая предъявляет платежеспособный спрос на все виды разработки, то есть осваивает разные подходы к автоматизации. Мы видим спрос со стороны крупных региональных сетей. Мы видим спрос среди тех сетей, в которых собственники сохраняют непосредственный контроль над управлением и пока не собираются продавать свой бизнес. Для этих компаний выбор модели взаимодействия с поставщиком решения — вопрос во многом открытый, так как для них создание информационной системы все еще является одним из инструментов долгосрочного развития, а не частью предпродажной подготовки.

'''CNews: По наблюдениям других участников рынка заказная, «домашняя» разработка за последние годы несколько вышла из моды. Почему же остается спрос на такого рода услуги?'''

'''Андрей Борейко:''' Прежде всего надо заметить, что заказная или проектная разработка принципиально отличается от «домашней». Различия существуют, прежде всего, на уровне подхода. Внутренняя разработка — это вспомогательный бизнес-процесс, который практически всегда имеет меньший приоритет, чем основная — торговая или производственная — деятельность. А заказная разработка — это профессиональная деятельность, профессиональная услуга. Клиент может мириться с ошибками собственной ИT-службы, принимая во внимание ее относительно меньшую стоимость. К внешнему подрядчику предъявляются совершенно другие требования. Отсюда следуют различия в темпах обновления технологической базы, в требованиях к рядовым специалистам, к методике управления проектами и так далее. От внутренней разработки ожидается, что ПО будет работоспособно. От заказного решения требуется предъявить все атрибуты промышленного ПО. Кроме живого кода должна быть документация, программа обучения, выделенная служба поддержки и так далее.

'''CNews: С кем вам приходится конкурировать больше — с внутренней разработкой или с готовыми решениями?'''

'''Андрей Борейко:''' У клиента, как известно, есть три возможности — не предпринимать ничего, разрабатывать ПО самостоятельно или купить готовое решение. Мы предлагаем четвертую возможность. Заказная разработка может сосуществовать с внутренними и готовыми решениями, но все они вместе взятые конкурируют с инерционным сценарием развития предприятия, без инвестиций в IT.

'''CNews: Как вам удается сосуществовать с внутренней разработкой у клиента?'''

'''Михаил Заборов:''' Очень хорошо удается. Вообще наличие сильной ИT-службы внутри клиента — большая удача. Вот у «Спортмастера» просто потрясающая айтишная команда. Ее вклад в развитие сети невозможно переоценить. Имея такую ИT-службу, можно эффективно управлять работой и внешних проектных команд и поставщиков готовых решений.

К сожалению, далеко не все торговые сети вкладываются в развитие собственных команд так, как это делает «Спортмастер». И дело здесь не только в экономии и в абсолютных размерах торговой сети. Просто так складываются приоритеты, что даже при сопоставимых оборотах сети численность технологических подразделений может различаться в разы, если не на порядки.

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

'''Михаил Заборов:''' Начинать «с нуля» имеет смысл в случае действительно уникальных бизнес-процессов. Например, в абсолютно новой предметной области. Более того, в таком случае другие варианты вообще не просматриваются.

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

Мы, например, используем по мере возможности оба слоя наработок — и технологический, и функциональный. Причем функциональный слой зачастую не уступает известным готовым решениям. Но этот функциональный задел не является для нас аксиомой. И объем изменений под конкретного заказчика может быть значительным.

'''CNews: Общепризнанно, что одним из ключевых преимуществ готовых решений является использование «лучших практик». Готовое решение аккумулирует в себе опыт множества пользователей. Очевидно, заказной разработке трудно похвастаться таким багажом. Что она может противопоставить «лучшим практикам» от международных вендоров?'''

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

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

'''CNews: Тем не менее, остается ценовой фактор: стоимость создания «готового ПО» распределяется среди большого числа клиентов. Можно ли считать, что в проектной разработке все бремя трудозатрат ложится на одного клиента?'''

'''Андрей Борейко:''' Все не так просто. Давайте посчитаем. Предположим, вы нашли готовое ПО, которое устраивает вас на 80 % (хотя такое совпадение — большая редкость). Нужно доработать всего 20 %. Сколько, по вашему, будет стоить такая доработка? Плюс эти самые 20 %?

Смотрите, инвестиции в разработку тех 80 % делались в расчете на большое число клиентов. Например, на 100 компаний. Стоимость разработки была распределена в среднем из расчета 0,8 % на одну компанию. А тут надо реализовать 20 % в расчете на одну компанию. То есть «удельный вес» нового функционала для разработчика в 25 раз больше, чем «вес» базовой конфигурации. Причем, далеко не всегда можно уверенно спрогнозировать что весь дополнительный функционал пригодится другим клиентам. Это грубый расчет — для наглядности. В действительности рост стоимости доработок происходит более плавно. Но в итоге природу не обманешь. Вот почему доработка вроде бы готовых решений пожирает иногда так много времени и ресурсов.

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

'''Михаил Заборов:''' Формально это так.

'''Андрей Борейко:''' Слово «формально» означает, что система будет закрывать «по площади» все основные бизнес-процессы. Таковы требования стандарта или маркетинговой идеологии ERP. Но при этом некоторые бизнес-процессы будут реализованы лишь контурно. А другие будут реализованы строго определенным образом, который отличается от бизнес-процессов заказчика. И те и другие особенности не очень заметны на уровне презентаций.

Реальную степень применимости и полезности ИT-решения клиент может понять, только сопоставив заявленный функционал со своей бизнес-практикой. А для этого он, повторимся, должен обладать собственной экспертизой. В том числе, в области IT. Плюс политика вендора должна допускать возможность анализа до продажи ПО.

'''CNews: По вашему мнению, фактически внедренная функциональность системы всегда отличается от декларируемой?'''

'''Михаил Заборов:''' Не всегда. Степень совпадения будет зависеть минимум от двух ключевых факторов. От наличия собственной ИT-экспертизы и от готовности менять свои бизнес-процессы. Если есть и то и другое, то результат может соответствует заявленным возможностям и ожиданиям: хотели внедрить систему Х — вот она, пожалуйста. Если ИT-экспертиза отсутствует и меняться не хочется, то решение будет внедрено в лучшем случае формально, для «галочки». Если отсутствует только одно из условий, тогда возможны два варианта. При отсутствии ИT-экспертизы многое будет зависеть от того, как повезет с подрядчиком. Повезет — внедрят, а не повезет — опять таки будет результат только на бумаге. Если же внутри есть хорошая айтишная команда, а бизнес-процессы руководство трогать не позволяет, то внедряют как бы систему Х, а на выходе получается заказное решение Y под брендом Х. Цена такого решения будет уже X плюс Y.

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

'''Андрей Борейко:''' То есть стихийная смена модели разработки оборачивается слабой управляемостью процесса. Поэтому неконтролируемый рост цены не сопровождается снижением рисков, а наоборот — риски растут пропорционально стоимости.

'''CNews: Допустим, что поскольку каждая модель разработки — внутренняя, готовое решение и заказное — имеет свои преимущества, готовые решения не вытеснят с рынка остальные подходы. Логично предположить, что выбор модели должен соответствовать определенным условиям. В каком случае какая модель разработки является оптимальной, скажем, для тех же торговых сетей?''' 

''' Михаил Заборов:''' Надо учитывать на каком этапе развития находится торговая сеть. По нашим наблюдениям большинство сетей проходят максимум шесть этапов. Сразу оговорюсь, что последовательность этапов — не строгая. Они могут где-то совпадать или обгонять друг друга.

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

На первом этапе об ИT особо говорить не приходится. А вот на втором уже как правило имеется небольшая команда разработчиков. Как правило, она хорошо справляется и быстро становится незаменимой. Удачные технологические решения топ-менеджеров быстро воплощаются в ПО.

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

'''CNews: Подразумевается, что на первых трех этапах доминирует внутренняя разработка?'''

'''Михаил Заборов:''' Да. И это вполне оправдано. Но вот на четвертом этапе ситуация меняется. Его можно, опять таки условно, обозначить как этап «механизации». На этой стадии внедряются специальные, локальные приложения, которые слабо затрагивают сквозные процессы, но могут сильно повысить технологичность конкретных участков. Например, складская система (WMS), система управления транспортом (TMS).

На пятом этапе происходит переосмысление всей технологии работы сети. Здесь становятся очевидны ограничения внутренней разработки. Система останавливается в развитии. Основные усилия IT-службы уходят на поддержание текущего функционала. Обостряются проблемы с масштабируемостью и производительностью ПО. И поскольку старая модель задает ограничения для развития бизнеса принимается трудное решение о реинжиниринге всей информационной системы предприятия.

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

'''Андрей Борейко:''' Если сопоставить этапы и модели разработки: внутренняя, заказная и внедрение готовых решений, то напрашиваются следующие выводы. Внутренняя разработка нужна и полезна практически на всех этапах. Правда, требования к ней меняются. Заказная разработка может постепенно «врастать» в информационную среду предприятия, начиная с этапа «хирургической бригады» или грибного роста. А готовые решения становятся актуальными не раньше этапа «механизации». На этапах переосмысления и «конвейера» могут пригодиться все три модели. Вопрос только в том, чтобы установить оптимальное соотношение и наладить кооперацию.

'''CNews: При каких условиях выбор заказной разработки действительно оправдан?'''

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

'''Михаил Заборов:''' Заказной разработке предшествует концептуальное проектирование. Это очень важный этап, который, помимо прочего, позволяет согласовать с заказчиком жизненный цикл функциональных модулей, сопоставить объем инвестиций со сроком службы и ожидаемой отдачей на каждом участке автоматизации. При таком подходе мы избегаем и ловушки версионности. Ведь не секрет, что у готовых решений установка новой версии часто выливается в полномасштабный проект внедрения.

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

'''CNews: Каковы ближайшие планы вашей компании в развитии экспертизы в области автоматизации торговых компаний?'''

'''Михаил Заборов:''' Нам больше всего интересны те бизнес-процессы, которые характерны именно для сетевой торговли. Какие-то функции являются более стандартными и не требуют специальных отраслевых решений просто потому, что принципы управления этими функциями мало отличаются не только на разных предприятиях, но в разных отраслях.

Мы же планируем сосредоточится именно на отраслевой экспертизе. Особенно на процессах продажи и тех обеспечивающих процессах, которые критически важны для эффективности бизнеса.

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

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

'''CNews: Спасибо.'''

== Ссылки ==
<references />

[[Категория:Андрей Борейко (Статьи)]]
[[Категория:Михаил Заборов (Статьи)]]
[[Категория:2007 год (Статьи)]]
[[Категория:CNews (Публикации)]]


{{replicate-from-custiswiki-to-lib}}