Известно немало примеров, когда даже в таких массовых отраслях, как розничная торговля, компании предпочитают заказную разработку тиражному программному продукту. Об этом свидетельствует, в частности, опыт российской компании CUSTIS, которая на протяжении многих лет решает задачи автоматизации для группы компаний “Спортмастер”. Научный редактор PC Week/RE Сергей Свинарев беседует с руководителем отдела технологического развития компании CUSTIS Игорем Беспальчуком.

PC Week: Какова сегодня ситуация на российском рынке приложений для розничной торговли?

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

PC Week: Что мешает заказчику выбрать продукт, уже представленный на рынке?

И. Б.: Дело в том, что иногда поставщик тиражного продукта, ознакомившись с требованиями заказчика, приходит к выводу, что бизнес-процессы торговой сети настолько нетипичны, что не укладываются в стандартную функциональность. Надо понимать, что бизнес-практики торговых предприятий вырабатываются годами и отражают существенные особенности их работы в конкретных условиях. Отказываться от них предприятию трудно. Есть два выхода из положения: либо подстроить свои бизнес-процессы под те, что “зашиты” в тиражное приложение, либо попытаться реализовывать их с помощью настроек и доработок. Во втором случае речь идет фактически о некой заказной разработке, которая, тем не менее, ограничена рамками базового приложения. Мы же можем вести такую разработку без каких-либо ограничений, создавая именно тот функционал, который нужен заказчику.

PC Week: Допустим, в организации уже используется ПО собственной разработки, которое устарело технологически, но содержательно всех вполне устраивает. Вы беретесь воссоздать такое приложение на более современной платформе?

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

PC Week: А как при таком подходе происходит замена старого приложения на новое?

И. Б.: Это действительно важная проблема. Ведь информационная система крупного торгового предприятия должна функционировать круглосуточно и без перерывов, а переход на новое приложение всегда сопряжен с огромными рисками. На данном этапе мы используем методологию, которую называем “бережное внедрение”. Суть ее в том, что старая и новая системы некоторое время работают параллельно в режиме промышленной эксплуатации, дополняя, но не дублируя друг друга. Новой системе постепенно передаются либо отдельные бизнес-процессы, либо поддержка всех функций некоторых структурных подразделений (например, магазинов или складов). При этом никаких проблем, связанных с несогласованностью данных или с их двойным вводом, нет, поскольку на протяжении всего переходного периода отсутствует какое-либо дублирование: всегда одни данные хранятся в старой системе, а другие — в новой. Выявленные на очередном шаге внедрения недоработки оперативно устраняются, после чего сфера действия новой системы расширяется на очередные бизнес-процессы или подразделения. Чтобы обеспечить такой режим работы, нам приходится прикладывать дополнительные усилия: нужно обеспечить интеграцию новой системы с внешними по отношению к ней приложениями, а также временную интеграцию старой и новой систем, которые должны определенное время функционировать как единое целое. Такой проект выполняется дольше, но при этом риски внедрения существенно снижаются , а дополнительные трудозатраты с лихвой компенсируются отсутствием масштабных сбоев в работе ритейлера на протяжении внедрения. Отмечу, что финансовые последствия подобных перебоев намного значительнее любых затрат на ИТ.

PC Week: Как в результате заказной разработки обеспечить промышленное качество программного продукта?

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

P C Week: Спасибо за беседу.