Практика ведения крупных проектов от 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 прямо-таки настаивает на участии в проектах консультантов (собственных в том числе) и других технологических партнёров. Это, вроде как, способствует выработке наиболее оптимальных решений по принципу «одна голова хорошо, а две лучше». То есть, есть хостинговая компания с подготовленными к размещению коммерческого приложения средами, есть консалтеры, есть команда проектировщиков и управляющих проектом и есть компании, предлагающие соответствующее оффшорное программирование. В сумме эти несколько компаний делят между собой и бюджет проекта, и ответственность.

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

Similar posts

Comments 12

    +2
    Зоопарк разных решений по автоматизации и геморрой с их интеграцией — вот единственный работающий подход.
    Нельзя все-все автоматизировать с помощью одного решения. Нужно использовать то ПО, которое позволяет вести бизнес лучше, а не выкручивать себе руки.
    У любой ERP есть свои сильные стороны, но точно есть и свои слабые. И ни одна ERP идеально не ляжет на конкретный бизнес.
    Выходит, что вопрос у вас какой-то теоретический, поскольку вариант «автоматизировать все-все одним» не жизнеспособен.
      0
      Мой вопрос был именно о практике ведения проектов. То, что Вы говорите, достаточно понятно. Может быть, я исходно неясно сформулировал свою мысль — я имел в виду практику, когда на крупный проект ключевой интегратор принципиально не берёт другие компании, и особенно — аналогичные по спектру услуг. Вот именно с таким подходом я сталкивался и считал его логично обоснованным в наших условиях.
      0
      Когда понимаешь что скушав эту рыбу можно поперхнутся то лучше дать кусок соседу. Всё самому сделать иногда не выходит, и это не самая худшая практика.
      Вот вы спрашивали, что будет через год или два, ничего особенного, второй подрядчик подтянет свою часть а вы свою.
        0
        Насколько я знаю, в России так не принято делать. И в любом случае, про соседа заказчик ничего не узнает: это что же, он потом к конкуренту уйти может?!
        +2
        Именно поэтому крупный бизнес, считающий деньги и работающий на перспективу, выбирает индустриальные решения: он покупает не столько программный комплекс, сколько пресловутые «лучшие практики», гарантию отсутствия типовых грабель, о существовании которых он может даже не догадываться на нынешнем этапе развития бизнеса.


        Очень спорное утверждение (если, конечно, абстрагироваться и не считать весь пост завуалированной джинсой).
          +1
          Жаль, что Вы так подумали (про джинсу). Мне в самом деле интересно, как у нас обстоят дела на больших проектах, а то, может, я уже давно от жизни отстал. Я там чуть выше в комментариях скорректировал свой основной вопрос, возможно, я неясно выразился.

          Кстати, я наслышан и про случаи переманивания специалистов, задачи которых заключались в затыкании конкретных технологических дырок в проектах. Правильный с точки зрения описанного мной вендора подход говорит о том, что следует не хантить спецов, а обратиться к компании с соответствующей компетенцией (и, конечно, находящейся в экосистеме вендора). А это вам как?

            +2
            Современные фреймворки дошли того уровня развития, что написать самому будет дешевле, чем развернуть большое готовое при той же (а то и большей) надежности. При этом это будет bespoke, lightweight и легким в поддержании и, самое главное, в добавлении фич (при условии аккуратных разработчиков). Большинство больших игроков, особенно в e-commerce секторе, это заметили.

            При чем применимо не только к .NET-сектору (где всегда были большие и удобные плюшки для сильного уменьшения времени), но и к PHP, Ruby.
              +1
              Это зависит от размера проекта, как я понимаю. Безусловно, для небольшого интернет-магазина я первый посоветую или Битрикс, или Опенкарт, или Виртумарт с Джумлой — да по сути что угодно, что подойдёт под требования заказчика. Просто когда речь идёт о бизнесе с ежегодным оборотом в 20, 50, 80 миллионов долларов, написать самому не получается — слишком всего много, слишком много надо кодировать бизнес-правил — сдаётся мне, писать самому не хватит ни здоровья, ни времени. Именно поэтому крупные заказчики и выбирают больших вендоров и их партнёров.

              А так по Вашей логике и бухгалтерию самому написать можно, зачем 1С покупать )))
                +1
                Далеко ходить не нужно для примера с вашим бюджетом – X5 Retail Group. И это, поверьте, не исключение. Как раз из-за того, что часто специфика крайне узка, использовать готовое решение – себе дороже (на выходе спустя годы получаесят монстр с кучей надстроек вместо отлаженного продукта).
                  +1
                  Чорт, ещё дальше в сторону от моего основного вопроса ушли ))

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


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

                    Во-первых, аутсорс всегда дороже, чем собственные разработчики (но их нужно найти и собрать команду, а это время). Во-вторых, если подобное делается впервые, естествено желание попробовать существующие продукты (и убедится в их несостоятельности удовлетворить необходимые потребности; как пример, вы бы знали чего стоила интеграция для обмена данными между моей системой и ATOS — я мог сделать все, что угодно, подстроится под любую архитектуру, у них же были одни ограничения). Поэтому, если есть время (обычно около года–полутора для большой системы) грамотные люди выбирают создание своей собственной. Я лично знаю одну компанию (помимо обычных примеров), которая 3 раза пыталась создать свою систему сначала, используя готовые наработки, потому и, так называемых, спецов в экосистеме вендора (и еще у одних). В итоге потеряла 3 года, создала свой IT-отдел (из 4 человек) и сделала собственный продукт, каждый месяц выпиливая новые фичи и реализуя любые хотелки клиентов.
                      0
                      Справедливости ради, отмечу один факт: свою систему никогда не нужно начать писать, если нет человека, который легко разбирает на кусочки бизнес-кейсы, знает, как сделать удобно и правильно, что приоритетно и т. д. Такой человек действительно будет критичен для системы и бизнеса (по крайней мере до момента запуска + в идеале, года после этого).

                      Но грамотный работодатель, если нашел такого человека, сделает все, чтобы не потерять (умный человек возьмет его в долю, предоставит опционы и т. д., а не будет держать с зп в 150 на руки).

          Only users with full accounts can post comments. Log in, please.