Практика ведения крупных проектов от Oracle

В апреле сего года меня волею судеб занесло на Oracle Commerce Conference в Лиссабоне. Не суть важно, что конкретно из себя представляет Oracle Commerce как продукт (если будет интересно, могу написать отдельный топик), я хотел рассказать о другом — а именно о том, как в настоящее время продаёт и ведёт проекты автоматизации электронной торговли один из крупнейших поставщиков промышленного софта.

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

Крупный торговый бизнес имеет массу требований к каждому функциональному блоку системы. В лучшем случае, у заказчика уже есть система ERP с массой бизнес-правил, включая организацию цепочек поставок, управление ассортиментом, прогнозы и автоматические заказы поставщикам, а c ней стыкуется весьма навороченная WMS, где-то рядом лежит финансовое управление, и всё это сопровождается бухгалтерией и бизнес-аналитикой. А теперь мы ко всему этому прикручиваем систему электронной коммерции, которая, в соответствии с современными тенденциями, должна охватывать все каналы продаж, включая традиционные.

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

Я даже больше скажу: сейчас в России идёт один очень крупный проект (о котором я не могу разглашать подробности), так вот над ним работает один не самый мелкий западный подрядчик с многолетней компетенцией в Oracle Commerce, который, тем не менее, в свою очередь привлекает к участию в проекте команду оффшорных программистов и одну из крупнейших консалтинговых компаний в мире. Понятно, что можно долго рассуждать об управлении собственной командой, преимуществах и недостатках той или иной модели построения рабочего процесса, я же хочу заострить внимание на том, что Oracle буквально поощряет сотрудничество партнёров при работе над крупными системами. Всем участникам процесса нужны хорошие референсные проекты и клиенты, добившиеся значительных успехов в бизнесе с помощью введённых в эксплуатацию систем, и зачастую интегратору не стоит заниматься развитием определённой компетенции в собственной компании в ущерб срокам и качеству работ.

В каком-то смысле осознание этого кластерного подхода перевернуло моё представление о ведении проектов. Обладая определённым опытом построения подобных систем, мне даже в голову не приходило такое делегирование проектных работ. Даже относительно большие системы мы создавали, опираясь исключительно на собственные силы, пусть иной раз с привлечением отдельных внешних специалистов-фрилансеров, но не компаний. Конечно, для заказчика это обходилось дешевле, но в итоге он получал систему, не полностью учитывающую лучший опыт и созданную людьми, не всегда хорошо понимающими перспективы развития бизнеса. Очевидно, что хорошо спроектированная система электронной коммерции в состоянии реализовать текущий набор требований, но что будет с ней через год? А через два? Что, нужно будет бесконечно допиливать какое-то кастом решение для того, чтобы в итоге упереться, скажем, в ограничение производительности?

В качестве яркого отрицательного примера, мне известна одна весьма немаленькая отечественная торговая компания, в которой имеется собственный штат из примерно 60 программистов, поддерживающих самописную ERP-систему. Особый бонус — это LAMP. Можете себе представить, как этот монстр обновляется и поддерживается.

Есть и положительный пример, правда, уже не наш, а голландский (если нужны подробности, напишу, проект интересный и, увы, совершенно невозможный в нынешней России). Технологический ландшафт такой: Oracle Commerce на фронте, SAP ERP и Manhattan WMS на бэке и управляет всем этим собственный штат IT-отдела размером в 6 человек, считая IT-директора.

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

Я всё это к чему написал: коллеги, особенно имеющие опыт реализации по-настоящему крупных проектов! Как вам кажется, какой подход в наших реалиях всё же уместнее: «многоядерный» или «принцип одного окна»? Особенно буду признателен за истории из личного опыта: это позволит мне привести в порядок собственные пошатнувшиеся представления о ведении проекта.